¿Pueden las siguientes reglas de .htaccess evitar este ataque?

Debería estar arreglando el código que causa el problema, en lugar de tirar cosas y esperar que bloquee las cosas maliciosas. Tu .htaccess bloquea el acceso a / proc, lo cual es bueno, pero no es lo único que quieres proteger. La lista negra como esta no lo llevará lejos, ya que hay docenas de otros directorios que desea proteger, y cuáles son los que dependen del sistema operativo y la configuración del servidor.

Parte del ataque del que ha sido víctima implica el recorrido de la ruta, es decir, salir de la raíz web al enviar una ruta relativa en un parámetro de cadena de consulta que de alguna manera se convierte en un nombre de archivo. Para arreglar esta parte, revise la base de código completa para las cadenas que se usan como nombres de archivo (esto incluye las declaraciones include y require ), y desinfecte esas. Los peores casos son aquellos en los que el nombre de archivo se usa para ejecutar un archivo como código PHP (intencionalmente o no), pero un file_get_contents inocente puede ser suficiente para formar un riesgo de seguridad (por ejemplo, cuando un atacante puede engañarlo para que sirva un archivo que contenga contraseñas de la base de datos).

A continuación, verifica todas las partes de tu código base que usan cadenas como código ( eval y amigos). Es mejor eliminarlos por completo: casi nunca se necesitan, y el precio que pagas por la comodidad percibida no vale la pena.

Luego está XSS; desea asegurarse de que todo lo que envíe al cliente esté codificado correctamente como HTML. Cualquier cadena que extraiga de la base de datos debe considerarse texto, y enviarla sin convertirla a HTML primero es claramente errónea y peligrosa. Verifique todo en su código que produzca resultados (que generalmente es mucho) y asegúrese de que todas las cadenas dinámicas estén codificadas correctamente ( htmlspecialchars() lo hace por usted). Es importante tener una comprensión clara de cuáles de sus cadenas son texto y cuáles son HTML, mientras que usar una como la otra técnicamente funciona, es, de nuevo, incorrecto y peligroso.

La inyección SQL es otra fruta de baja pendiente para los atacantes. La forma en que intenta protegerse es popular, pero muy ineficiente. Falla en varias cuentas: hay muchos trucos que puedes usar para seguir inyectando SQL sin usar ninguna de las cadenas en la lista negra, y cuanto más te pongas en la lista negra, mayor será la posibilidad de falsos positivos. He visto a personas bloquear las comillas simples por completo como parte de la prevención de inyección SQL, con el resultado de que era imposible encontrar clientes llamados O'Brien (de los cuales había varios). Para resolver correctamente la inyección SQL, asegúrese de que todas sus consultas estén parametrizadas. Desafortunadamente, la API mysql_XXXX () de la vieja escuela no los admite, por lo que las personas simplemente concatenan las consultas, lo que, de nuevo, es incorrecto y peligroso. Estoy hablando de cosas como estas: mysql_query("SELECT * FROM foo WHERE bar = '$baz'"); . Dado que PHP ofrece tanto la interfaz mysqli como la API de PDO, realmente debería usar estos y proporcionar todos los valores dinámicos como parámetros a su consulta. La biblioteca MySQL subyacente se encargará de todos los procesos de escape y protección por usted.

También es muy importante: la configuración de PHP. Desactive register_globals (la configuración más peligrosa que he visto), magic_quotes (no hace más que sugerir una falsa sensación de seguridad y una excusa para escribir código descuidado), revise las recomendaciones de php.net en sí mismas.

Y: permisos de archivo. Asegúrese de que su servidor web tenga acceso de solo lectura a sus scripts, acceso de escritura solo a directorios específicos donde sea absolutamente necesario y ningún acceso a los archivos que no necesita.

Además, ponga un .htaccess con Deny From All en él en todos los directorios de los que no quiera servir. Tenga en cuenta que esto no impedirá que el servidor web acceda a esos archivos, pero provocará que apache ignore las solicitudes que se resuelven directamente en cualquiera de estos directorios; aún puede include desde allí, o leer datos de los archivos en ellos. simplemente no se pueden solicitar desde el exterior.

Y finalmente, una cosa más general que hacer: revise todos los puntos donde ingresan datos no confiables ($ _POST, $ _GET, $ _COOKIE, partes de $ _SERVER, y todo lo que provenga de la base de datos no es confiable en este contexto) , y seguir su camino. Vea si en algún momento es posible el abuso.

Si tiene el presupuesto, también debe considerar una auditoría profesional: un pirata informático calificado podrá investigar rápidamente los agujeros de seguridad restantes y decirle cómo solucionar sus problemas específicos.