OWASP (Open Web Application Security Project) es una metodología de seguridad de código abierto y colaborativa que se utiliza como referente para auditorias de seguridad de aplicaciones web. En este artículo, explicamos cómo implementar OWASP desde un punto de vista práctico, sobre WordPress, el gestor de contenidos más utilizado para prácticamente cualquier proyecto en Internet.
Este sistema permite garantizar que la revisión de seguridad de un proyecto web se realiza de forma adecuada, asegurando que analizamos todos los puntos clave para detectar cualquier fallo de seguridad.
OWASP TOP 10
El más famoso de los proyectos de esta metodología es conocido con el nombre OWASP TOP 10, que no es más que un listado de los problemas de seguridad más comunes en las aplicaciones web y ordenados de más a menos críticos.
- A1: Inyección
- A2: Pérdida de autenticación y gestión de sesiones
- A3: Datos sensibles accesibles
- A4: Entidad externa de XML (XXE)
- A5: Control de acceso inseguro
- A6: Configuración de seguridad incorrecta
- A7: Cross site scripting (XSS)
- A8: Decodificación insegura
- A9: Componentes con vulnerabilidades
- A10: Insuficiente monitorización y registro
Con este gráfico, podrás tener OWASP TOP 10 siempre presente:
Cómo aplicar OWASP en WordPress
Aunque se puede aplicar a cualquier proyecto, a continuación, vamos a ver un ejemplo de cómo usar OWASP TOP 10 en un WordPress, por ser uno de los CMS más utilizados en la Web.
A1 – Inyección
Los parámetros de entrada mal gestionados, dentro de la programación, pueden provocar una vulnerabilidad que permita a un hacker inyectar información en una base de datos o a un intérprete. Las medidas a tomar serían las siguientes:
- Contraseñas robustas
- Versiones seguras de WordPress (ojo a las últimas actualizaciones)
- Plugins seguros, actualizados, compatibles con la última versión de WP y originales
- Temas seguros y originales
- Usuarios y prefijos de las BBDD que no sean por defecto
- Moderación de los comentarios y un complemento que evite SPAM (Akismet)
- Un hosting WordPress que tenga buenos sistemas de seguridad.
- Hosting con versiones seguras de software y WAF (Web Application Firewall). También se recomienda la instalación del plugin Wordfence.
- Permisos 400 en archivos sensibles (.htaccess, wp-config.php)
- wp-config.php ubicado en un directorio superior
- Desactivar la ejecución php
El siguiente código de.htaccess, evita el listado de archivos, scripts y cadenas GLOBALS o _REQUEST que intenten inyectar código:
Options -Indexes Options +FollowSymLinks RewriteEngine On RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) RewriteRule ^(.*)$ index.php [F,L]
Y con este el archivo .htaccess y otro adicional en uploads, content, wp-includes, y carpetas de caché de plugins y temas, evitamos la ejecución de php:
<FilesMatch “\.(php|php\.)$”> Order Allow,Deny Deny from all </FilesMatch>
A2 – Pérdida de autenticación
Cuando las claves no se protegen convenientemente, un atacante puede aprovechar vulnerabilidades para entrar y robar la información sensible. Es fundamental tener esto en cuenta:
- Contraseñas robustas
- Versiones seguras y originales de todo
- No dejar nada por defecto
- Definir las secret_keys de wordpress en wp-config.php. Recuerda que suelen venir en blanco y es necesario crearlas. Podemos copiar las que nos ofrece esta página (aleatoria cada vez que la ejecutemos).
- Ocultar los errores de login
- Utilizar únicamente dos administradores
- Usar Doble verificación
Con el siguiente código sobre el archivo functions.php evitaremos que WordPress muestre los errores de acceso:
add_filter('login_errors',create_function('$a', "return null;"));
El archivo wp-config.php contiene información sensible, pero añadiendo lo siguiente a .htaccess evitamos su acceso:
<files wp-config.php> order allow,deny deny from all </files>
A3 – Exposición de datos sensibles
Es importante que las transacciones sean PCI compliance (Payment Card Industry Compliance) o en español “Cumplimiento de la industria de tarjetas de pago”, unos estándares de seguridad para proteger los datos de los dueños de tarjetas de crédito durante, y después, de una transacción online. Las medidas a tomar:
- Aplicaremos A1 y A2
- RGPD (Reglamento General de Protección de Datos)
- Hosting RGPD y PCI compliance
- Gestionar permisos de los usuarios
- Eliminación de datos sensibles
- SSL = HTTPS
A4 – Entidades externas XML (XXE)
Las inyecciones de entidades externas son un tipo de ataque contra una aplicación que analiza las entradas XML y se combaten con software que no use parsers (analizadores de sintaxis externos). En PHP podemos evitar parsers con este código:
libxml_disable_entity_loader(true);
Y las medidas a implementar serían las siguientes:
- Software original y reconocido
- No incluir parser XML
- No incluir parsers en PHP
- No cargar extensiones externas (XMLWRITER, DOM, XMLREADER)
A5 – Control de acceso roto
Los atacantes utilizan herramientas SAST y DAST para detectar vulnerabilidades en el acceso, ya sean por medios manuales o automáticos. Sin embargo, si A1 y A2 están correctamente implementados, no deberíamos preocuparnos de este paso. Haríamos lo siguiente:
- Aplicar A1 y A2
- Desactivar XML-RPC
- Inspeccionar las llamadas de las APIs (JSON REST API)
- Disponer de copias de seguridad (All-in-One WP Migration)
Con el siguiente código sobre el archivo .htaccess podemos suprimir totalmente XML-RPC:
<Files xmlrpc.php> <IfModule mod_authz_core.c> Require all denied </IfModule> <IfModule !mod_authz_core.c> Order allow,deny Deny from all </IfModule> </Files>
Opcionalmente podríamos utilizar este otro código, también sobre .htaccess:
RewriteCond %{REQUEST_METHOD} ^(GET|POST|PUT|PATCH|DELETE) [NC] RewriteCond %{REQUEST_URI} ^.*wp-json/wp/ [NC] RewriteRule ^(.*)$ - [F]
Si el servidor que tenemos es NGINX, podemos utilizar este código en el archivo de configuración:
location = /xmlrpc.php { deny all; }
A6 – Configuración de seguridad incorrecta
Aunque esta configuración se aplica a lo anteriormente visto, sobre todo a la exposición de datos y a la protección de usuarios, cuenta con unas medidas concretas:
- Aplicar A1 y A2
- No utilizar nada por defecto, incluido en el ordenador, router o móvil
- Utilizar los siguientes permisos para archivos y carpetas: 650 para archivos, 750 para carpetas y 400 para .htaccess y wp-config.php
A7 – Secuencia de comandos en sitios cruzados (XSS)
XSS es un vector de ataque que los hackers utilizan para robar información, hacerse con las sesiones de los usuarios y poner en riesgo el navegador, dejando vulnerable la integridad del sistema.
Tener en cuenta validar todo:
- is_numeric()
- preg_match()
- filter_var()
- in_array()
Sanear todo:
- sanitize_email
- sanitize_file_name
- sanitize_html_class
- sanitize_text_field
- sanitize_textarea_field
- esc_url_raw
- sanitize_option
- sanitize_meta
- wp_kses
- sanitize_key
- sanitize_user
- sanitize_mime_type
- sanitize_title
- wp_filter_post_kses
Escapa todo:
- esc_html
- esc_url
- esc_js
- esc_attr
- esc_textarea
A8 – Deserialización segura
La deserialización o también llamada decodificación, debe ser segura, ya que puede ocasionar la ejecución de código malicioso. Afecta a todo el WordPress, cachés, BBDD y tokens de APIs.
A tener en cuenta:
- Aplicar A1
- Mantener el CMS actualizado
- Implementar controles de integridad como firmas digitales en cualquier objeto serializado
A9 – Uso de componentes con vulnerabilidades
Es un problema muy extendido y es posible que los equipos de desarrollo ni siquiera entiendan qué componentes usan en su aplicación o API, por lo que determinar las vulnerabilidades requiere un esfuerzo añadido. Las recomendaciones para este punto se podrían resumir en:
- No alojarse en hostings no seguros
- No utilizar software con vulnerabilidades conocidas o que han sido discontinuados.
Algunas páginas para comprobar vulnerabilidades en nuestro sitio:
- https://wpscans.com/
- https://sitecheck.sucuri.net/
- https://wpvulndb.com/
- https://www.pluginvulnerabilities.com/
A10 – Registro y monitoreo insuficientes
El registro y monitoreo insuficiente de cualquier sistema, proporciona múltiples puertas traseras e infracciones que pueden ser difíciles de identificar y resolver si no existe un seguimiento eficaz.
Debemos encontrar cualquier código vulnerable que afecte al sistema:
- Código ofuscado
- Código base64
- Llamadas al sistema (exec, passthru, system, shell_exec, etc.)
- Ejecuciones de código PHP (eval, assert, preg_replace, etc.)
- Exposiciones de información (phpinfo, getenv, getmygid/pid/uid, etc.)
- Funciones del sistema de archivos (fopen, bz/gzopen, chgrp/own/mod, etc.)
- RGPD (plugin)
Técnicas de Auditoría Web
El objetivo de la revisión para la seguridad completa de una Web, es validar todos los controles definidos por la metodología OWASP, centrándonos en errores críticos y ayudando a proteger un sistema frente a ataques informáticos.
La revisión se puede realizar tanto manualmente, como a través del uso de aplicaciones automáticas o semiautomáticas. Además, las aplicaciones Web pueden ser analizadas desde dos puntos de vista diferentes:
Caja negra: no se conoce la infraestructura, no existen usuarios y con la revisión centrada en el análisis de las partes accesibles que son anónimas.
Caja blanca: la revisión es mucho más profunda porque se conoce más la plataforma y se controla el acceso de los usuarios a la zona privada.
OWASP ofrece un modelo estandarizado y preciso de seguridad preventiva y activa para cualquier página web. En pocos puntos nos enseña a revisar cuatro aspectos clave: seguridad preventiva, servidores y software de confianza, permisos apropiados y constante monitorización.