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

Question

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

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

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

Есть идеи?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

КАЛ9000