Lista de verificación para vulnerabilidades de programación de sitios web

Question

Ver a SO conectarse ha sido una gran educación para mí.Me gustaría hacer una lista de verificación de diversas vulnerabilidades y exploits utilizados contra sitios web, y qué técnicas de programación se pueden utilizar para defenderse de ellos.

• ¿Qué categorías de vulnerabilidades?
  • sitio de colisión
  • irrumpir en el servidor
  • irrumpir en los inicios de sesión de otras personas
  • correo basura
  • marionetas con calcetines, marionetas de carne
  • etc...
• ¿Qué tipo de técnicas de programación defensiva?
• etc...

Answer 1

Desde el Proyecto abierto de seguridad de aplicaciones web:

1. El Los diez mejores de OWASP vulnerabilidades (pdf)
2. Para obtener una lista más dolorosamente exhaustiva: Categoría:Vulnerabilidad

Los diez primeros son:

1. Secuencias de comandos entre sitios (XSS)
2. Defectos de inyección (inyección SQL, inyección de script)
3. Ejecución de archivos maliciosos
4. Referencia de objeto directo inseguro
5. Falsificación de solicitudes entre sitios (XSRF)
6. Fuga de información y manejo inadecuado de errores.
7. Autenticación rota y gestión de sesiones
8. Almacenamiento criptográfico inseguro
9. Comunicaciones inseguras
10. No restringir el acceso a la URL

Answer 2

Apoyo la información de OWASP como un recurso valioso.Lo siguiente también puede ser de interés, en particular los patrones de ataque:

• Las 10 mejores prácticas de codificación segura del CERT
• Enumeración y clasificación de patrones de ataque comunes
• Patrones de ataque
• Programación segura para Linux y Unix
• Una taxonomía de errores de codificación que afectan la seguridad
• Presentación Programación segura con análisis estático

Answer 3

Obviamente, pruebe todos los campos en busca de vulnerabilidades:

• SQL: cadenas de escape (p. ej. mysql_real_escape_string)
• XSS
• HTML que se imprime desde los campos de entrada (generalmente una buena señal de XSS)
• Cualquier otra cosa que no sea el propósito específico para el que se creó el campo.

Busque bucles infinitos (lo único indirecto (si mucha gente lo encuentra accidentalmente) que realmente podría matar un servidor).

Answer 4

Algunas técnicas de prevención:

XSS

• Si toma algún parámetro/entrada del usuario y alguna vez planea generarlo, ya sea en un registro o en una página web, desinféctelo (elimine/escapa cualquier cosa que se parezca a HTML, comillas, javascript...) Si imprime el URI actual de una página dentro de sí misma, ¡desinfecte!Incluso imprimir PHP_SELF, por ejemplo, no es seguro.¡Desinfectar!El XSS reflectante proviene principalmente de parámetros de página no desinfectados.

• Si toma alguna entrada del usuario y la guarda o la imprime, adviértale si se detecta algo peligroso o no válido y pídale que vuelva a ingresarla.un IDS es bueno para la detección (como PHPIDS). Luego, desinfecte antes de almacenarlo/imprimir.Luego, cuando imprima algo desde el almacenamiento/base de datos, ¡desinfecte nuevamente!Entrada -> IDS/desinfectar -> almacenar -> desinfectar -> salida

• Utilice un escáner de código durante el desarrollo para ayudar a detectar código potencialmente vulnerable.

XSRF

• Nunca use la solicitud GET para funcionalidad destructiva, es decireliminar una publicación.En cambio, solo acepte solicitudes de publicación.GET hace que sea más fácil para la piratería.
• Verificar el referente para asegurarse de que la solicitud provenga de su sitio No funciona.No es difícil falsificar al referente.
• Utilice un hash aleatorio como token que debe estar presente y ser válido en cada solicitud, y que caducará después de un tiempo.Imprima el token en un campo de formulario oculto y compruébelo en el lado del servidor cuando se publique el formulario.Los malos tendrían que proporcionar el token correcto para falsificar una solicitud, y si lograban obtener el token real, tendría que ser antes de que expirara.

inyección SQL

• su ORM o clase de abstracción de base de datos debe tener métodos de desinfección; utilícelos siempre.Si no estás usando una clase de abstracción ORM o db...usted debería ser.

Answer 5

inyección SQL

Answer 6

XSS (Secuencias de comandos entre sitios) Ataques

Answer 7

Fácil de supervisar y fácil de arreglar:la desinfección de los datos recibidos del lado del cliente.Verificar cosas como ';' puede ayudar a evitar que el código malicioso se inyecte en su aplicación.

Answer 8

Buen día,

Una buena herramienta de análisis estático para la seguridad es Buscador de defectos escrito por David Wheeler.Hace un buen trabajo buscando varios exploits de seguridad,

Sin embargo, no reemplaza que alguien con conocimientos lea su código.Como dice David en su página web: "¡Un tonto con una herramienta sigue siendo un tonto!"

HTH.

Saludos, Rob

Answer 9

Puede obtener buenos complementos de Firefox para probar múltiples fallas y vulnerabilidades como inyecciones xss y sql desde Brújula de seguridad.Lástima que no funcionan en Firefox 3.0.Espero que se actualicen pronto.