Hace algunos días infectaron un servidor con un malware (ver https://blog.manchestergreyhats.co.uk/2018/11/07/php-malware-examination/), entonces llegue al blog de Jeff Starr (@perishable), en donde vi la siguiente entrada: https://perishablepress.com/protect-post-requests/.

Me llamo mucho la atención el poder ejecutar un script desde un .htaccess con la directiva ErrorDocument, así:

ErrorDocument <3-digit-code> <action> 

Segun la entrada, ejecuta el script sí el retorno de la petición es 403 o 404

ErrorDocument 403 /error-handler.php
ErrorDocument 404 /error-handler.php

Aquí es donde entra mi duda, entiendo que los codigos de respuesta 403 (Forbidden) y 404 (Not Found), pero si existe algun malware oculto en un archivo que si exista y se encuentre digamos index.php, como podría ejecutar el script si la petición arroja un codigo 200 (OK)?

La entrada de Jeff solo guarda peticiones POST por medio de file_get_contents('php://input'), necesito esto tanto como para POST y para GET. Alguna idea?

Concuerdo con MinusFour, ese tipo de cosas no se recomienda validar desde el lado de la aplicación en php ya que una aplicación web solo debiera dedicarse a funcionar como servicio y nada mas, todos los puntos de control de seguridad adicional que no sea para mitigar una vulnerabilidad ya existente debiera hacerlo un waf, en este caso mod security por ejemplo.

Desde el apache puedes configurar que user agent quieres denegar, rangos de direcciones ip, cabeceras extrañas, peticones mal formadas, limpieza de variables, etc. Ten en cuenta que Apache carga las reglas en memoria, en cambio php debe leer e interpretar tus reglas y modificaciones cada ves que un usuario accede al sitio, por lo cual apache es mucho mas rápido y eficiente en el uso de memoria porque está diseñado para ello, no así php.

En Apache puedes configurar reglas de dos maneras, utilizando el htaccess o el host virtual. El .htaccess sólo sirve cuando necesitas especificar configuraciones muy puntuales para una aplicación web como por ejemplo el sistema de ruteo con mod rewrite, la ruta de los archivos de errores por defecto, etc, pero las configuraciones persistentes que ya no debieran depender de una aplicación específica como las reglas de seguridad debieran estar en el host virtual ya que estas se cargan una sola ves ahorrando latencia en las peticiones.

Por otro lado, tu primer link está caido, por otro lado debes tener en cuenta que debes atacar el problema raiz y es corregir la vulnerabilidad que se usó para hackear el sitio y darle un vistazo mas a profundidad sobre lo que pasó.

Saludos.

Lo mejor sería que no fuera parte de un script como resultado de una petición, sino que el servidor maneje todo esto por tí. Mod Security puede guardar las peticiones completas.

Por lo pronto, lo que puedes hacer es revisar los access logs por las URLs por la cual se acceden al backdoor. Con un poco de suerte hay información en común para encontrar como metieron el backdoor o por lo menos inspeccionar que estaban haciendo antes de usar el backdoor.

En el caso de wordpress, debe ser posible agregar logs a través de un plugin. Lo único es que estás limitado solo al acceso por medio de wordpress. No se si wordpress tenga "early hooks" para colgarse antes de todos (por si algo falla antes de ejecutarse el plugin), pero yo empezaría por ahí.

No es eso, solo me contrataron pero no me dieron todos los permisos, solo puedo editar y subir archivos por ftp. Por eso quiero hacer algo simple mi propio log de peticiones.