Seguridad en PHP

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, como preg_match('/^.+@.+\..{2,3}$/',$_POST['email'])
    * Usar funciones que escapan caracteres especiales de una cadena para su uso en una sentencia SQL, como You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, la cual coloca barras invertidas antes de los siguientes caracteres: \x00, \n, \r, \, ', " y \x1a. O You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, (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 You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, y las cookies asociadas al sitio web serán incluidas en la consulta:

Citar<script>document.location = 'You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login' + 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 You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login que convierte caracteres a entidades HTML, You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login que elimina las etiquetas HTML y PHP de una cadena y You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login.
    * 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:

CitarGET /buy.php?symbol=SCOX&quantity=1000 HTTP/1.1
Host: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
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 en register_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=../secret accediendo 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 You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login y nuestro script se encuentra en You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login. Un atacante puede hacer esta petición: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login 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 You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login? 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 You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login 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.

• You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
• You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
• You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Buena info , les va a servir a muchos que recien comienzan a implementar seguridad en PHP.. Gracias por el aporte

Saludos

Gracias por esta info pHP, viene muy bien para todos aquellos que recien comienzan y para los que quieren mejorar en este tipo de programacion.