13 consejos para mejorar la seguridad

de tu aplicacin web
Publicado en 18 junio, 2014 por lvaro Reig Gonzlez 2 comentarios

Hace algunas semanas asist a un (excelente) curso de seguridad en

aplicaciones web impartido por @raulsiles en el Centro Criptolgico Nacional.
Tras terminarlo program una pequea auditora de varias aplicaciones. Este post
trata de ennumerar una serie de consejos bsicos para mejorar la seguridad de
una aplicacin web con relativamente poco esfuerzo

0.-Formacin, formacin, formacin

Todos debemos tener unas nociones bsicas. Hay muchos cursos (incluso gratuitos)
y libros. No te fes exclusivamente de lo que te cuenta en un blog alguien no

experto en la materia

1.-Estar al tanto de las actualizaciones de los

productos utilizados
Una aplicacin est sustentada en una serie de componentes software. Todos los
das se descubren vulnerabilidades que afectan a esos componentes y se
publican actualizaciones para parchearlas. Si no aplicamos esas actualizaciones
tenemos componentes con vulnerabilidades conocidas y publicadas. Por ejemplo,
si un atacante averigua que en una aplicacin se utiliza PHP 5.3.X (sin soporte,
actualmente estn vivas las ramas 5.4.X y 5.5.X) sabe las vulnerabilidades no
parcheadas desde el fin de soporte de PHP 5.3 y por lo tanto puede explotarlas.
Por ejemplo, supongamos una aplicacin basada en Drupal corriendo en un
servidor web Apacheen Ubuntu Server. Pues habra que estar al tanto de:
Drupal y sus mdulo que utilicemos.
Apache y sus mdulos.

PHP
Ubuntu Server

Para evitar estar consultando pginas, yo trato de suscribirme a feeds rss y

newsletter de las releases de cada componente.

2.-Comprobar la informacin que se obtiene

de las cabeceras HTTP
Las cabeceras HTTP suelen aportar ms informacin de lo deseable acerca del
sistema operativo, versiones de software, productos, etc. Para ver las cabeceras
utilic nmap y Netcat
nmap -O -Pn -n NOMBRE_DEL_HOST
1
La respuesta:

1
2
3 Starting Nmap 5.21 ( http://nmap.org ) at 2014-05-06 20:34 CEST
4 Nmap scan report for NOMBRE_DEL_HOST (X.X.X.X)
is up (0.049s latency).
5 Host
Not shown: 998 filtered ports
6 PORT
STATE SERVICE
7 80/tcp
open
http
8 Device type: general purpose|WAP|specialized
9 Running (JUST GUESSING) : Linux 2.6.X|2.4.X (87%), Linksys Linux 2.4.X (86%), Crestron
Aggressive OS guesses: Linux 2.6.22 (87%), Linux 2.6.23 (87%), OpenWrt White Russian 0
1 7.09 (Linux 2.6.22) (86%), Crestron XPanel control system (85%)
0 No exact OS matches for host (test conditions non-ideal).
11
1 OS detection performed. Please report any incorrect results at http://nmap.org/submit/
2 Nmap done: 1 IP address (1 host up) scanned in 13.12 seconds
1
3
1 nc -w 10 NOMBRE_DEL_HOST 80
2 HEAD / HTTP/1.0
La respuesta:

1
2
3
4
5
6
7
8
9
10
11
12
13

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 06 May 2014 18:39:17 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Vary: Accept-Encoding
X-Powered-By: PHP/VERSION+NOMBRE_DE_REPOSITORIO~NOMBRE_SO+1
X-Pingback: http://NOMBRE_DEL_HOST/xmlrpc.php
Link: <http://wp.me/3dPWl>; rel=shortlink
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Page-Speed: 1.7.30.4-3847
Cache-Control: max-age=0, no-cache

14
Como podis ver, se ve tanto el servidor (cabecera Server) como la versin de
PHP utilizada (cabecera X-Powered-By), de la que se poda deducir el
repositorio del que se instal y el sistema operativo del servidor.
Esta segunda cabecera es la que ms me preocup, ya que sabiendo la versin de
PHP y el sistema operativo utilizada en el servidor es ms sencillo
explotar vulnerabilidades. Investigando un poco averig que esa cabecera la
introduce PHP y desactivarla es tan sencillo como cambiar una linea del archivo de
configuracin php.ini.
Basta con buscar la linea expose_php=On y cambiarlo a expose_php=Off.
Tras ello, hay que reiniciar php-fpm y el servidor web
En cuanto a la cabecera Server, lo ms preocupante hubiera sido que mostrara
la versin, pero no me termina de gusta que muestre el servidor web utilizado. Mi
primer impulso fue ofuscarla, pero tras leer alguna discusin al respecto y leer las
implicaciones me convenc de que:
1. Seguramente ese dato se pueda obtener de otros modos.
2. Al ocultar la versin tampoco es una informacin especialmente
interesante.
Por lo que decid olvidarme de ello.

3.-Verificar los servicios visibles

El siguiente paso es comprobar que slo estamos exponiendo los servicios
deseados (tpicamente, el servidor web por los puertos 80 y 443). Para
comprobarlo podemos usar Nmap:
1sudo nmap -sV -n -Pn -p 80,443 NOMBRE_DEL_HOST

1Starting Nmap 5.21 ( http://nmap.org ) at 2014-05-06 20:52 CEST

2Nmap scan report for NOMBRE_DEL_HOST (XXX.XXX.XXX.XXX)
3Host is up (0.051s latency).
PORT
STATE
SERVICE VERSION
480/tcp open
http
nginx
5443/tcp filtered https
6
7Service detection performed. Please report any incorrect results at
8http://nmap.org/submit/ .
9Nmap done: 1 IP address (1 host up) scanned in 8.68 seconds
Vemos que slo estn accesibles los puertos del servidor web.

4.-Buscar vulnerabilidades

Utilizando herramientas ms avanzadas como Nikto y W3AF podemos automatizar

la bsqueda de vulnerabilidades e informacin interesante:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

larry@sobremesa ~ $ nikto -h NOMBRE_DEL_HOST

- Nikto v2.1.4
--------------------------------------------------------------------------+ Target IP:
XXX.XXX.XXX.XXX
+ Target Hostname:
NOMBRE_DEL_HOST
+ Target Port:
80
+ Start Time:
2014-05-07 21:14:16
--------------------------------------------------------------------------+ Server: nginx
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ robots.txt contains 1 entry which should be manually viewed.
+ ETag header found on server, fields: 0x52af7c7c 0x21
+ OSVDB-3093: /.htaccess: Contains authorization information
+ OSVDB-3092: /xmlrpc.php: xmlrpc.php was found.
+ /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up t
version
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ /wordpress/: A WordPress installation was found.
+ 6448 items checked: 41 error(s) and 7 item(s) reported on remote host
+ End Time:
2014-05-07 22:05:36 (3080 seconds)
--------------------------------------------------------------------------+ 1 host(s) tested

La salida de w3af es demasiado extensa como para ponerla aqu, pero utilizando
los perfiles predeterminados podemos obtener informacin muy valiosa para
mejorar la seguridad de la aplicacin.
Hay que tener en cuenta que herramientas como Nikto o W3af realizan muchas
peticiones HTTP para tratar de obtener informacin. Es muy adecuado tener
instalado algn Web Application Firewall o al menos un plugin que bloquee las
direcciones IP que realicen demasiadas peticiones en poco tiempo. De cara a
obtener la mayor cantidad de informacin posible, puede ser interesante
desactivar estas herramientas antes de lanzar las peticiones.

5.- Bloquear puertos de entrada y salida

Es imprescindible utilizar un Firewall para bloquear todos los puertos que no sean
necesarios. Si no se dispone de un Firewall corporativo, se puede
utilizar Iptables con el front-end ufw, cuya configuracin es muy sencilla.

6.- Ajustar los usuarios y permisos

Ficheros sensibles del sistema operativo

Aunque suene evidente, insistir en que todos los ficheros sensibles del sistema
operativo deben estar lo ms restringidos posible. Por ejemplo, un VirtualHost slo
debe ser ledo y escrito por root.

Ficheros de la aplicacin web

En muchas ocasiones tendemos a asignar los archivos de una aplicacin web al
usuario y grupo que ejecuta el servidor web ( en Linux suele ser www-data). Sin
embargo, esto no es realmente necesario y tiene sus riesgos desde el punto de
vista de la seguridad. No es necesario porque el usuario www-data debe tener
permiso para leer y, dependiendo de la tecnologa que
utilicemos,ejecutar determinados archivos. Es decir, salvo determinadas
excepciones el usuario www-data no tiene por qu tener permisos de escritura.
Por ello, se puede optar por separar el usuario de publicacin y el del servidor web.
Por ejemplo, los archivos podran pertenecer al usuario publicador y el
grupo www-data, teniendo el grupo permisos de lectura y ejecucin. De este
modo, si un atacante obtuviera el control del usuario www-data expotando una
vulnerabilidad de nuestra aplicacin no podra cambiar el contenido.
No obstante, hay situaciones en las que es interesante que el usuario www-data
tenga permisos deescritura sobre los archivos. Por ejemplo, WordPress permite
actualizar tanto el CMS como los plugins a travs de su interfaz web. Esta
funcionalidad es muy cmoda, pero lgicamente requiere que el usuario www-data
tenga permisos de escritura. En ese caso, cada responsable deber elegir entre
funcionalidad y mayor seguridad.

7.- Revisar la configuracin de HTTPS

Aunque todos usamos deberamos usar HTTPS, en muchas ocasiones aceptamos la
configuracin por defecto del software que utilicemos sin dedicarle mayor tiempo.
Sin embargo, conviene prestarle atencin a aspectos como:
Pedir a la CA que emite nuestro certificado que utilice SHA-2, ya que
SHA-1 quedar obsoleto en 2017. Adems, el certificado debe ser

de 2048b.
Revisar los algoritmos utilizados. Para ello, es interesante

utilizar TLSSLed.
Usar las cabeceras STS.

Evitar las redirecciones HTTP -> HTTPS, ya que son vulnerables a SSL

Strip.
Asegurarse de que el certificado utilizado es designado
como confiable por los navegadores. Esto implica utilizar autoridades
de certificacin (AC) cuyo certificado raz est incluido por defecto y

comprobar que el servidor web incluye los certificados de las AC

intermedias.

8.- Habilitar la conexin en dos pasos

Si el software utilizado lo soporta o si es factible desarrollarlo, es interesante exigir
autenticacin en dos pasos al menos para los perfiles ms privilegiados. En el caso
de WordPress est disponible el plugin Google Authenticator.

9.- Limitar la informacin que ofrece tu

aplicacin en lo relativo a contraseas
Pensemos en tres funcionalidades que tienen casi todas las aplicaciones pblicas:
1. Crear una cuenta.
2. Tratar de autenticarse con una cuenta.
3. Olvid la contrasea
Varias de ellas (o todas) permiten a un hipottico atacante saber si un correo
electrnico determinado est asociado a una cuenta:
Intento crear una cuenta => Ese correo electrnico ya est asociado

con una cuenta

Tratar de autenticarse con una cuenta => Esa cuenta no existe / Error

genrico
Olvid la contrasea => Se ha enviado un enlace etc etc / Esa

cuenta no existe
Para evitar dar ms informacin de la necesaria, se pueden configurar los
mensajes de error de modo que den la menor informacin posible:
Crear una cuenta => Responder siempre Se ha enviado un correo para

confirmar la creacin. Si ya existe, no hacer nada, o enviar un correo al

propietario legtimo de la cuenta avisando de la circunstancia.
Tratar de autenticarse con una cuenta => Si la autenticacin falla,

devolver un error genrico, no decir si la cuenta existe o no.

Olvid la contrasea => Decir siempre Se ha enviado un enlace para
resetear la contrasea, aunque la cuenta no exista.

Es cierto que estas medidas pueden disminuir la usabilidad de la aplicacin. Un

usuario legtimo podra pinchar en olvid mi contrasea pero equivocarse y meter
su correo electrnico mal. En ese caso, como la aplicacin ya no le avisa de
que el correo electrnico introducido es incorrecto, puede esperar indefinidamente
a ese correo. Como siempre, habr que valorar la importancia de la seguridad de la
aplicacin frente a su usabilidad.

10.- Configurar las cookies para que sean

httponly y secure
Al configurar la cookie como secure slo se intercambian entre el navegador y tu
aplicacin por https. Al marcarlas como httponly evitas que scripts accedan a la
misma, limitando las posibilidades de los ataques va cross-site scripting.

11.- Filtrar todo lo que venga del usuario y

utilizar consultas SQL compiladas
Todo campo de formulario puede ser utilizado para explorar vulnerabilidades.
SIEMPRE conviene filtrar el contenido introducido por el usuario
mediante expresiones regulares.
Adems, para tratar de evitar ataques por inyeccin SQL conviene utilizar
consultas compiladas (prepared statements). En este post de StackOverflow lo
explica muy bien.

12.- Utilizar un WAF

Un Web Application Firewall es una aplicacin que intercepta las peticiones
dirigidas a una aplicacin web. De este modo, antes de derivar la peticin se
ejecutan una serie de filtros que tratan de encontrar patrones comunes en
ataques. Por ejemplo, si un atacante enva muchas peticiones en poco tiempo, su
IP ser bloqueada temporalmente.
El ms popular en el mundo del software libre es mod_security. Sin llegar a su nivel
de potencia, en WordPress hay plugins como iThemes Security que tratan de cubrir
los puntos bsicos.

13.- Repetir las comprobaciones cada cierto

tiempo
Aunque tras un repaso se haya mejorado la seguridad de una aplicacin, en un
tiempo la situacin se habr vuelto a degradar. Esto es debido a actualizaciones de
software, vulnerabilidades que se descubran, el hecho de que a lo largo de la vida
de una aplicacin acceden a ella diferentes tcnicos, falta de recursos, etc.
Por ello es conveniente volver a auditar la aplicacin cada cierto tiempo. La
frecuencia depender de la criticidad de la aplicacin y de los recursos disponibles,
pero siempre se puede hacer una comprobacin rpida utilizando herramientas
que automaticen parte de las comprobaciones.

Herramientas utilizadas
Nmap y Netcat para examinar las cabeceras HTTP.
W3AF y Nikto para hacer un escner general de vulnerabilidades.
Phpsecinfo para comprobar la configuracin de una aplicacin PHP.
TLSSLed para verificar la configuracin de HTTPS.
Brutus para evaluar la calidad de las contraseas.
Sqlmap para buscar vulnerabilidades de tipo SQL Injection.

Fuentes:
http://www.raulsiles.com/
https://www.ccn.cni.es/
http://stackoverflow.com/questions/962230/hide-x-powered-by-nginx
http://serverfault.com/questions/214242/can-i-hide-all-server-os-info
https://gist.github.com/plentz/6737338
http://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html
https://www.modsecurity.org/
Si te ha gustado, comprtelo