Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

articles:exp-inj [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== exp-inj ======
 +<​sub>​{{exp-inj.odt|Original file}}</​sub>​
 +
 +====== SQL Injection/​XSS ======
 +
 +криска ака мыщъх
 +
 +# SQL Injection получила широкую огласку благодаря уязвимости сайтов,​
 +
 +# а web - давно уже массовый. Но где еще можно встретить SQL Injection?
 +
 +наверное,​ везде, где стоит SQL, обрабатывающий не отфильтрованные пользовательские запросы. достаточно многие программы,​ работающие с базами данных используют SQL. клиентское приложение,​ взаимодействует с пользователем и генерирует SQL-запросы,​ посылая их серверу. в правильно спроектированной системе — разграничение доступа к данным осуществляется на сервере. это вообще не забота клиента. клиент вправе слать любые запросы. но далеко не все разработчики это понимают (или реализуют должным образом) в результате чего часть (или все) проверки "​имеет ли право пользователь выполнять данную SQL-операцию"​ осуществляются на клиентской стороне,​ внутри программы. обычный пользователь,​ действительно,​ не может обойти защиту,​ т.к. наталкивается на интерфейс ;) но хакер легко направит запрос к SQL серверу по сети и тот послушно выполнит его со всеми вытекающими отсюда последствиями (а иногда никакой сети вообще нет, SQL-"​сервер"​ представляет собой локальную программу).
 +
 +тем не менее, web-интерфейс является одним из самых полярных способов взаимодействия с базами данных (особенно удаленными) и актуальность атак типа SQL Injection в обозримом будущем снижаться не собирается.
 +
 +# 2. Какие способы борьбы с SQL Injection наиболее эффективны?​
 +
 +разграничение доступа к данным на уровне SQL-сервера. но проблема здесь в том, что с точки зрения SQL-сервера,​ обрабатывающего запросы web-сервера,​ под которым "​вращаться"​ сайт, написанный на PHP или Perl'​е,​ все запросы равнозначны,​ поскольку авторизация пользователей (даже если она и предусмотрена) как правило осуществляется на PHP, просто в SQL-базе хранятся пользователи с паролями,​ проверяемыми PHP-скриптом,​ а для SQL есть только один пользователь — сам PHP скрипт.
 +
 +причем,​ PHP вообще не самый безопасный язык программирования (как, впрочем,​ и Perl). он допускает интерполяцию строк и вообще любит разводить самодеятельность. на Си написать безопасный сайт намного проще, но… тут уже возникают проблемы иного рода: переносимость,​ переполнение буферов (фундаментальная проблема Си) и т.д. и т.п.
 +
 +так что остается… нанимать грамотных программистов,​ имеющих реальный опыт и давать им реальные сроки, поскольку подавляющее большинство ошибок совершается из-за невнимательности,​ излишней суетливости и нервозности,​ вызванной нависающий дедлайном.
 +
 +# 3. XSS - новая угроза или исключительно слабое место пофигистов?​
 +
 +с каких это пор она стала новой? если я правильно понимаю,​ то XSS есть Cross-site scripting, появившийся когда Netscape добавила в браузер поддержку JavaScript, а это не вчера и не позавчера,​ а много лет назад было. и сейчас без скриптовых языков никуда. стоит только отключить их поддержку,​ как значительная часть сайтов отображаются неверно или вообще перестают работать. а модель (не)безопасности виртуальных машин давно стала притчей во языцах и еще ни одному производителю не удалось избежать ошибок реализации. в лучшем случае злоумышленник получает доступ к cookies'​ам (хранящим массу конфиденциальной информации). в худшем же… полностью захватывает управление удаленной машиной. это вполне серьезная угроза с которой необходимо считаться.
 +
 +# 4. Какие способы борьбы с XSS наиболее эффективны?​
 +
 +отключить поддержку Java и Ко в браузере,​ а если это невозможно,​ использовать наиболее аккуратно написанные бразуеры (например,​ Оперу). IE дыряв как ведро без дна, в Горящем Лисе в последнее время наблюдается обвальный рос уязвимостей,​ превративших его в друшлаг. так что никто не может чувствовать себя в безопасности,​ разве что пользователи рыся (бразузера Lynx :), не путать с Linux.
 +
 +# 5. Можно ли защитить динамический сайт (есть скрипты,​ работающие с БД)
 +
 +# на 100% от SQL Injection и XSS? Как?
 +
 +100% гарантию не дает даже госстрах. хотя, идея застраховать сайт в страховой компании не такая уж и бредовая,​ какой кажется на первый взгляд. по крайней мере, в случае атаки, компания компенсирует нанесенный ею ущерб. а если серьезно,​ то все решает сложность. несколько сотен строк можно проверить и вдоль и поперек,​ но трудоемкость проверки кода растет быстрее его объема и начиная с некоторого уровня становится практически невыполнимой задачей,​ требующей гигантских ресурсов. следовательно,​ лучшая защита — это простота.
 +
 +