Seguridad de
proyectos PHP
Cómo evitar que
nuestros proyectos web sean atacados fácilmente.
Debido a los avances en nuestro medio tecnológico nos
encontramos con situaciones que nos amargan la existencia como por ejemplo:
cuando nuestras webs se caen, ingreso de virus a nuestra PC, spam en nuestros
correos, etc.
Surge un el término se empezó a utilizar en el año
2000 por Luis von Ahn, Manuel Blum y Nicholas J. Hopper de la Carnegie Mellon
University, y John Langford de IBM.
El sistema
captcha tiene las siguientes características por definición:
Son completamente automatizados, es decir, no es
necesario ningún tipo de mantenimiento ni de intervención humana para su
realización. Esto supone grandes beneficios en cuanto a fiabilidad y coste.
El algoritmo
utilizado es público. De esta forma la ruptura de un captcha pasa a ser un
problema de inteligencia artificial
y no la ruptura de un algoritmo secreto.
Pues habiendo visto un poco de lo que es captcha “Completely Automated Public T
uring test to tell Computers and Humans Apart (Prueba de Turing pública y
automática para diferenciar a máquinas y
humanos).
En este escenario, podríamos encontrarnos con dos
situaciones bien diferentes:
Tener un site
montado y tener que protegerlo.
Programar un
site desde cero.
Escape de las entradas Para muchos la manera ideal de
proteger un site.
Como ya hemos
visto en alguno de los casos no nos es útil. Los más habituales son el uso de:
addslashes()
/ stripslashes()
htmlentities($string,
ENT_QUOTES)
htmlspecialchars()
mysql_real_string()
Teniendo activadas las magic_quotes_gpc en nuestro php.ini, que nos pondrá por defecto un slash
\ en todos los strings (evitando los tediosos addslashes()) En todo caso,
el uso de dichos elementos nos podrá salvar de muchos de los ataques.
Evitar, salvo en casos necesarios, que los formularios
POST se llamen desde otro dominio que no sea el del propio servidor. En este
caso, nos evitaremos que un atacante avezado utilice un script a tal efecto
para ir bloqueando nuestro servidor y llenándolo de datos inútiles.
Vamos a ver ¿Qué
clase de configuración sería la óptima para que un sistema PHP fuera más seguro
contra todo tipo de ataques?
Estas directivas
serían:
openbase_dir
Esta directiva bien configurada evitará los ataques
trasversal directories, debido a que limita ejecución de ficheros al entorno
que escojamos.
allow_furl_open
off
Es importante que esta directiva esté en OFF para
evitar Remote File Inclusion, ya que la inhabilitación de esta directiva no
permitirá a la aplicación hacer include remotos.
register_globals
off
Como ya hemos explicado, quizá la más maléfica (y
obsoleta) forma de que nuestros atacantes desplieguen todo su potencial es
mediante esta directiva activada. Es decir, cualquier parámetroque nos venga
por POST o GET puede ser una variable potencialmente peligrosa en nuestroaplicativo.
Así, cualquier parámetro externo setratará de forma cuidad con $_GET['param'], $_POST['param'], $_FILES['param']
para establecer qué tipo de variables son externas y cuáles no. No se
recomienda, a no ser que se tenga muy claro qué se está haciendo, el uso de $_REQUEST, pues ahí puede entrar
'cualquier cosa' que nos venga externamente, y fácilmente podrían introducirnos
valores no esperados.
safe_mode on
Esta directiva activada evitará la ejecución de algunos
comandos potencialmente dañinos en nuestro sistema, además del chequeo de
ciertas funciones que puedan considerarse delicadas. Una lista de dichas
funciones puede encontrarse aquí:
Especial atención merecen también las directivas
“safe_mode*” que componen la familia.
safe
mode:
safe_mode_gid
safe_mode_include_dir
safe_mode_exec_dir
safe_mode_allowed_env_vars
safe_mode_protected_env_vars
Por último, unas funciones que, según la casuística de
nuestro aplicativo pudiera evitarnos algún susto por la ejecución de comandos
sensibles que no queremos (y no debemos) utilizar:
disable_functions
<lista de funciones>
disable_classes
<lista de clases>
Escaneo de puertos Una manera de evitar ataques a todo
sistema operativo, ya sea mediante web o mediante cualquier otro tipo de vulnerabilidad,
sería mediante la ejecución de código remoto o inyección de código no deseado
en servicios que puedan tener relación con nuestro sistema.
Para ello se recomienda ejecutar un escaneo de puertos
de nuestra máquina (no únicamente puerto 80-http o 443-SSL) para averiguar las posibles
vulnerabilidades o exploits que puedan afectar a nuestro sistema y servidor
web:
Los más conocidos son nmap y nessus. El funcionamiento de nmap puede llegar a ser sencillo,
aunque tiene un despliegue de opciones que de buen seguro mucha gente
encontrará interesante.
Una ejecución de este programa puede dar lugar a un
resultado como este:
Starting
Nmap 4.53 ( http://insecure.org ) at
20080603
12:05
CEST
Interesting
ports on 192.168.1.1:
Not
shown: 1711 closed ports
PORT
STATE SERVICE
21/tcp
open ftp
23/tcp
open telnet
80/tcp
open http
MAC Address:
00:02:CF:81:6F:89 (ZyGate
Communications)
Nessus, en cambio, nos ofrecerá una herramienta
cliente/servidor que utilizará una base de datos con las vulnerabilidades que estadísticamente
han podido ocasionar “desastres” y nos avisa mediante este escaneo.
La interfaz, además, es bastante más amigable y nos
mostrará unas estadísticas de los procesos ejecutados.
Escaneo de
vulnerabilidades web
Más en consonancia con el objetivo de este artículo,
están los escaneos de vulnerabilidades propiamente web. Estos escaneos se
pueden basar en varias premisas, empleando sistemas de conocimiento, funciones
heurísticas e incluso técnicas fuzz, que veremos más adelante. Una buena combinación de estos elementos puede
darnos muchas pistas a la hora de proteger nuestro site y llegar donde nosotros
no alcanzamos. Empecemos por los escaneadores automáticos más empleados y
populares.
Acunetix
Acunetix, que goza de una versión Free Edition (sólo para HTML Injection),
pero con una gran variante de sistemas de inyección, una base de datos amplia y
una interfaz muy amigable. Los procesos por los que puede “atacarse” pueden ser
varios y los perfiles de ataque – si se tiene la versión de pago – de los más
variopintos, muchos de ellos ya los hemos visto aquí.
SSS (Shadow
Security Scanner)
Similar al anterior en cuanto a sistema web (quizá no tan completo) pero que ofrece también el sondeo
de otros protocolos como FTP, NetBios, módulos de Apache del que se tengan constancia
que hay vulnerabilidades.
Técnicas Fuzz
Se llama fuzzing a las diferentes técnicas de testeo de aplicativos que generan datos secuenciales
y aleatorios para obtener así las vulnerabilidades de la victima. Este
sistema de testeo puede ser muy potente pues combina la aleatoriedad en los
ataques con ataques basado en formatos heurísticos. Una lista de estos potentes
escaneadores de vulnerabilidades pueden encontrarse en:
Un ejemplo lo podemos tener ejecutando el WebFuzzer,
con licencia GPL, escrito en C:
PHP IDS
PHP-IDS es un sistema basado en PHP que actúa como IDS
(Intrusion Detect System) y que se aplica a todos nuestros archivos buscando
algún tipo de inyección o vulnerabilidad. Puede detectar desde XSS, SQL
Injection, RFI y ataques LDAP Injection y tiene incluso hasta módulos
especializados para distintos tipos de CMS.
Módulos Apache
De entre ellos, existen muchos que nos pueden ayudar a
nuestro cometido, aunque nos centraremos en los siguientes:
mod_rewrite
Famoso sobre todo para el uso de URL-Friendly, pues reescribe la entrada transformándola en otras “Human
readibility”. Personalmente recomiendo el uso de mod_security, debido a que mod_rewrite
tiene lógicas limitaciones al no ser un módulo diseñado a tal efecto.
Conclusión
No es un caso trivial tener que proteger un site web,
tanto si ya está hecho como si lo tenemos que desarrollar de nuevo. La única
forma de obstaculizar el ejercicio de estos atacantes será conocer cuáles son
sus técnicas, mantenerse actualizado regularmente de las vulnerabilidades de
nuestro entorno (Sistema Operativo, Lenguaje,
base de datos y módulos y librerías asociados), en caso de ser un programa
conocido (como un WordPress, Joomla!, PostNuke) mantenerse alerta a los
bugs que, altruistamente, algunos atacantes publican en webs.
Además, con un sistema
IDS que nos pueda ir comunicando qué pasa con nuestros logs, la evolución
de estos mismos y la constante evaluación de las vulnerabilidades de nuestro sistema,
junto con un escaneo automático, técnicas
fuzz y una programación sólida, y algún módulo destinado a la seguridad
harán de nuestro servidor web una fortaleza (casi) inexpugnable.
0 comentarios:
Publicar un comentario