¿Los vectores de ataque en las variables de POSTing de una secuencia de comandos php a la siguiente?

4

Tengo una aplicación que está estructurada de la siguiente manera para su página de registro. Después de este registro, al usuario se le otorga acceso directo al sistema, no hay verificación de correo electrónico (según lo previsto).

Me interesa saber si hay vectores de ataque u otras inseguridades en cómo se construye este flujo de trabajo.

  1. ScriptA.php toma la entrada del usuario en un FORMULARIO
  2. Cuando se envía, se envía a ScriptA-verify.php
  3. Esta segunda secuencia de comandos verifica la información enviada a ella
  4. Si hay un problema, envía la información a ScriptA.php (para que la información sea retenida por el usuario)
  5. Si no hay ningún problema, agrega los datos a la base de datos, establece una variable SESSION ['userid'], etc. y envía algunos campos ocultos a landing.php
  6. En landing.php, verificamos si SESSION ['userid'] está establecido
  7. Si no lo está, enviamos al usuario a una página de error
  8. Si es así, procedemos con la aplicación
pregunta Alan Beats 25.05.2011 - 15:46
fuente

2 respuestas

5

Es difícil darle una respuesta detallada, ya que mucho dependerá del código real que utilice para implementar este proceso. Lo primero y posiblemente lo más importante a considerar es la validación de entrada Y salida en los datos suministrados por el usuario. Hay muchos buenos recursos sobre eso, enlace viene inmediatamente a la mente como el "ir a" para eso.

En cuanto a su enfoque actual, sugeriría que en lugar de tener ScriptA.php POST a ScriptA-verify.php, debería POST a ScriptA.php y manejar la verificación allí. Por todos los medios, logre esto haciendo una "inclusión" de ScriptA-verify.php, pero lo que esto significa es que no tiene la complejidad agregada y, por lo tanto, el riesgo de volver a enviar datos a ScriptA.php si ScriptA-verify.php devuelve problema. Los datos del formulario original estarán disponibles para usted a partir de sus variables saneadas derivadas de $ _POST (no use $ _POST directamente, consulte la validación de la escritura anterior).

El superglobal $ _SESSION es "bastante seguro" pero hay una publicación decente aquí que puede encontrar un poco más de: ¿Alterar una variable $ _SESSION en PHP a través de XSS? . También hay otros en Security StackExchange.

No tengo la sensación de que su cheque de $ _SESSION ['userid'] será particularmente a prueba de bombas, aunque mucho de eso dependerá de conocer otros detalles específicos del proceso que está desarrollando. Por ejemplo, la capacidad de secuestrar una sesión si la sesión se realiza a través de HTTP, no de HTTPS, las configuraciones de configuración de PHP en su servidor, etc.

Otra pregunta que me gustaría hacer es qué controles hay en las otras páginas que este inicio de sesión protegerá, de lo contrario, es potencialmente vulnerable a cosas como la Referencia Insegura de Objetos Directos. En resumen, no asumas que la gente siempre pasará por landing.php para ir a "secured-page1.php". Si no hay nada en secure-page1.php para garantizar una sesión válida, todos sus esfuerzos serán en vano.

Tampoco veo nada que proteja a sus usuarios del ataque CSRF. De nuevo, depende de lo que realmente haga la aplicación, pero si la única comprobación antes de cargar una página es para una sesión válida, entonces sería trivial forzar al navegador de un usuario a solicitar páginas específicas como restablecimientos de contraseña o similares. Nuevamente, el sitio OWASP puede ayudarlo aquí.

Esto es una especie de prueba rápida, respuesta de volcado de cerebro. Si puede proporcionar detalles más específicos del código detrás de su aplicación y posiblemente su nivel de experiencia, es posible que le brinde un nivel más bajo y un asesoramiento más completo.

    
respondido por el Marc Wickenden 25.05.2011 - 16:42
fuente
2

Aquí hay algunos puntos que debe considerar y cuidar, además de la buena respuesta de @ wicky:

  • Validación de entrada, cada vez los datos llegan al servidor. (No confíe en las validaciones anteriores).
  • Codificación de salida: todos los datos que usted genere deben estar correctamente codificados de acuerdo con el contexto actual (por ejemplo, no utilice la codificación HTML si está escribiendo un valor de atributo).
  • Asegúrese de usar $ _POST, y no $ _REQUEST: las variables pueden escribirse directamente en la URL y recuperarse del GET, aunque espera que estén en el POST.
  • Hay algunos campos que NO se deben enviar al usuario, por ejemplo. contraseñas Haga que el usuario vuelva a ingresar la contraseña, no la vuelva a enviar.
  • Registre cada error (pero no las contraseñas).
  • No haga rodar su propia administración de sesión, use la existente que proporciona el marco. Hay demasiadas cosas a considerar allí, y probablemente obtendrá algunas de ellas incorrectas: generación de id de sesión, validación, caducidad, etc. ...

En general, me gusta la sugerencia de @ wicky de validar en la misma página, en lugar de rebotar de un lado a otro, y alentar a los atacantes a encontrar un punto débil en todo lo que se vuelve a publicar. Minimizar la superficie de ataque, y todo eso ...

    
respondido por el AviD 05.06.2011 - 11:40
fuente

Lea otras preguntas en las etiquetas