Hacer compatibles las reglas de OWASP para los principales CMS nunca fue tarea fácil. La cantidad de falsos positivos era considerable, por lo que mod_security muchas veces bloqueaba tareas de lo más habituales: publicar un post, subir una imagen, editar un tema, etc… Hasta ahora uno de los métodos más utilizados -y tediosos- era configurar mod_security en modo de detección (SecRuleEngine DetectionOnly) e ir comprobando en los logs las reglas que daban falso positivo para irlas excluyendo o tuneando posteriormente.
Afortunadamente los compañeros de OWASP se pusieron las pilas para hacer más amigable el uso de WordPress y Drupal, creando unos perfiles específicos que customizan las reglas para evitar en gran medida todos esos falsos positivos que tantos quebraderos de cabeza nos daban.
En concreto, tendremos que habilitar la regla de exclusión 900130, que carga la variable de entorno crs_exclusions_wordpress=1. Basándonos en un sistema Debian, esto lo hacemos en el fichero /etc/modsecurity/crs/crs-setup.conf. Un poco de historia bajo el epígrafe Application Specific Rule Exclusions que no viene mal leer:
#
# -- [[ Application Specific Rule Exclusions ]] ----------------------------------------
#
# Some well-known applications may undertake actions that appear to be
# malicious. This includes actions such as allowing HTML or Javascript within
# parameters. In such cases the CRS aims to prevent false positives by allowing
# administrators to enable prebuilt, application specific exclusions on an
# application by application basis.
# These application specific exclusions are distinct from the rules that would
# be placed in the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS configuration file as
# they are prebuilt for specific applications. The 'REQUEST-900' file is
# designed for users to add their own custom exclusions. Note, using these
# application specific exclusions may loosen restrictions of the CRS,
# especially if used with an application they weren't designed for. As a result
# they should be applied with care.
# To use this functionality you must specify a supported application. To do so
# uncomment rule 900130. In addition to uncommenting the rule you will need to
# specify which application(s) you'd like to enable exclusions for. Only a
# (very) limited set of applications are currently supported, please use the
# filenames prefixed with 'REQUEST-903' to guide you in your selection.
# Such filenames use the following convention:
# REQUEST-903.9XXX-{APPNAME}-EXCLUSIONS-RULES.conf
#
# It is recommended if you run multiple web applications on your site to limit
# the effects of the exclusion to only the path where the excluded webapp
# resides using a rule similar to the following example:
# SecRule REQUEST_URI "@beginsWith /wordpress/" setvar:crs_exclusions_wordpress=1
#
# Modify and uncomment this rule to select which application:
#
#SecAction \
# "id:900130,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_wordpress=1"
Así pues descomentamos dicha sección para WordPress o Drupal. En este ejemplo utilizaré WordPress:
# # Modify and uncomment this rule to select which application: # SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_wordpress=1"
Si investigamos un poco más, vemos que en /usr/share/modsecurity-crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf tenemos la configuración de exclusión de reglas, únicamente efectiva si la variable crs_exclusions_wordpress=1 está cargada previamente como habíamos visto:
... # These exclusions remedy false positives in a default WordPress install. # The exclusions are only active if crs_exclusions_wordpress=1 is set. # See rule 900130 in crs-setup.conf.example for instructions. # # Note that the WordPress comment field itself is currently NOT excluded # from checking. The reason is that malicious content is regularly being # posted to WordPress comment forms, and there have been various cases # of XSS and even RCE vulnerabilities exploited by WordPress comments. ...
Como vemos Core Rule Set 3 ofrece una mayor compatibilidad de serie con WordPress/Drupal mediante la aplicación de la regla de exclusión 900130. Esto nos ahorra mucho tiempo de trabajo haciendo debug y seguimiento del comportamiento de nuestro CMS. Si no nos convence este método, siempre podemos volver como siempre a realizar nuestras pruebas en modo DetectionOnly para ajustar las reglas de forma manual a nuestras necesidades.