Liste de contrôle pour les vulnérabilités de programmation de site Web

Question

Regarder SO venir en ligne a été tout à fait une éducation pour moi. Je voudrais faire une liste des différentes vulnérabilités et exploits utilisés contre les sites web, et quelles techniques de programmation peuvent être utilisées pour se défendre contre eux.

• Quelles catégories de vulnérabilités?
  • site se écraser
  • rupture dans le serveur
  • rupture dans les connexions des autres
  • Spam
  • sockpuppeting, meatpuppeting
  • etc ...
• Quel genre de techniques de programmation défensives ?
• etc ...

Answer 1

De l'Open Web Application Security Project:

1. Le OWASP Top Ten vulnérabilités (pdf)
2. Pour une liste plus exhaustive douloureusement: Category:Vulnerability

Les dix premiers sont:

1. Cross- scriptage de site (XSS)
2. défauts d'injection (injection SQL, injection de script)
3. Malicious exécution du fichier
4. référence Insecure objet direct
5. de falsification de requêtes intersites (XSRF)
6. fuites d'informations et traitement inapproprié des erreurs
7. authentification brisé et gestion de la session
8. stockage cryptographique non sécurisé
9. communications non sécurisées
10. Failu re pour restreindre l'accès URL

Answer 2

injection SQL

Answer 3

XSS (Cross Site Scripting) Les attaques

Answer 4

tester Il est évident que tous les domaines des vulnérabilités:

• SQL - échapper à des chaînes (par exemple mysql_real_escape_string
• XSS
• HTML en cours d'impression à partir des champs d'entrée (un bon signe de XSS habituellement)
• rien d'autre thatis pas le but spécifique domaine a été créé pour

Rechercher des boucles infinies (la seule chose indirecte (si beaucoup de personnes l'ont trouvé accidentellement) qui pourrait tuer un serveur vraiment).

Answer 5

Facile à superviser et facile à réparer: la désinfection des données reçues du côté client. Vérification des choses telles que ';' peut aider à empêcher l'injection de code malveillant dans votre application.

Answer 6

Je suis d'avis que l'information OWASP est une ressource précieuse. Ce qui suit peut être intéressant aussi bien, notamment les schémas d'attaque:

• CERT Top 10 Secure Coding Practices
• Common Attack Pattern Enumeration and Classification
• Attack Patterns
• Secure Programming for Linux and Unix
• A Taxonomy of Coding Errors that Affect Security
• Secure Programming with Static Analysis Presentation

Answer 7

G'day,

Un bon outil d'analyse statique pour la sécurité est FlawFinder écrit par David Wheeler. Il fait un bon travail à la recherche de divers exploits de sécurité,

Cependant, il ne remplace pas une personne bien informée lire votre code. Comme le dit David sur sa page Web, «Un fou avec un outil est toujours un imbécile!"

HTH.

acclamations, Rob

Answer 8

Quelques techniques de prévention:

XSS

• Si vous prenez des paramètres/entrée de l'utilisateur et de planifier jamais sur la sortie, que ce soit dans un journal ou une page web, désinfectez-la (strip/escape tout ce qui ressemble à du HTML, des guillemets, javascript ...) Si vous imprimez l'URI en cours d'une page en elle-même, désinfectez! Même imprimer PHP_SELF, par exemple, n'est pas sûr. Désinfecter! XSS réfléchissant provient principalement de paramètres de page non anonymes.

• Si vous saisissez une entrée de l'utilisateur et que vous le sauvegardez ou l'imprimez, avertissez-le si un élément dangereux/invalide est détecté et demandez-lui de le saisir de nouveau. un IDS est bon pour la détection (comme PHPIDS.) Puis désinfectez avant le stockage/l'impression. Ensuite, lorsque vous imprimez quelque chose à partir du stockage/base de données, désinfectez à nouveau! Entrée -> IDS/assainir -> stocker -> assainir -> sortie

• utiliser un scanner de code au cours du développement pour aider à repérer le code potentiellement vulnérable.

XSRF

• Ne jamais utiliser la requête GET pour fonctionnalité destructrice, à savoir la suppression d'un poste . Au lieu de cela, seulement accepte les requêtes POST. GET rend plus facile pour le hackery.
• Vérification du referrer pour vous assurer que la demande est venu de votre site ne le fait pas travail. Il n'est pas difficile d'usurper le référent .
• Utilisez un hachage aléatoire comme un jeton qui doit être présent et valide dans chaque requête, et qui expirera après un certain temps. Imprimez le jeton dans un champ de formulaire masqué et vérifiez-le du côté serveur lorsque le formulaire est publié. Les mauvais joueurs devraient fournir le jeton correct afin de forger une requête, et s'ils réussissaient à obtenir le jeton réel, ils devraient l'avoir avant son expiration.

injection SQL

• votre ORM ou db classe d'abstraction doit avoir désinfectante méthodes - les utiliser, toujours. Si vous n'utilisez pas une classe d'abstraction ORM ou db ... vous devriez l'être.

Answer 9

Vous pouvez obtenir de bons addons firefox pour tester plusieurs failles et vulnérabilités comme les injections xss et sql de Security Compass. Dommage qu'ils ne fonctionnent pas sur Firefox 3.0. J'espère que ceux-ci seront mis à jour bientôt.