¿Es necesario probar todos los parámetros de entrada de una aplicación web al probar su seguridad?

1. Sí, necesita probar todos los parámetros si desea realizar una buena prueba. Puede optar por utilizar pruebas automáticas frente a manuales, según la importancia de la variable de entrada y la ubicación en la aplicación. Tenga en cuenta que si bien una determinada variable de entrada puede parecer no crítica, podría dejar a los atacantes con un vector para acceder a funcionalidades más críticas de la aplicación (piense en XSS almacenado)
2. Priorice en función de la probabilidad y el impacto en su negocio. Si esa vulnerabilidad permite ejecutar comandos o volcar todo el contenido de su base de datos, incluida la información confidencial, debe parchearlo lo antes posible. Si solo permite el acceso a la información pública (y no se puede abusar de ella para obtener más privilegios dentro de la aplicación o el acceso al sistema operativo subyacente), es posible que tenga menos prioridad (dependiendo de cuáles sean los otros temas a los que está asignando prioridad). en)
3. No estoy seguro de qué son los "elementos de entrada" pero si te refieres a los parámetros, debes elegir todos. Puede elegir prestar más atención en algunos campos que en otros (según su presupuesto / tiempo)
4. Depende, usted necesita hacer lo que su cliente le pide, obviamente, si su experiencia le ha enseñado que ciertas variables son más susceptibles que otras, podría prestarles un poco más de atención. Pero diría que es necesario tener en cuenta los requisitos del cliente.

Incluso si una funcionalidad no se considera crítica, siempre debe evaluar el impacto que su exploit tiene en la aplicación y la información almacenada dentro de la aplicación. Lo contrario también es cierto, si tiene una funcionalidad crítica con un exploit, pero en realidad no puede obtener información valiosa de ella, entonces debería hacer que sea menos prioritario solucionarlo. Por lo tanto, el impacto de explotar una vulnerabilidad es importante y no es la criticidad de la función que está explotando. Las prioridades deben suceder en función del impacto.

La respuesta es definitivamente "sí", "no" y "depende". La mejor forma de hacer esta pregunta sería " Sabiendo que tengo recursos limitados, ¿cómo debería priorizar una revisión de mi aplicación web? ".

En seguridad, el éxito no se define como 100% seguro. El éxito debe definirse como la reducción del riesgo a un nivel aceptable. Su "nivel de riesgo aceptable" debe basarse en lo que hace su aplicación, lo que protege y las consecuencias si ocurre algo malo. Quiero más revisión del código que ejecuta mi marcapasos que del juego de Android que compro por un dólar.

Para el 99% de las organizaciones, los recursos son limitados. Es poco probable que tenga los recursos para probar exhaustivamente todos los aspectos de su aplicación web. Debe comprender qué recursos tiene disponibles para revisar y luego establecer prioridades.

Cada aplicación es diferente, así que debes hacer tus propios juicios, pero aquí hay algunas cosas que yo priorizaría:

Entradas que se utilizan como parte de las consultas SQL (inyección de SQL)

Entradas que se utilizan como parte de los comandos ejecutados (inyección de comandos)

Entradas que se utilizan como parte de las consultas LDAP (inyección de ldap)

Entradas de un usuario que se repiten a otros usuarios (XSS persistente)

Entradas de un usuario que se devuelven a ese usuario (XSS reflejado)

Entradas que se utilizan como parte de acciones que modifican la cuenta de un usuario

Entradas que se utilizan como parte de cualquier procesamiento complejo (agotamiento de recursos DOS)

Entradas que se pasan a cualquier proceso que se ejecute con privilegios elevados

Además, sabiendo que no puede revisar exhaustivamente todos los aspectos de su aplicación web, "hace trampa" agregando mitigaciones adicionales:

Ejecute su servidor web sin privilegios elevados

Las cuentas para el acceso a la base de datos deben tener privilegios mínimos

Tenga cuentas separadas para diferentes tipos de acceso a bases de datos. Si el 95% de sus llamadas a la base de datos son de solo lectura, no use una cuenta con privilegios de escritura para esas.

Como han señalado otros, la respuesta corta es SÍ , es necesario probar todos los parámetros de entrada porque cuando se llega a esto, no tiene idea de cuán bien o mal está codificada la aplicación.

Sin embargo , como ha dicho, eso no siempre vuela cuando hay plazos poco realistas en las líneas de negocios: a quienes, por falta de una mejor frase, realmente no les importa.

Es posible que OWASP pueda indicarle a qué caracteres debe dar prioridad. Por ejemplo: enlace (sitio web de OWASP)

Sin embargo, con eso dicho, acaba de crear una carga de trabajo mayor. Debe pasar por cada posible vulnerabilidad y determinar qué caracteres son específicos de esa vulnerabilidad.

Esa sola tarea puede llevar más tiempo (al menos inicialmente) que probar a todos los personajes y no será tan exhaustiva. (lo que no hace falta decir)