Непрограммная профилактика SQL-инъекций - PullRequest
Новая
       8

Непрограммная профилактика SQL-инъекций

4 голосов
/ 12 февраля 2011

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

Был большой академический интерес к автоматизированным механизмам предотвращения SQL-инъекций (не буду перечислять их здесь, я провел литературный опрос и видел по крайней мере 20), но я ничего не виделэто на самом деле реализовано.

Кто-нибудь знает какие-либо фреймворки, которые на самом деле используются вне академической среды, либо на основе сигнатур, на основе аномалий, либо иным образом?

Редактировать : Я ищу что-то, что не изменяет базу кода.

Ответы [ 4 ]

8 голосов
/ 12 февраля 2011

Компания, в которой я работаю, использует Barracuda Web Application Firewall для того, о чем вы говорите.Из того, что я видел, это работает довольно хорошо.В основном, если он обнаруживает подозрительный ввод, он перенаправляет пользователя на выбранную нами страницу.Это позволяет вам размещать слой между Интернетом и вашими приложениями и не требует изменения какого-либо кода.

Тем не менее, плохая идея не защищать ваши приложения.

3 голосов
/ 12 февраля 2011

Если вы не собираетесь изменять свой код, вы можете только перехватывать запросы. Поскольку не существует такой вещи, как хорошая или плохая команда SQL, вы довольно ограничены в возможностях, но вы можете попробовать отклонить несколько запросов, которые инициируются из одной строки. Другими словами:

ЮРИДИЧЕСКАЯ 

SELECT * FROM foo WHERE bar='baz';

НЕЗАКОННО 

SELECT * FROM foo WHERE bar=''; DELETE * FROM foo; SELECT 'baz';

Поскольку практически для каждой атаки с использованием инъекций требуется несколько запросов в одном запросе, а при условии, что вашему приложению не требуется эта функция, вы можете просто сойти с рук. Вероятно, он не уловит все типы атак (вероятно, вы можете нанести большой ущерб, используя подзапросы и функции), но, вероятно, лучше, чем ничего.

1 голос
/ 23 февраля 2011

Поведение по умолчанию с PreparedStatements в Java, когда вы передаете каждый параметр, делает его в основном устойчивым к ошибкам, потому что фреймворк избегает ввода для вас.Это не мешает вам делать что-то вроде

exec spDoStuff

, где spDoStuff делает:

exec ()

Ноесли вы используете нормальные запросы, это очень эффективно.Я не знаю, считаете ли вы его непрограммным, но разработчику не нужно писать код, чтобы самостоятельно управлять проверкой ввода.

Например: 

int id;
String desc;
Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement("SELECT * FROM table1 t1 WHERE t1.id = ? AND t2.description = ?");
// or conn.prepareStatement("EXEC spMyProcedure ?, ?");
ps.setInt(1, id);
ps.setString(2, desc);
ResultSet rs = ps.executeQuery();
...
rs.close();
ps.close();
conn.close();
1 голос
/ 22 февраля 2011

Единственный способ оставить код без изменений при исправлении уязвимостей, таких как SQL-инъекция, - это использовать брандмауэр веб-приложений, такой как проект с открытым исходным кодом mod_security .Недавно Oracle выпустила брандмауэр базы данных , который фильтрует неприятные запросы.Этот подход лучше подходит для решения проблемы SQL-инъекций, но это все, что он может решить.

WAF очень полезны и бесплатны, если вы в это не верите протестируйте их .

WAF - это всего лишь один слой.Вам также следует проверить приложение * под ним.Это глубокий подход к защите.* Это услуга, которую я продаю с ограниченным бесплатным предложением.

...