2010-05-10 16 views
5

De nombreuses entreprises utilisent des logiciels CMS qui sont régulièrement mis à jour, souvent des correctifs de sécurité, ce qui implique que la version précédente présente des failles de sécurité. Mais la plupart des clients ne mettent jamais à jour cela, ou même le CMS a été modifié de sorte qu'une mise à jour puisse briser le site. Existe-t-il des sites documentant ces exploits et indiquant comment les tester? Ou est-ce que cette information n'est même pas publiée? (afin de ne pas avoir à essayer de les exploiter)Test des failles de sécurité sur les applications Web

Existe-t-il une liste de vérification générique basée sur php/js pour éviter les tentatives de piratage? Je connais les injections SQL et XSS, mais je suis sûr qu'il y a plus de menaces.

paix

+0

Avez-vous essayé googler autour pendant un certain temps? Il y a des tonnes de blogs sur ce genre de choses. Vous pouvez également acheter une suite d'attaques semi-automatisée pour tester des sites Web. –

Répondre

3

Les sites catalogue toutes ces vulnérabilités sont par exemple

  • SecurityFocus
  • Milw0rm
  • packetstormsecurity

La liste de contrôle de base pour webapps se trouve sur OWASP , qui est une liste de contrôle très générale.

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

+0

excellent, milW0rm et packetstormsecurity look très prometteur – Moak

3

attaques SQL et XSS Injections sont tous deux résolus en analysant toutes les informations qui devient à votre code (addslashes, supprimer « » balises et ainsi de suite); L'émulation de guillemets magiques et register_globals off résout les problèmes de mon point de vue. Soyez prudent, ne savez pas exactement quand, mais magic_quotes sera obsolète alors ne comptez pas là-dessus.

Alors, quelles sont les autres menaces? D'après mon expérience, les erreurs humaines les plus courantes sont liées à l'authentification. Cela ne signifie pas que l'utilisateur ne se connecte pas, mais cela signifie qu'un utilisateur peut lire/écrire des informations pour d'autres utilisateurs. Ainsi, chaque fois que vous voyez un lien de suppression comme ceci: index.php? Page = images & action = supprimer & id = 2, essayez avec un autre id, de l'image d'un autre utilisateur. Vous devriez obtenir une phrase d'erreur "pas votre image" ou quelque chose. C'est très très difficile à vérifier, vous devez donc compter sur l'expérience du développeur.

Le deuxième plus gros problème que j'avais n'était pas lié au code mais au serveur. Les mots de passe FTP ont été volés par des virus (virus IFrame et autres), ou le serveur a été piraté en utilisant diverses méthodes de force brute. La conclusion est la suivante: si vous êtes sûr que vous avez vérifié les injections SQL et les attaques XSS, la dernière chose à faire est de résoudre le problème d'authentification (une fois de plus, l'authentification est YOURS). Les gens ont tendance à être un peu paranoïaque sur les problèmes de sécurité, mais les hacks les plus courants ne sont pas la faute du développeur.

Espérons que cela aide;

Cordialement, Gabriel

+1

Oublié de mentionner CSRF, qui est très très très populaire de nos jours. Surtout parce que la solution n'est pas aussi simple que pour xss/sqli – Henri