exp-inj

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% гарантию не дает даже госстрах. хотя, идея застраховать сайт в страховой компании не такая уж и бредовая, какой кажется на первый взгляд. по крайней мере, в случае атаки, компания компенсирует нанесенный ею ущерб. а если серьезно, то все решает сложность. несколько сотен строк можно проверить и вдоль и поперек, но трудоемкость проверки кода растет быстрее его объема и начиная с некоторого уровня становится практически невыполнимой задачей, требующей гигантских ресурсов. следовательно, лучшая защита — это простота.