Test de sécurité Web

Question

Dans votre expérience, ce que vous avez trouvé, travaillé, ou rencontré en termes de vulnérabilités du site? Et quelles actions avez-vous prises pour atténuer ces problèmes?

Cela peut inclure XSS (de cross site scripting), les attaques par injection SQL, ou DDOS bon vieux tentatives de phishing sur les clients de votre site. Hier encore, je suis tombé sur une section complète d'outils de Firefox pour les sites d'audit et leur potentiel pour diverses vulnérabilités.

A la recherche d'élargir mes connaissances dans ce domaine pour un rôle, donc plus d'informations à lire ou à apprendre est toujours bon - liens solides appréciés aussi! Et des histoires de guerre de la pire que vous avez trouvé ou trou le plus effrayant que vous avez vu - apprendre de l'expérience est la meilleure façon parfois

Answer 1

Je l'ai fait examen de la sécurité, boîte blanche et boîte noire, pour des dizaines (centaines?) Des applications et des sites.

1. XSS et injection SQL obtenir beaucoup de presse, mais je sais ce que je trouve la faille de sécurité la plus commune d'être? Laissant le débogage et la fonctionnalité de test dans le code de production. Soit par altération des paramètres POST (IsDebug = true) ou via spidering un site et de trouver des pages qui restent, ce sont les pires erreurs que je vois en ce qui concerne la sécurité. Si vous y compris le code test / debug, le mettre dans une branche de code distinct, ou du moins préparer une liste de contrôle pour le retrait avant le lancement.

2. La prochaine vulnérabilité la plus commune que j'ai vu est tout simplement la possibilité de contourner les mécanismes de sécurité en saisissant une URL de la source de la page. Le nom technique est « Énergique Navigation » ou « Navigation forcée » Ceci est quelque chose de tout qui peut lire HTML peut faire, mais je suis surpris par la variété des applications vulnérables. L'examen d'un site d'achat de billets hier, je suis en mesure d'acheter des billets pour les spectacles à guichets fermés à l'aide de cette méthode. Sur les sites précédents, j'ai pu sauter tout à fait payer (beaucoup, beaucoup de sites Paypal passent l'URL « achat complète » à paypal via les paramètres POST - Yoink!). Vous avez besoin d'une sorte de statefulness back-end ou vérifier pour assurer l'achèvement, le paiement, la disponibilité, la précision, etc.

3. Pour être franc, je laisse généralement des outils comme AppScan, proxy BURP, WebScarab, Fortify, FindBugs ou YASCA (en fonction du budget et de l'accessibilité du code source) trouver XSS et les attaques par injection SQL pour moi. Je vais essayer les choses simples sur moi-même, chercher des trous évidents, mais il y a trop de combinaisons connues pour vous essayer. Je garde une petite collection de scripts et des cas de test pour des défauts plus avancés ou récemment découverts.

Je vais arrêter à 3, parce que je pouvais vraiment aller toute la journée, je suis de perdre de vue votre question, et personne ne veut lire un mur de texte.

Certaines ressources pour la sécurité Web nouveaux et chevronnés gourous: (ARGH. Je ne peux pas officiellement poster encore des liens. Copier / coller. Désolé)

Le projet Open Web Application Security (OWASP)

http://www.owasp.org/

Web Security Testing livre de recettes

Ce livre est écrit pour les auditeurs, les testeurs, et moins pour les développeurs. Ce qui est assez inhabituel pour un livre O'Reilly.

websecuritytesting.com

Vulnérabilité Catégorisation par Fortify

www.fortify.com/vulncat /

Common Weakness Enumeration (avertissement: vaste)

nvd.nist.gov/cwe.cfm

Modèle d'attaque commune Enumeration et classification (avertissement: encore plus étendue)

capec.mitre.org /

Tutoriels de sécurité Web de Google

(plutôt faible)

code.google.com/edu/security/index.html

Answer 2

J'ai rejoint un projet d'application Web qui comprenait une bibliothèque de documents. La façon dont il fait référence des documents était quelque chose comme http://example.com/getdocument?file=somefile. pdf . Bien sûr, je devais juste essayer file = / etc / passwd, et bien sûr il a travaillé.

Solution: Effectuez sanitization d'entrée utilisateur et / ou utiliser un certain niveau d'abstraction entre les ressources demandées dans l'URL et les ressources du système de fichiers réels

.

Ceci est le cousin des attaques par injection SQL. Examiner toute demande autorisée qui ressemble étrangement lui donne le client trop de contrôle.