Найдите потенциальные проблемы с внедрением SQL в коде Java / JSP
Я работаю для клиента с огромной устаревшей кодовой базой, состоящей из различных приложений на основе Java en JSP.
Большинство запросов выполняется с использованием системы «orm» домашней сборки. Некоторые приложения используют простой старый JDBC. Некоторые приложения основаны на Hibernate (да, сборка HQL со знаками плюса также является потенциальной проблемой). Некоторые из старых приложений полностью написаны на JSP.
Я обнаружил пару ошибок ввода SQL вручную. Но я действительно мог бы использовать какой-то инструмент для поиска потенциальных слабых мест.
Есть идеи?
хе-хе, большинство этих приложений были онлайн уже много лет ... что вселяет в людей ложную уверенность!
Ответы 7
Когда я работал над локализацией приложения «это-никогда-не-локализация», мы использовали самодельный инструмент для анализа скомпилированного кода (IL в .NET, это то же самое, что и байт-код в Java).
Вы можете найти вызов указанных методов, которые работают с БД (типичные операции CRUD), у которых есть строковый параметр с командой SQL, и отслеживать экземпляр строки и проверять сцепление.
Мы использовали .NET Reflector для декомпиляции и отслеживания строк. Но я не знаю, доступен ли аналогичный инструмент для Java :(.
Я бы написал несколько поисковых запросов или загрузил IDE, которая искала использование java.sql.Statement в отличие от PreparedStatement.
Вы можете заняться профилактикой, а не лечением. добавьте слой дезинфекции чуть ниже пользовательского интерфейса ur, так что вы не получите sql / scripts во входных данных пользователя. В java должны быть примеры, я видел такой подход в CakePHP
Найдите любое место, где не используется PreparedStatement.
А как насчет использования PreparedStatement, где параметризованный оператор формулируется с помощью конкатенации строк?
@shad: Это как раз один из тех случаев, когда я копался вручную. спасибо, что указали на это!
Если вы не используете параметры, вы не получаете никакой пользы от PreparedStatement, это правда. Но если у вас больше SQL-инъекций, исходящих от этого, чем от простых старых заявлений, которые параметризуют не могу, у предыдущего разработчика было плохое чувство юмора.
Я бы порекомендовал FindBugs (есть также плагин eclipse), который может отслеживать эти и многие другие проблемы.
Мы используем его в работе, он быстрый и стоит своих денег (как в бесплатном). С его помощью мы решили несколько типичных проблем.
Насколько велик ваш URL-адрес? Если возможно, лучше всего попробовать SQL-инъекцию с помощью запросов HTTP GET и POST. Есть некоторые проблемы, которые могут быть обнаружены путем проверки исходного / байтового кода, но единственный способ точно узнать, какие типы потенциально вредоносных входных данных будет принимать ваше приложение, - это использовать HTTP-запросы.
CAL9000 - хороший инструмент для тестирования SQL-инъекций / межсайтовых скриптов, если ваш набор URL-адресов невелик.
Компании, которые серьезно относятся к обнаружению неправильно обработанных злонамеренных входных данных, будут нанимать стороннюю организацию для проведения тестирования на проникновение. Белая шляпа безопасности - поставщик, с которым я работал в прошлом, и могу порекомендовать его. Мы использовали их для создания веб-сайта электронной коммерции стоимостью более 100 миллионов долларов. (Я не связан с White Hat и не получу никакой выгоды, если вы станете их клиентом.)
Помимо всего тестирования / усиления вашего кода, очень хорошей идеей является наличие брандмауэра HTTP, такого как mod_security.
Я рекомендую CAL9000. Вы можете получить подробную информацию по следующей ссылке:
Самый простой способ, который я нашел, - это опубликовать мое приложение в Интернете на несколько минут! Не публиковать в качестве ответа, так как я не хочу голосов против.