2011-11-22 14 views
8

Estoy auditando mi sitio web con w3af.Asegurar mi sitio

Dice que encontró varios problemas en mi sitio, pero dudo que ese sea realmente el caso.

Uno de los temas es:

El URL: http://localhost/en/login es vulnerable a la petición en sitios cruzados falsificación. Permite al atacante intercambiar el método de POST a GET cuando envía datos al servidor.

Estoy bastante seguro de que no es vulnerable a un ataque csrf ya que he utilizado la protección crsf en mis formularios (campo con token que se comprueba).

Así que me pregunto ¿cuál es este mensaje sobre: ​​

Permite al atacante para intercambiar el método de POST a GET al enviar datos al servidor.

No me importa si un atacante sería capaz de cambiar de POST a GET o hacer?

Y si lo hago, ¿me pueden explicar por qué lo hago? ¿Cómo puede ser explotado?

+0

¿Está utilizando $ _REQUEST en esa forma, en lugar de _POST? –

+0

@MarcB: Sí, lo soy. Pero no veo cómo eso sería explotable (teniendo en cuenta el campo de prevención csrf). – PeeHaa

+0

@Macmade: ¿me pueden explicar por qué me importa? – PeeHaa

Respuesta

3

Viniendo desde el punto de vista de la falta de experiencia con w3af, supongo que tiene algunas reglas bastante básicas escritas en él y comprueba esas reglas e informes sobre ellas.

En este caso es probable que comprobar si ha utilizado $_REQUEST en lugar de $_POST o $_GET y luego informar de un error si encuentra que, independientemente de los esfuerzos que ha realizado para asegurar esto.

Todos codificarán de forma diferente para que el software entienda el contexto de su código sería un logro increíble y probablemente supere la inteligencia de este. Esto no pretende ser un ataque al software, pero para ser honesto, si surgiera algún programa que pudiera entender el contexto y la intención del código de otra persona, no lo divulgaría en sourceforge: p

¿Importa? Tal vez dependiendo de qué tan bien haya asegurado el sitio (vea el comentario de Marc B (+1) arriba).

- EDITAR -

Mediante el uso de $_REQUEST en lugar de especificar $_POST o $_GET le queda usted abierto a un área de ataque que se cierra fácilmente. No solo esto, sino $_REQUEST también incluye $_COOKIE. Esto ha sido cubierto here en lugar de que yo haya duplicado la respuesta de otra persona.

+0

Dime por qué el +1 desde que tengo la protección csrf incorporada ... No lo entiendo. También vea mi comentario sobre el comentario de Marc B. ¿Cómo puede ser explotado alguna vez cuando la protección csrf está en su lugar? O me estoy perdiendo algo enorme aquí (también puede ser el caso. Ocurre a veces :)) – PeeHaa

+0

He actualizado mi publicación en respuesta;) –

+0

Oh @PeeHaa por cierto +1 para w3af. Solo eché un vistazo y se ve bastante impresionante. –

Cuestiones relacionadas