2009-11-23 29 views
2

Un de nos clients nous a transmis un scan PCI sur l'un de nos sites Web. Il y a un certain nombre de rapports de vulnérabilités qui ressemblent quelque chose comme ceci:Rapports de vulnérabilité provenant d'un scan PCI-DSS

service réseau: 80/443 URL de l'application: http://www.oursite.com/signup.php La réponse contient des erreurs SQL Server . Cela suggère que les caractères dangereux insérés par le test ont pénétré l'application et que a atteint la requête SQL elle-même (c'est-à-dire que l'application est vulnérable à Injection SQL).

Résumé des informations de test: tête: tête X-Forwarded-For =% 2527

Je ne sais pas comment ils disent qu'ils ont le code injecté ici?

un autre exemple, ils prévoient une autre URL avec soi-disant la même question a ce que l'exploit:

Résumé des informations de test: en-tête: tête X-Forwarded-For = »

EDIT
J'ai jeté un coup d'oeil dans cet en-tête et il semble que son seul ensemble par Proxy ou Load Balancers (que nous n'utilisons pas de toute façon). De toute façon, je l'ai usurpé moi-même et il n'y a aucune vulnérabilité de notre part, donc je ne suis pas sûr de ce qu'ils mettent en évidence. Puisque nous n'utilisons pas cet en-tête, je ne suis pas sûr de ce que serait le point d'attaque supposé?

Un autre exemple, nous avons d'une vulnérabilité soi-disant ceci:

service réseau: 80/443 URL de l'application: http://www.oursite.com/products/product-na-here/370 Le test intégré avec succès un script dans la réponse, et sera exécuté une fois la page chargée dans le navigateur de l'utilisateur. Cela signifie que l'application est vulnérable aux scripts inter-sites .

Résumé essai informations:

chemin: chemin /produits/produits-na-ici/370 -> /produits/produits-na-ici/370, paramètre: tête > ' » > alerte (957652)

Encore une fois, je ne sais pas ce qui est marqué ici du tout?

Merci.

Répondre

2

Les analyses sont automatisées et peuvent générer des faux positifs. C'est pour vous alerter sur les possibilités de vulnérabilités, et vous devez soit expliquer comment vous n'êtes pas vulnérable, soit fermer les vulnérabilités.(En supposant que vous faites cela pour l'audit de conformité PCI ... sinon, vous essayez de les justifier/fermer en interne.)

Les analyses sont basées sur les 10 vulnérabilités du principal OWASP (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) PCI DSS. Jetez un coup d'oeil là-bas; il y a beaucoup de bons exemples et des explications vraiment approfondies des vulnérabilités.

0

Comme mentionné par un autre utilisateur, la plupart des résultats d'analyse PCI semblent signaler des faux positifs ou des changements de pratiques. J'en ai vu une qui recommandait que nous n'utilisions pas bind et que permettre l'accès FTP était un trou de sécurité majeur. Je vous suggère de contester leurs conclusions là où vous le souhaitez.

1

Une autre option consiste à utiliser un ASV qui ne fournit pas uniquement des résultats automatisés. Il y a quelques bons ASV autour de qui adoptent une approche mélangée aux résultats de sécurité. Ils vérifient manuellement pour confirmer ou infirmer chaque vulnérabilité trouvée automatiquement, ainsi que fournir des tests manuels pour trouver des choses que seul un humain peut de manière fiable, comme l'injection SQL, les scripts inter-sites et les fuites d'informations sensibles, entre autres. des exemples clairs des vecteurs d'attaque requis. Description complète: Je travaille pour un ASV qui fournit un service similaire à celui que je décris.