Inyección remota de archivos en la base de datos de actualización de formularios ARGS

1

Estoy prohibiendo una página porque mod_security la bloquea con la Inyección de archivos remotos en la regla ARGS.

¿Cómo puedo detener esto aparte de no incluir las URL en los campos del formulario o eliminar el prefijo http: // de la URL antes de enviarlo al script de actualización (los datos se actualizan desde el formulario)?

La empresa de alojamiento tuvo que eliminar algunas reglas para evitar que esto suceda antes, pero incluso después de volver a escribir los formularios, sigue ocurriendo.

¿Cómo reescribo el formulario para detener el error del firewall?

    
pregunta Dwight Walker 23.04.2013 - 17:47
fuente

2 respuestas

1

Supongo que los hosts utilizan el conjunto de reglas mod_security de Atomicorp. El error "intento de inyección remota de archivos en ARGS" se documenta aquí ; Puede ver el código aquí .

Esta regla no permite la entrada que se parece a una URL de todos los campos, en el supuesto de que cualquier mención de una URL sea un intento de que la aplicación obtenga y ejecute el contenido de esa URL. Esto es muy improbable y bastante inútil, pero nadie dijo que los WAF eran inteligentes.

Debido a que naturalmente esto rompe casi todos los sitios, la regla incluye un montón de excepciones para aplicaciones web de uso generalizado. Parece que si pones una cadena que se parece a una aplicación conocida en tu URL (por ejemplo, jomsocial/x/add ), o si usas el nombre de parámetro de una aplicación conocida para tu URL (por ejemplo, origin ), probablemente puedas evadir la regla . Por supuesto, la lista de excepciones contiene muchas aplicaciones que en realidad han sufrieron varios agujeros de seguridad graves, pero nadie dijo que los WAF eran inteligentes.

En general, los WAF como este y otros conjuntos de reglas complejas de mod_security no son tan buenos como la protección contra intrusiones para aplicaciones web de uso general. Necesitan una configuración específica para reconocer qué entrada es y qué no se espera, y para las aplicaciones personalizadas usted mismo escribió que el esfuerzo involucrado en hacer esa configuración generalmente se gasta mejor asegurándose de que la entrada se maneje adecuadamente en la propia aplicación.

(Pueden ser útiles para la detección de intentos de intrusión y para solucionar problemas en el software de otra persona que no puede cambiar, o como medida temporal hasta que pueda solucionarlo correctamente. Pero implementarlo de forma generalizada contra software personalizado aleatorio es no es sensato, y reescribir el software personalizado para evitar los bloques WAF no es realmente productivo o sostenible.)

Si su empresa de alojamiento insiste en usar una instancia de mod_security fuera de su control para bloquear la entrada de aplicaciones perfectamente válida, buscaría una empresa de alojamiento con más inteligencia.

    
respondido por el bobince 24.04.2013 - 00:21
fuente
0

Pídale a su proveedor que se asegure de usar modsecurity 2.7.3 o superior, y que han habilitado esta opción:

--enable-htaccess-config

Cuando compilaron el DSO modsecurity de Apache.

Esto te permitirá deshabilitar esta regla y otras reglas, usando .htaccess. El formato para deshabilitar una regla en .htaccess, siempre que esté habilitado, se documenta en la siguiente URL:

enlace

    
respondido por el Mike Shinn 04.05.2013 - 23:01
fuente

Lea otras preguntas en las etiquetas