Найти потенциальные проблемы SQL-инъекций в коде Java / JSP

Question

Я работаю для клиента с огромной унаследованной кодовой базой, состоящей из различных приложений на основе Java en JSP.

Большая часть запросов выполняется с использованием системы orm, созданной в домашних условиях. Некоторые приложения используют Plain Old JDBC. Некоторые приложения основаны на Hibernate (да, потенциальная проблема также в сборке HQL со знаками плюса). Некоторые из старых приложений полностью написаны на JSP.

Я обнаружил несколько ошибок SQL-инъекций вручную. Но я действительно мог бы использовать какой-то инструмент для поиска потенциальных слабых мест.

Есть идеи?

Answer 1

Я бы порекомендовал FindBugs (есть также плагин Eclipse), который может отследить эти проблемы и многое другое.

Мы используем его на работе, это быстро и стоит денег (как в бесплатной). Мы решили некоторые общие проблемы с его помощью.

Answer 2

Я бы написал несколько поисков или загрузил бы IDE, которая искала использование java.sql.Statement, а не PreparedStatement.

Answer 3

Насколько велико ваше адресное пространство? Если возможно, лучше всего попытаться внедрить SQL через HTTP GET и POST запросы. Есть некоторые проблемы, которые могут быть обнаружены при проверке исходного / байтового кода, но единственный способ точно определить, какие виды потенциально вредоносного ввода будет принимать ваше приложение, - это использовать HTTP-запросы.

CAL9000 - хороший инструмент для тестирования SQL-инъекций / межсайтовых сценариев, если ваш набор URL-адресов мал.

Компании, которые серьезно относятся к обнаружению неправильного ввода вредоносных данных, будут нанимать стороннюю компанию для проведения тестирования на проникновение. White Hat Security - поставщик, с которым я работал в прошлом, и может порекомендовать. Мы использовали их для веб-сайта электронной коммерции стоимостью более 100 миллионов долларов США. (Я не имею отношения к White Hat и не получаю никакой выгоды, если вы становитесь их клиентом.)

Все тестирование / усиление вашего кода в стороне, это очень хорошая идея, чтобы иметь брандмауэр HTTP, например mod_security .

Answer 4

Я рекомендую CAL9000. Вы можете получить подробную информацию по следующей ссылке:

CAL9000

Answer 5

Найдите любое место, где не используется PreparedStatement.

Answer 6

Вы можете пойти на профилактику, а не на лечение. добавьте слой дезинфекции чуть ниже вашего пользовательского интерфейса, так что вы не получите sql / scripts при вводе пользователем. Должны быть примеры в Java, я видел такой подход в CakePHP

Answer 7

Когда я работал над локализацией приложения «это будет никогда не нужно», мы использовали самодельный инструмент для анализа скомпилированного кода (IL в .NET, он такой же, как байт-код в Java) .

Вы можете найти вызов указанных методов, который работает с БД (как правило, операции CRUD), у которого есть строковый параметр с командой SQL, а также отследить экземпляр строки и проверить его на предмет объединения.

Мы использовали .NET Reflector для декомпиляции и отслеживания строк. Но я не знаю, есть ли подобный инструмент для Java: (.