Liste de contrôle pour le Site Web de la Programmation des Vulnérabilités

Question

Regarder, AFIN de venir en ligne a été une éducation pour moi.Je voudrais faire une liste des différents vunerabilities et les exploits utilisés contre les sites web, et ce que les techniques de programmation peut être utilisé pour se défendre contre eux.

• Quelles sont les catégories de vunerabilities?
  • s'écraser site
  • la rupture dans l'server
  • la rupture dans les connexions
  • le spam
  • sockpuppeting, meatpuppeting
  • etc...
• Quel genre de défense des techniques de programmation?
• etc...

Answer 1

À partir de la Open Web Application Security Project:

1. L' OWASP Top Ten vulnérabilités (pdf)
2. Pour une plus douloureusement liste exhaustive: Catégorie:Vulnérabilité

Les dix premiers sont:

1. Cross-site scripting (XSS)
2. Failles d'Injection (SQL injection, injection de script)
3. Fichier malveillant d'exécution
4. Directe non sécurisée à un objet de référence
5. Cross-site request forgery (XSRF)
6. La fuite de l'Information et de la mauvaise gestion des erreurs
7. Brisé d'authentification et de gestion de session
8. Stockage cryptographique non sécurisé
9. L'insécurité des communications
10. Échec de restreindre l'accès URL

Answer 2

Je seconde l'OWASP info comme étant une ressource précieuse.Les éléments suivants peuvent être d'intérêt, notamment les modèles d'attaque:

• CERT Top 10 des Pratiques de Codage Sécurisé
• Commune de profil d'Attaque de l'Énumération et la Classification
• Modèles D'Attaque
• Programmation sécurisée pour Linux et Unix
• Une Taxonomie des Erreurs de Codage qui Affectent la Sécurité
• Programmation sécurisée avec l'Analyse Statique de Présentation

Answer 3

Évidemment tester chaque champ de vulnérabilités:

• SQL - échapper à cordes (par exemple mysql_real_escape_string)
• XSS
• HTML cours d'impression à partir de champs de saisie (un bon signe de XSS, généralement)
• Autre chose qui est pas le but spécifique de ce champ a été créé pour

Recherche pour les boucles infinies (le seul indirecte chose (si beaucoup de gens ont trouvé par hasard) qui pourrait tuer un serveur vraiment).

Answer 4

Certaines techniques de prévention:

XSS

• Si vous prenez l'un des paramètres d'entrée/de l'utilisateur et plan sur la sortie, que ce soit dans un journal ou une page web, de désinfecter le (ou la tranche de s'échapper de quelque chose ressemblant à du HTML, des citations, javascript...) Si vous imprimez le courant de l'URI d'une page à l'intérieur de lui-même, à désinfecter!La même impression d'PHP_SELF, par exemple, est dangereux.Désinfecter!Réfléchissant XSS provient principalement de l'unsanitized les paramètres de la page.

• Si vous prenez n'importe quelle entrée de l'utilisateur et de le sauvegarder ou de l'imprimer, de les avertir si quelque chose de dangereux/non valide est détecté et leur ré-entrée.un IDS est bon pour la détection (comme PHPIDS.) Puis les désinfecter avant de les stockage/d'impression.Ensuite, lorsque vous imprimez quelque chose de stockage/de base de données, désinfecter à nouveau!Entrée -> ID/désinfection -> enregistrer -> désinfection -> sortie

• utiliser un scanner de code en cours de développement pour aider à détecter potentiellement vulnérables code.

XSRF

• N'utilisez jamais d'OBTENIR la demande de destructeur de fonctionnalités, c'est à direla suppression d'un poste.Au lieu de cela, seulement accepter les requêtes POST.OBTENIR le rend très facile pour hackery.
• La vérification de la référent assurez-vous que la demande est venu à partir de votre site ne pas travail.Il n'est pas difficile d'usurper l' référent.
• L'utilisation aléatoire de hachage comme un jeton qui doit être présent et valide dans chaque demande, et qui expirent après un certain temps.Imprimer le jeton caché dans un champ de formulaire et de le vérifier sur le côté serveur lorsque le formulaire est affiché.Les méchants auraient à fournir le bon jeton pour forger une demande, et si ils ont réussi à obtenir le véritable coup, il faudrait avant son expiration.

L'injection SQL

• l'ORM ou db abstraction classe devrait avoir la désinfection des méthodes de les utiliser, toujours.Si vous n'êtes pas à l'aide d'un ORM ou db abstraction de la classe...vous devriez être.

Answer 5

L'injection SQL

Answer 6

XSS (Cross Site Scripting) Attaques

Answer 7

Facile à surveiller et facile à réparer:la désinfection des données reçues par le client.La vérification de choses comme le ';' peut aider dans la prévention de code malveillant injecté dans votre application.

Answer 8

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 pour les différentes failles de sécurité,

Toutefois, il ne remplace pas avoir un bien à quelqu'un de lire à travers votre code.Comme David le dit sur sa page web, "Un imbécile avec un outil est toujours un imbécile!"

HTH.

cheers, Rob

Answer 9

Vous pouvez obtenir de bons addons firefox pour tester de multiples failles et les vulnérabilités comme xss et les injections sql à partir de La Sécurité De La Boussole.Dommage qu'ils ne fonctionne pas sur firefox 3.0.J'espère que ceux-ci seront mis à jour bientôt.