Rechercher des problèmes d'injection SQL potentiels dans le code Java / JSP

Question

Je travaille pour un client disposant d'une base de code héritée considérable composée de diverses applications basées sur Java et JSP.

La plupart des requêtes sont effectuées à l'aide du système home-build 'orm'. Certaines applications utilisent Plain Old JDBC. Certaines applications sont basées sur Hibernate (oui, la construction de HQL avec des signes plus est également un problème). Certaines des anciennes applications sont entièrement écrites dans JSP.

J'ai trouvé quelques bogues d'injection SQL manuellement. Mais je pourrais vraiment utiliser une sorte d’outil pour rechercher des points faibles potentiels.

Des idées?

Answer 1

Je recommanderais FindBugs (il existe également un plug-in eclipse) qui permet de suivre ces problèmes et bien d'autres. .

Nous l'utilisons au travail, c'est rapide et ça en vaut la peine (comme en libre). Nous avons résolu certains problèmes courants avec son aide.

Answer 2

J'écrirais des recherches ou chargerais un environnement de développement intégré (IDE) qui recherchait l'utilisation de java.sql.Statement, par opposition à PreparedStatement.

Answer 3

Quelle est la taille de votre espace URL? Si possible, il est préférable de tenter l'injection SQL via les requêtes HTTP GET et POST. L'examen du code source / octet permet de détecter certains problèmes, mais le seul moyen de connaître avec certitude les types d'entrées potentiellement malveillantes acceptées par votre application consiste à utiliser des requêtes HTTP.

CAL9000 est un bon outil de test d'injection SQL / de script intersite. si votre ensemble d'URL est petit.

Les entreprises soucieuses de détecter les entrées malveillantes mal gérées vont faire appel à une tierce partie pour effectuer les tests d'intrusion. La White Hat Security est un fournisseur avec lequel j'ai déjà travaillé et que je peux recommander. Nous les avons utilisées pour un site Web de commerce électronique de plus de 100 millions de dollars. (Je n'ai aucune affiliation avec White Hat et je ne tire aucun avantage de la situation si vous devenez leur client.)

Tous les tests / durcissements de votre code mis à part, il est très judicieux de mettre en place un pare-feu HTTP tel que mod_security .

Answer 4

Lorsque je travaillais sur la localisation de "cette localisation ne sera jamais nécessaire" " application, nous utilisons un outil fait maison pour analyser le code compilé (IL dans .NET, il est identique au code octet en Java).

Vous pouvez appeler les méthodes spécifiées qui fonctionnent avec une base de données (opérations CRUD typiques) sans avoir un paramètre de chaîne avec une commande SQL, et suivre l'instance de chaîne et vérifier la concation.

Nous avons utilisé le réflecteur .NET pour la décompilation et le suivi des chaînes. Mais je ne sais pas si un outil similaire est disponible pour Java: (.

Answer 5

Vous pouvez faire de la prévention plutôt que du guérir. ajoutez une couche de désinfection juste en dessous de votre interface utilisateur pour ne pas avoir SQL / scripts dans les entrées utilisateur. Il doit y avoir des exemples en Java, j'ai vu une telle approche dans CakePHP

Answer 6

Trouvez un endroit qui n'utilise pas une PreparedStatement .

Answer 7

Je recommande CAL9000. Vous pouvez obtenir des détails à partir du lien suivant:

CAL9000