¿Es la "validación de contenido" la regla de oro para evitar todos los ataques e infracciones web?

No, nunca te inmunizarás completamente contra todos los posibles ataques e infracciones de seguridad. Validar la entrada es un paso importante para defender sus activos, aunque en términos de reducir la posibilidad de inyección de SQL y XSS. Lee el top ten de OWASP nuevamente, es un buen lugar para comenzar.

Pruebe y haga preguntas más específicas sobre ataques o contramedidas y defensas y recibirá respuestas más útiles y específicas.

Sin duda, podrás deshacerte de muchos de ellos.

Pero, por un lado, algunas vulnerabilidades se derivan de su arquitectura . En cierto sentido, podría decir que su aplicación está diseñada para que no sea segura.

Suponga que su código de cierre de sesión no destruye correctamente la sesión, pero lo deja en un estado que la página de inicio de sesión reconoce como "desconectado". Al parecer, todo funciona bien. Todas las pruebas pasan. Hay una prueba faltante que habría fallado: intentar acceder a un recurso después de cerrar la sesión. Pero falta la prueba.

Si abre dos pestañas en el mismo navegador, puede descubrir que puede cerrar la sesión en la primera página y seguir navegando por el sitio con solicitudes 100% regulares, pasando todas las validaciones; y al finalizar la sesión oficialmente, todo lo que hace no se registra, todos los intentos de grabación se bloquean silenciosamente. El registro de la consola de su navegador se llena de errores y no le importa.

Y es aún peor que eso. Si intenta acceder a un recurso de superadmin, el sistema intenta verificar si está autorizado o no, y debido a la circunstancia imprevista de que ya no tiene un lado del servidor asignado de la entidad de Usuario, esta comprobación falla . De tal manera que a esta sesión ahora se le otorga acceso de superadmin .

Por lo tanto, te queda una aplicación donde entradas perfectamente legales , simplemente desde dos pestañas diferentes del mismo navegador, terminan otorgándote acceso administrativo completo a la aplicación, y alguien puede presionarla < em> involuntariamente .

^{Y cuando esto sucedió, porque realmente sucedió , la "solución" propuesta fue, lo adivinaste, tratando de encontrar una manera de evitar que se abran dos pestañas en el navegador en lugar de rastrear el origen del problema . La solución "real" fue agregar una línea con session_destroy() en la fuente. El "parche rápido" resultó ser una pesadilla de Javascript kludgy de una semana} .

Otro ejemplo es la aleatoriedad débil o la divulgación de información en su aplicación, que podría permitir que alguien adivine cómo obtener privilegios injustificados. Lo harán mediante la emisión de comandos legales : el problema será que pudieron descubrir estos comandos .

Por ejemplo, algunas aplicaciones pueden proporcionar un menú con opciones. A un usuario de nivel de administrador se le mostrarán diez entradas, a un invitado solo se le mostrarán dos. Los enlaces a los puntos de entrada privilegiados no estarán en el HTML. Pero si los puntos de entrada no controlan el nivel de privilegio del usuario, cualquiera puede acceder a ellos siempre que sepa o adivine sus nombres.

Los fallos predecibles de restablecimiento de contraseñas (por ejemplo, md5 (loginname + unix_timestamp)) permitirán que un usuario malintencionado acceda a la cuenta de cualquiera enviando una solicitud de restablecimiento de contraseña a última hora de la noche y enviando ciegamente una confirmación ( o un número razonable de intentos de fuerza bruta). El usuario legítimo lo descubrirá a la mañana siguiente, y puede que sea demasiado tarde.

Al restablecer la contraseña antes llega la confirmación, y usar esta última para otorgar acceso, resultará en una fácil denegación de servicio de todas las cuentas.

Y, por supuesto, podríamos encontrar muchos más ejemplos en varios niveles de vulnerabilidad (desde acceder a datos no autorizados hasta interrumpir la operación del sitio) que aún funcionarán incluso después de todos los posibles desinfecciones.

Por otra parte, las entradas de desinfección adecuadas pueden resultar imposibles, ya que es posible que necesite procesar combinaciones de entradas increíblemente complejas o no poder saber fácilmente si, por ejemplo, ingresar COTE D'OR es una solicitud legítima o una inyección de SQL intento (en este caso, sí, es razonablemente fácil).

En algunos casos, necesitaría un intérprete seguro de la entrada para poder saber si la entrada es kosher o no ... pero si tuviera un intérprete de este tipo, tendría más sentido para usarlo para analizar datos de entrada en el código de producción. Este tipo de "blindaje" todavía vale la pena cuando no puede modificar el comportamiento de la aplicación y se ve obligado a desplegar un "extremo frontal" más inteligente como un escudo; pero como desarrollador de aplicaciones web para aplicaciones propias, este no es su caso.

Mi consejo es planificar y probar cuidadosamente su aplicación e intentar pensar en todo lo que podría salir mal y qué hacer cuando finalmente saldrá mal.

La imposición de una "Gran Muralla" de entrada desinfectada podría hacerte sentir una falsa sensación de seguridad y, a la larga, hacer más daño que beneficio.

Dicho esto, hay varias bibliotecas y marcos que agregarán saneamiento de entrada casi sin costo, y sin duda es un camino que vale la pena seguir. Lo que no es una "bala de plata" que le permite "deshacerse de todas las vulnerabilidades".

Sí, la validación de contenido ejecutada correctamente sentará las bases para un enfoque de seguridad sólido. El Top 10 de OWASP es una guía para establecer una postura de seguridad de línea de base.

No, la validación de contenido no es una regla de oro para evitar ataques e infracciones de TODOS . Si bien establecer una implementación sólida de la validación de contenido reducirá drásticamente el número de ataques exitosos, pero "hay más de una forma de proteger a un gato".

También debe considerar los riesgos y el impacto que podría generar una infracción. Un sitio web personal puede no tener mucho impacto, y una infracción puede resolverse mediante una simple restauración desde la copia de seguridad. Un sitio web que se ocupe de información financiera o de salud podría tener importantes implicaciones de una sola infracción.

Usted, como nuevo desarrollador web, no necesariamente necesita estar íntimamente familiarizado con todos los métodos de ataque y defensa, pero al menos debe estar familiarizado con los conceptos básicos de cómo proteger correctamente su sitios web A medida que pase el tiempo, debe continuar desarrollando su conocimiento de los mecanismos de defensa.

Si la idea de aprender a defenderse contra los ataques te molesta, desafortunadamente puedes estar en el campo equivocado. En esta época, el conocimiento de las mejores prácticas de seguridad es cada vez más importante.

No creo que sea un buen enfoque sumergirse en la "validación de contenido" para proteger su sitio web. En su lugar, debe utilizar marcos y tecnologías que eviten muchos riesgos desde el principio. Cuando se habla de inyección SQL, no use ninguna validación de contenido, use declaraciones preparadas. Existen en Java, existen en PHP. Nunca compile sus afirmaciones por concatenación de cadenas. Eso es todo.

Luego, debes pensar en XSS y en la falsificación de solicitudes entre sitios. Es una buena idea pensar qué partes de la entrada del usuario se reflejan de nuevo en su respuesta http al navegador. Sin embargo, en lugar de escribir funciones que analizan la entrada del usuario (lo más probable es que se pierda algo), codifique la salida html o use un marco que lo haga por usted. No es una mala idea entender los vectores de ataque más comunes con respecto a XSS. Debe saber que no solo hay inyecciones del tipo < script > alert ('sth') < / alert > pero también cosas como onload = ... que evita los caracteres < y & gt ;.

Verifique las páginas OWASP para CSRF. Una manera relativamente fácil de hacer que CSRF sea mucho más difícil es verificar el remitente cuando procesa las solicitudes y rechazar si el remitente no es su propio sitio.

Dicho esto, la validación de entrada es definitivamente una necesidad cuando se sabe que una entrada tiene un formato definido con precisión. Buen ejemplo es una fecha. Asegúrese de que el usuario realmente ingresa una fecha. Esto mejorará la calidad de su código independientemente de la seguridad.

Un par de cosas más:

• No use la ejecución de código. No eval, exec, como se llame en su idioma
• No utilice la serialización. Nunca deserialice los objetos que un cliente le envíe.