asegurando cuadros desplegables

Es muy importante que entienda que CUALQUIER entrada de los usuarios debe ser desinfectada de una forma u otra, o de lo contrario, es posible que se esté abriendo para los agujeros de seguridad. Cualquier entrada podría significar cuadros desplegables u otros datos que usted consideraría estáticos. Ejemplos de esto es simplemente algo devuelto por el usuario como por ejemplo:

• Botones de radio
• cuadros desplegables
• Los datos provienen de complementos como flash, silverlight, etc.
• ¡Simplemente cualquier cosa que se envíe al cliente!

Para ilustrar mejor esto, le animo a descargar un proxy simple que le permitirá mostrar todos los datos que se envían a su servidor cuando envía un formulario. Aquí se muestra un ejemplo de solicitud POST:

POST /api/rest HTTP/1.1
Host: api.example.com
User-agent: Googlebot/2.1 (+http://www.google.com/bot.html)
Referer: example.com/admin.php
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Cookie: username=karrax&password=855425718dfe4a50f6f0bbb9335d3c3b&userid=591

dropdownBox=string&staticTextField=string&hiddenElement=string

Cualquier cosa en la que tenga que confiar en la lógica de su negocio proveniente del lado del cliente debe ser limpiada .

Recuerde que esto se aplica a cualquier cosa que provenga del lado del cliente. ¡NO SE PUEDE CONFIANZA! ... Incluso si es simplemente una cadena que se devuelve al cliente (por ejemplo, un nombre de usuario), debe limpiarse para que no sea vulnerable a los scripts entre sitios y otros vectores de ataque.

Editar : como @Avid señaló en los comentarios, también es imprescindible saber que los datos que se transmiten a través de las cookies también se envían desde el lado del cliente, lo que los hace vulnerables a la manipulación. Esto también se aplica a cualquier otro campo en los encabezados (o cualquier cosa que provenga del cliente) como el agente de usuario o el campo de referencia para nombrar algunos.

En el ejemplo anterior, la solicitud HTTP puede frustrar algunos sistemas de seguridad si se basan en el campo de referencia para, por ejemplo, autorizar al usuario. El ejemplo también hace que parezca que es el bot de Google que en algunas circunstancias puede proporcionar contenido diferente en la página que solicita ( source ).

Debe implementar alguna lógica de negocios en el servidor, que incluye la validación de entrada del lado del servidor. Nunca permita que la entrada del navegador fluya directamente a su base de datos.

Si desea realizar una validación del lado del cliente también ( no en lugar de! ) la validación del lado del servidor para mejorar el rendimiento o la facilidad de uso, entonces por todos los medios . Pero si no está validando en el servidor, en realidad no está validando los datos (como mostró su propio experimento).

Estás haciendo PHP, por lo que esta página puede tener algunos buenos consejos. [Los detalles de cómo hacer esto, por supuesto, dependen de la plataforma de su servidor.]

Volvamos a los primeros principios: ¿Contra qué estás defendiendo?

Si está defendiendo que los campos no válidos se envíen a su aplicación web, como todas las otras publicaciones han señalado, un atacante no necesita usar HTML o JS para enviar datos no válidos. Pueden crear su propio GET o POST y enviarlo a su servidor (los datos de manipulación del complemento FF le permiten hacer esto desde el navegador).

1. Use la validación del lado del navegador para la usabilidad. Esta validación es fácil de eludir, por lo que la única razón para hacerlo es aumentar la facilidad de uso de su sitio ayudando al usuario a enviar valores válidos.

2. Validación del lado del servidor, desinfección, etc. Se debe asumir que todos los datos enviados están sucios y son un posible vector de ataque. Desinfecte los datos enviados antes de usarlos para cualquier cosa (y use su base de datos de manera segura: evite la inyección de SQL).