Mod Security y Webpay

Para operar con Webpay, necesitamos instalar una aplicación en nuestros servidores llamado KCC. Esta instalación puede llegar a ser no muy agradable para muchos, ya que esto puede tomar horas, días y hasta semanas para que quede funcionando al 100%. ¿El motivo? pueden ser varios: configuración de apache, php, permisos, llaves, etc. Pero uno de los más complejos es la compatibilidad con uno de los módulos de apache, el famoso mod_security. Ya con el hecho de concluir de que "es el responsable de hacer que siempre falle la transacción, haciéndonos caer en la famosa página de fracaso" es un gran logro, más aún cuando usas un hosting que por defecto lo tiene activado y uno no tiene idea de ello. Por lo tanto, ya sabiendo esto, una posible solución es simplemente desactivando el módulo, pero si quieres tener tu sitio protegido ante ataques entonces tendrás que dar con la regla indicada del mod_security para hacer funcionar Webpay y eso es lo que intentaremos hacer aquí.

Entendiendo el problema

Antes de dar a conocer las posibles reglas, tenemos que entender el flujo de la transacción, entre nuestro servidor y el de Webpay y en que parte mod_security hace lo suyo impidiendo que la transacción se complete. Todo ocurre después de que el usuario, al ingresar su número de tarjeta y otros datos en la página de Webpay, da en continuar o pagar. El proceso es el siguiente:

1. Usuario en Webpay ingresando datos de su tarjeta.
2. Usuario presiona pagar
3. El sistema Webpay hace un POST a tbk_bp_resultado.cgi de nuestro servidor
4. tbk_bp_resultado.cgi (ya local en servidor) hace un POST a nuestra página de cierre
5. Esta página responde ACEPTADO o RECHAZADO a tbk_bp_resultado
6. tbk_bp_resultado le responde a Webpay
7. Se termina la Transacción, se redirecciona a la página de éxito o fracaso (Este porque realmente la tarjeta no tiene cupo.)

Este proceso es lo que debe ocurrir para completar con la transacción, pero mod_security podría hacer lo suyo en el punto 3, digo podría porque mod_security por si mismo no provoca el problema, sino que son las reglas que se tienen configuradas.
Puede ser que el servidor tenga una regla que si la solicitud enviada al servidor no cuenta con la cabecera Accept, entonces no le da acceso. Para dar un ejemplo, si ingreso a tbk_bp_resultado.cgi directamente desde el browser, el sistema detectará la siguiente información:

Y me dará acceso debido a que tengo la cabecera Accept
¿Pero que sucede cuando es Webpay quien ingresa a tbk_bp_resultado.cgi? Esto es lo que se registra:

Aquí nos damos cuenta que existen menos datos que en el anterior y que no se encuentra la cabecera Accept, por lo tanto la regla de mod_security entra en acción y le retorna inmediatamente un error 403 u otro según la configuración.

Esto hace que en nuestros logs de KCC solo llegue hasta "Todo OK", faltando todo lo que debe suceder con la página de cierre.

Ya teniendo claro esto entonces se concluye de que necesitamos hacer algo para que dicha regla no le afecte a Webpay, para ello necesitamos crear una regla que si la IP del solicitante es Webpay entonces que no se le apliquen las reglas. Las IP's están publicadas en el manual, son las siguientes:

• Ambiente de Certificación
  • 200.10.12.55
• Ambiente de Producción
  • 200.10.14.162
  • 200.10.14.163
  • 200.10.12.162
  • 200.10.12.163
  • 200.10.14.34
  • 200.10.14.177

Incluso pueden aprovechar de crear una regla que solo estas IP's pueden hacer POST a tbk_bp_resultado.cgi.

¿Estamos listo para configurar las reglas en nuestros servidores? Aún no

Mod security puede no parar hasta aquí, con esto solo logramos hacer que Webpay le pueda hacer POST a tbk_bp_resultado.cgi (Punto 3), ahora tenemos que analizar el punto 4, cuando tbk_bp_resultado.cgi quiera hacerle POST a la página de cierre. ¿Qué se detecta aquí cuando se hace POST?

POST http://midominio.com/pagina-cierre.php HTTP/1.0
Content-type: application/x-www-form-urlencoded
Content-length: 1733

Esto es peor, tiene menos datos en la cabecera, no tiene Accept ni Host, aquí mod_security construye la mejor muralla posible para que no pueda acceder el solicitante (el tbk_bp_resultado.cgi como localhost). Por lo tanto podemos usar la misma lógica anterior, si el solicitante tiene IP del localhost, que no aplique las reglas. Otra opción es si la solicitud se hace a la pagina-cierre.php entonces que también elimine las reglas. Si no abordamos este problema, los logs de KCC terminarían así:

...	Medio 2: Por redireccion
...	Redireccion web
...	Todo OK (Hago POST a tbk_bp_resultado.cgi y pude acceder!!.- Webpay)
...	TBK_PARAM desencriptado
...	Entidad emisora de los datos validada
...	Parseo de los datos
...	http://midominio.com/pagina-cierre.php
...	conectandose al port :(80)
...	Abrio socket para conex-com
...	POST a url http://midominio.com/pagina-cierre.php (Intento ingresar pero no tengo acceso!! .- tbk_bp_resultado.cgi)
...	mensaje enviado
...	tienda NO acepto transaccion
...	respuesta enviada a TBK (ERR)
...	Error al obtener ack (46)
...	46

Ya identificado esto estaríamos listo para implementar las reglas de oro.

Mod_Security versión 1

No he podido probar esta versión, si alguien tiene la solución, se agradecería el aporte

Mod_Security versión 2

Para esta versión tuve que crearme el escenario en Ubuntu 12.04, tuve que instalar el mod_security. Debo indicar que apenas lo instale y lo active no tuve ningún problemas para usar Webpay, esto porque aún no habían reglas tan estrictas, para ello instale OWASP ModSecurity Core Rule Set (use como referencia ésta página para la instalación), con esto deje mi servidor apache protegido hasta los dientes, haciendo que ya me dejará de funcionar Webpay. Ya que una de las las reglas pide que la solicitud debe tener la cabecera Accept y Host para dar acceso, algo que no sucede con Webpay.

NOTA: Las siguientes reglas (código) se crearon en un archivo .conf ubicado en /etc/modsecurity/, directorio que estableció la instalación del módulo. Creo que sería distinto aplicarlo en .htaccess

Regla para dar acceso a Webpay a tbk_bp_resultado.cgi

Con esto estamos diciendo que si el solicitante tiene la IP 200.10.12.55 entonces que permita el acceso y que el motor de reglas se apague. Listo, con esto Webpay (en certificación), lograría entrar a tbk_bp_resultado.

Regla para dar acceso a tbk_bp_resultado.cgi a la página de cierre.

Primero se probó si dándole acceso a la IP localhost podría acceder sin problemas a la página de cierre pero no resultó. Desconozco el motivo, quizás por el hecho de no contar con la cabecera Host, le era imposible hacer coincidir con esta regla. Es por ello que se probó con REQUEST_URI, dando acceso cuando se ingresa a la página de cierre permitiendo que tbk_bp_resultado.cgi ingrese, sin embargo no solo a este sino que a todos los solicitantes, por lo tanto no creo que sea la solución definitiva.

Resultado

Con esto pude hacer funcionar Webpay nuevamente, pero no podría asegurar si es la mejor forma, mod_security es gigante, tiene muchas configuraciones para mejorar la seguridad. Es por ello que si cuentas con otras reglas, métodos y/o sugerencias sería de mucha ayuda poder recibirlas y adjuntarlas en este análisis para hacer compatible de la mejor forma mod_security con Webpay.