2010-05-10 16 views
5

Muchas empresas utilizan el software CMS que se actualiza regularmente, a menudo son soluciones de seguridad, lo que implica que la versión anterior tiene vulnerabilidades de seguridad. Pero la mayoría de los clientes nunca actualizan esto, o incluso el CMS ha sido modificado para que una actualización rompa el sitio. ¿Hay sitios que documenten estos exploits e indique cómo probarlos? ¿O esta información ni siquiera se publica? (para que las personas no intenten explotarlas)Comprobación de vulnerabilidades de seguridad en aplicaciones web

¿Existe una lista de verificación genérica basada en php/js para evitar intentos de pirateo? Sé sobre las inyecciones de SQL y XSS, pero estoy seguro de que hay más amenazas por ahí.

Paz

+0

¿Usted ha intentado googlear alrededor por un tiempo? Hay toneladas de blogs sobre esto. También puede comprar un conjunto de ataques semiautomático para probar sitios web. –

Respuesta

3

Los sitios que el catálogo todas estas vulnerabilidades son, por ejemplo,

  • SecurityFocus
  • milw0rm
  • packetstormsecurity

La lista de comprobación básica para aplicaciones web se puede encontrar en OWASP , que es una lista de verificación muy general.

http://www.owasp.org/index.php/Top_10_2010-Main

+0

excelente, milW0rm y packetstormsecurity se ven muy prometedores – Moak

3

inyecciones SQL y XSS ataques son a la vez resueltos mediante el análisis de toda la información que está llegando a su código (addslashes, eliminar "" etiquetas, etc.); Magic cita la emulación y register_globals solucionó los problemas desde mi punto de vista. Tenga cuidado, no sé exactamente cuándo, pero magic_quotes estará en desuso así que no cuente con eso.

¿Qué otras amenazas son? Desde mi experiencia, los errores humanos más comunes están relacionados con la autenticación. Esto no significa que el usuario no inicie sesión, pero significa que un usuario puede leer/escribir información para otros usuarios. Entonces, cada vez que vea un enlace de eliminación como este: index.php? Page = images & action = delete & id = 2, intente con otra identificación, de la imagen de otro usuario. Debería obtener un mensaje de error "no su imagen" o algo así. Esto es muy difícil de verificar, por lo que debe contar con la experiencia del desarrollador.

El segundo problema más grande que tuve no estaba relacionado con el código sino con el servidor. Las contraseñas FTP fueron robadas por virus (virus IFrame y otros), o el servidor fue pirateado usando varios métodos de fuerza bruta.

La conclusión es: si está seguro de que revisó las inyecciones SQL y los ataques XSS, lo último que debe hacer es resolver el problema de autenticación (una vez más, la autenticación significa que la información que obtiene/altera es SUYA). La gente tiende a ser un poco paranoica sobre los problemas de seguridad, pero los hacks más comunes no son culpa del desarrollador.

Espero que esto ayude;

Saludos, Gabriel

+1

Olvidé mencionar CSRF, que es muy muy popular hoy en día. Especialmente porque la solución no es tan sencilla como para xss/sqli – Henri

Cuestiones relacionadas