security - verificar - Lista de verificación para las vulnerabilidades de programación del sitio web

test seguridad pagina web

Question

Ver SOO en línea ha sido toda una educación para mí. Me gustaría hacer una lista de verificación de varias vulnerabilidades y vulnerabilidades usadas contra sitios web, y qué técnicas de programación pueden usarse para defenderse de ellas.

• ¿Qué categorías de vunerabilities?
  • estrellarse el sitio
  • irrumpiendo en el servidor
  • irrumpir en los inicios de sesión de otras personas
  • correo no deseado
  • emborracharse , emborracharse
  • etc ...
• ¿Qué tipo de técnicas de programación defensiva?
• etc ...

Answer 1

Ataques XSS (Cross Site Scripting)

Answer 2

Del proyecto de seguridad de aplicaciones web abiertas :

1. Las vulnerabilidades OWASP Top Ten (pdf)
2. Para una lista más dolorosamente exhaustiva: Categoría: Vulnerabilidad

Los diez mejores son:

1. Cross-site scripting (XSS)
2. Defectos de inyección (inyección SQL, inyección de scripts)
3. Ejecución de archivo malicioso
4. Referencia insegura de objeto directo
5. Falsificación de solicitudes entre sitios (XSRF)
6. Fuga de información y manejo incorrecto de errores
7. Autenticación rota y gestión de sesión
8. Almacenamiento criptográfico inseguro
9. Comunicaciones inseguras
10. No se puede restringir el acceso a la URL

Answer 3

Fácil de supervisar y fácil de solucionar: la desinfección de los datos recibidos del lado del cliente. Comprobando cosas como '';'' puede ayudar a prevenir la inyección de códigos maliciosos en su aplicación.

Answer 4

Obviamente, prueba todos los campos para detectar vulnerabilidades:

• SQL - cadenas de escape (por ejemplo, mysql_real_escape_string )
• XSS
• HTML impreso desde los campos de entrada (una buena señal de XSS generalmente)
• Cualquier otra cosa que no sea el propósito específico para el que se creó el campo

Busque bucles infinitos (la única cosa indirecta (si mucha gente lo encontró accidentalmente) podría matar a un servidor realmente).

Answer 5

inyección SQL

Answer 6

En segundo lugar, la información de OWASP es un recurso valioso. Los siguientes pueden ser de interés también, especialmente los patrones de ataque:

• CERT Top 10 Secure Coding Practices
• Enumeración y clasificación de patrón de ataque común
• Patrones de ataque
• Programación segura para Linux y Unix
• Una taxonomía de los errores de codificación que afectan la seguridad
• Programación segura con presentación de análisis estático

Answer 7

Gday,

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

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

HTH.

aplausos, Rob

Answer 8

Algunas técnicas de prevención:

XSS

• Si toma cualquier parámetro / entrada del usuario y alguna vez planea generarla, ya sea en un registro o en una página web, desinfecte (elimine / escape todo lo que se parezca a HTML, citas, javascript ...) Si imprime el URI actual de una página dentro de sí misma, desinfectar! Incluso imprimir PHP_SELF, por ejemplo, no es seguro. Sanitize! Reflective XSS proviene principalmente de parámetros de página no optimizados.

• Si toma cualquier información del usuario y la guarda o la imprime, avísele si se detecta algo peligroso / inválido y haga que vuelvan a ingresar. un IDS es bueno para la detección (como PHPIDS.) Luego higienice antes de almacenar / imprimir. ¡Luego, cuando imprima algo del almacenamiento / base de datos, desinfecte de nuevo! Entrada -> IDS / desinfectar -> almacenar -> desinfectar -> salida

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

XSRF

• Nunca utilice la solicitud GET para la funcionalidad destructiva, es decir, eliminar una publicación. En cambio, solo acepta solicitudes POST. GET hace que sea más fácil para hackers.
• Verificar el referente para asegurarse de que la solicitud proviene de su sitio no funciona . No es difícil burlar 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 revíselo en el lado del servidor cuando se publique el formulario. Los chicos malos tendrían que proporcionar el token correcto para falsificar una solicitud, y si lograron obtener el token real, tendría que ser antes de que expirara.

inyección SQL

• su clase de abstracción de ORM o db debe tener métodos de desinfección: úselas, siempre. Si no estás utilizando una clase de abstracción de ORM o db ... deberías.

Answer 9

Puedes obtener buenos complementos de Firefox para probar múltiples fallas y vulnerabilidades, como xss e inyecciones sql de Security Compass . Es una pena que no funcionen en Firefox 3.0. Espero que esos se actualizarán pronto.