Interpolique: прозрачно предотвращая SQL-инъекции и XSS с кодировкой base64, что случилось?

Question

Для ключевой заметки на The Next HOPE пару лет назад Дэн Камински представил Interpolique (кстати, разговор действительно забавный). Проблема, которую он поднял, заключалась в том, как защититься от атак внедрения, включая внедрение SQL, межсайтовый скриптинг (XSS) и другие уязвимости внедрения. Например, Unicode делает экранирование символов бесполезным, а подготовленные операторы являются PITA.

Его исправление заключалось в преобразовании строк в base64 во время транзита. Например, в SQL можно просто добавить вызов SQL с помощью decode64 eval (). Это гораздо проще, чем подготовленные операторы, небольшое (если таковое имеется) влияние на производительность БД, прозрачное для пользователей БД и собственная реализация в языках программирования может сделать использование прозрачным для программиста как с точки зрения использования, так и с точки зрения производительности сервера. Подобные методы могут быть применены для защиты от XSS и всех межъязыковых коммуникаций. Но, за исключением пары статей в блогах, написанных в то время, я нигде не могу упомянуть об этом.

Что случилось?

Answer 1

Что случилось? То, что произошло, - это то же самое, что происходит со многими хорошими идеями в области безопасности: оно ни к чему не привело по причинам, не зависящим от изобретателя. Это классная идея, но она требует принятия фреймворками и разработчиками приложений. И, что бы там ни было, спрос на такие решения безопасности не так высок. Для большинства разработчиков безопасность является второстепенным фактором. Многие разработчики приложений не думают, что у них есть проблема, и не видят необходимости в решении (большинство из них, вероятно, обманывают себя, но так и происходит). И многие из разработчиков, которые * знают о XSS, считают, что могут избежать этого, просто проявив осторожность (это сомнительное предложение, поскольку слишком легко совершить одну непреднамеренную ошибку, которая ставит под угрозу безопасность всей вашей системы). сайт, но эй, если они не чувствуют в этом необходимости, они не примут это).

Пожалуйста, поймите, что Interpolique - это не только внедрение SQL. Вы описываете это как внедрение SQL, но это не основной вклад. Его основной вклад - защита от XSS и других инъекционных атак. В выступлении Каминского обсуждается, как использовать Interpolique для предотвращения SQL-инъекций, но я подозреваю, что это в первую очередь педагогическое устройство. Interpolique - это общая защита от инъекционных атак, примерами которых являются SQL-инъекция и XSS. Внедрение SQL легче понять и проще понять, чем XSS, поэтому, вероятно, было проще объяснить идеи, лежащие в основе Interpolique в контексте внедрения SQL, чем XSS. Любой исследователь безопасности должен немедленно увидеть, как они применимы к контексту XSS, что является более важной и сложной проблемой. Как уже говорили другие, подготовленные операторы являются «достаточно хорошим» решением для внедрения SQL для практических целей (действительно, есть некоторые случаи, которые не обрабатываются подготовленными операторами, но они, вероятно, могут быть обработаны путем экранирования / проверки плюс тщательный аудит кода), так что это не то, где Interpolique является наиболее полезным.

Технология безопасности в этом пространстве, которая получила наибольшее распространение, - это контекстно-зависимое автоматическое экранирование , такое как , которое реализовано в ctemplate Google . Это требует поддержки фреймворка, но, возможно, даже лучше для разработчиков, чем Interpolique, потому что в большинстве ситуаций это не требует от разработчиков дополнительных усилий: для них экранирование выполняется автоматически. Кроме того, это также лучше для безопасности: экранирование выполняется по умолчанию, поэтому настройки по умолчанию безопасны, и разработчики должны предпринять какой-то явный шаг для отключения мер безопасности.

На этот вопрос могли быть получены более информированные ответы об обмене стеками IT Security. (Я не могу поверить, что один человек на самом деле написал: «Не знаю, кто такой парень Дэн Камински, но он понятия не имеет.« Надеюсь, это была шутка! Каминский - один из самых выдающихся и уважаемых исследователей / практиков в области компьютерной безопасности.) В Interpolique и аналогичных технологиях, обсуждаемых в области безопасности ИТ, можно найти следующие вопросы: Элементы DOM из белого списка для победы над XSS , Экранирующие константы JavaScript .

Answer 2

Пример, приведенный YCS, будет более понятным, если вы увидите, что на самом деле возвращается:

php > echo mysql_real_escape_string("1; DROP TABLE users;");
1; DROP TABLE users;
php > echo mysql_real_escape_string("1'; DROP TABLE users;");
1\'; DROP TABLE users;

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

Answer 3

Не знаю, кто этот парень Дэн Камински, но он понятия не имеет.

• Экранирование строк не бесполезно при правильном использовании (и, по сути, экранирование строк вообще не имеет ничего общего с инъекциями)
• Подготовленные заявления - это не то, что PITA, если их использовать с небольшим умом

Итак, оба его предположения явно неверны. Этого достаточно, чтобы все его рамки устарели.

Может быть, он просто осознал, что вскоре после публикации своей идеи - возможная причина, почему вы никогда не слышали об этом подходе снова.

Кстати, Mysql, например, имеет свою собственную функцию кодирования base16 из коробки:

mysql> SELECT 0x5061756c;
       -> 'Paul'

не требует идеалистических проектов для реализации. это не широко используется, хотя.

Тем не менее, я должен признать, что в отличие от побега, он не потерпит неудачу в случае неправильного использования.

Скажем, пресловутый случай неправильного побега (PHP / Mysql)

$spoiled_data = "1; DROP TABLE users;"
$spoiled_data = mysql_real_escape_string($spoiled_data);
$query        = "SELECT * FROM users where id=$spoiled_data";

при переносе в шестнадцатеричные строки способом

$spoiled_data = "1; DROP TABLE users;"
$spoiled_data = '0x'.bin2hex ($spoiled_data);
$query        = "SELECT * FROM users where id=$spoiled_data";

будет довольно безопасно.