 |
Предотвращение атак SQL Injection
|
|
|
|
Если вы тщательно разрабатываете скрипты и приложения, атаки SQL injection будут мало вероятны. Существует много вещей, которые разработчики могут сделать, чтобы уменьшить угрозу атаки сайта.
Ограничить доступ пользователей
Системный аккоунт по-умолчанию для SQL сервера 2000 не должен использоваться. Не следует заводить специальных аккоунтов для специальных целей.
Например, если вы работаете с базой данных, где разрешен доступ пользователей к таблицам заказа товара, тогда вам следует сформировать пользователя с именем webUser_public, который имеет права SELECT для таблицы товаров, и права INSERT для таблицы заказов.
Если вы не используете расширенные процедуры, имеете неиспользуемые триггеры или функции, определенные пользователем и т.д., удалите их или перенесите на изолированный сервер. Большинство наиболее разрушительных атак SQL injection пытаются использовать несколько расширенных, запомненных процедур, таких как xp_cmdshell и xp_grantlogin, таким образом, удаляя их, вы теоретически блокируете атаку до ее попытки.
Escape Quotes
Как мы видели из примеров, обсужденных, большинство атак инжекции требуют, чтобы пользователь завершал выражение одиночной кавычкой. Используя простую функцию замещения и преобразуя одиночные кавычки в двойные, вы заметно уменьшите вероятность успешной атаки.
Используя ASP, очень просто сформировать общую функцию подмены, которая будет иметь следующий вид:
<%
function stripQuotes(strWords)
stripQuotes = replace(strWords, "'", "''")
end function
%>
Теперь, если вы используете функцию stripQuotes в сочетании с нашим первым вариантом запроса, тогда последует:
select count(*) from users where userName='john' and
userPass='' or 1=1 --'
или:
select count(*) from users where userName='john'' and
userPass=''' or 1=1 --'
|
|
|
Это сделает атаки injection практически невозможными, так как ограничение WHERE теперь требует одновременной корректности полей userName и userPass.
Удалить потенциально опасные символы и символьные последовательности
Как было показано выше, определенные символы и последовательности символов, такие как;, --, select, insert и xp_, могут использоваться для реализации атаки SQL injection. Удаляя эти символы и сочетания символов из входного потока пользователя до формирования запроса, мы можем уменьшить шанс подобной атаки в будущем.
Как в случае с одиночной кавычкой для обработки всего этого нам нужна базовая функция:
<%
function killChars(strWords)
dim badChars
dim newChars
badChars = array("select", "drop", ";", "--", "insert",
"delete", "xp_")
newChars = strWords
for i = 0 to uBound(badChars)
newChars = replace(newChars, badChars(i), "")
next
killChars = newChars
end function
%>
Использование stripQuotes в сочетании с killChars существенно уменьшает шанс успеха любой атаки SQL. Так, если мы имеем запрос:
select prodName from products where id=1; xp_cmdshell 'format
c: /q /yes '; drop database myDB; --
и реализуем его через stripQuotes и далее killChars, он завершится примерно следующим образом:
prodName from products where id=1 cmdshell ''format c:
/q /yes '' database myDB
...что в принципе бесполезно, так как не возвращает никакой информации.
Ограничьте длину ввода для пользователя
Не разумно иметь текстовое поле формы, допускающее ввод 50 или более символов, если размер эталонной строки не превышает 10.
Если вы воспринимаете строку запроса для ID товара или в качестве функции фильтрации (проверки) входных данных, например, IsNumeric() для ASP. Так если величина не является числовой, генерируется ошибка либо пользователь переадресуется на другую страницу, где он сможет выбрать нужный ему товар.
Старайтесь переправлять вашу форму с привлечением метода POST, что не даст пользователям возможности отслеживать параметры формы, следующие в конце URL.
Атака SQL injection возможна и в случае MySQL, Oracle и любой другой базы данных. Смотри также An Anatomy of a Web Hack: SQL Injection Explained. Для обеспечения противодействия атакам SQL-injection нужно тщательно отлаживать скрипты, выполняющие обработку SQL-запросов, в особенности в части обработки параметров запроса.
|
|
|
ARP-spoofing
Атака ARP spoofing (ARP-фальсификация), известна также под названиями ARP flooding ("наводнение"), ARP poisoning ("отравление") или ARP poison routing (APR - вредоносная переадресация), является технологией атак локальных сетей (LAN). Смотри, например, соответствующую статью в Wikipedia. ARP spoofing позволяет хакеру перехватывать информационные пакеты в LAN, модифицируя или даже блокирую трафик. Атака может быть предпринята только против сети, где используется протокол ARP (Address Resolution Protocol). В частности, этот метод не работает для сетей, работающих с IPv6.
В случае ARP spoofing атакер посылает фальсифицированный ARP-запрос. Главная цель хакера установить связь между MAC-адресом его машины и IP-адресом другого компьютера (например, сетевого шлюза).
Если такое хакеру удастся, то все пакеты, адресованные сетевому шлюзу, будут посылаться машине хакера. Атакер может переадресовывать эти пакеты настоящему шлюзу или модифицировать данные перед последующей переадресацией (атака человек-по-середине). Атакер может предпринять D0S-атаку против машины жертвы, подменив МАС-адрес шлюза на МАС-адрес машины жертвы.
Может показаться, что такая атака слишком рискована, так как машина атакера может быть легко локализована, так как она должна размещаться внутри атакуемой LAN. Но это не всегда так, ведь атакер может действовать из взломанной ранее машины.
Фальсификация межсайтовых запросов CSRF (Cross-Site Request Forgeries)
Уязвимости CSRF часто путают с XCC. Однако CSRF не полагается на активные скрипты стороны клиента, вместо этого CSRF использует для выполнения нежелательных действий соединение клиента с вредоносным WEB-сайтом. Примером использования этой уязвимости можно назвать phpMyAdmin (CVE-2006-5116). В этом примере удаленный атакер выполняет неавторизованные действия, прикидываясь одним из пользователей и установив ссылку на специально созданный URL. Известны случаи реализации CSRF при работе с DSL-маршрутизатором. Смотри Cross-site request forgery.
В случае CSRF невинные на вид сайты генерируют запросы к различным другим сайтам, эти атаки используют уязвимости, например, в Twitter, позволяя владельцам сайтов получать данные о профайлах посетителей Twitter.
|
|
|
Обход фильтра XSS
Огромное число атак, основанных на XSS, вынудило сетевых администраторов использовать специальные фильтры. Это достаточно эффективное средство против XSS за исключением случаев, когда WEB-сайт должен поддерживать многонациональных пользователей. Это связано с тем, что большинство XSS-фильтров предполагают использование определенного символьного набора для заданного языка. Чтобы обойти XSS-фильтр хакер просто производит переключение, например с UTF-8 на US-ASCII.
|
|
|
