Даже если вы лишь слабо следили за событиями хакерских групп Anonymous и LulzSec, вы, вероятно, слышали о взломанных веб-сайтах и сервисах, таких как печально известные взломы Sony. Задумывались ли вы, как они это делают?
Эти группы используют ряд инструментов и техник, и хотя мы не пытаемся дать вам руководство, чтобы сделать это самостоятельно, полезно понять, что происходит. Две атаки, о которых вы постоянно слышите, – «(распределенная) отказ в обслуживании» (DDoS) и «инъекции SQL» (SQLI). Вот как они работают.
Изображение xkcd
Атака отказа в обслуживании
Что это?
Атака «отказ в обслуживании» (иногда называемая «распределенным отказом в обслуживании» или DDoS) происходит, когда система, в данном случае веб-сервер, получает столько запросов одновременно, что ресурсы сервера перегружены, система просто блокируется. и выключается. Целью и результатом успешной DDoS-атаки является то, что веб-сайты на целевом сервере недоступны для законных запросов трафика.
Как это работает?
Логистика DDoS-атаки лучше всего объяснить на примере.
Представьте, что миллион человек (злоумышленники) собираются вместе с целью помешать бизнесу компании X, разрушив их колл-центр. Злоумышленники координируют свои действия, чтобы во вторник в 9 часов утра все они позвонили на номер телефона компании X. Скорее всего, телефонная система компании X не сможет обрабатывать миллион вызовов одновременно, поэтому все входящие линии будут связаны злоумышленниками. В результате этого законные звонки клиентов (то есть те, которые не являются злоумышленниками) не проходят, потому что телефонная система связана с обработкой вызовов от злоумышленников. Таким образом, по сути, Компания X потенциально теряет бизнес из-за невозможности дозволить законные запросы.
DDoS-атака на веб-сервер работает точно так же. Поскольку практически невозможно узнать, какой трафик поступает от законных запросов от злоумышленников, пока веб-сервер не обработает запрос, этот тип атаки обычно очень эффективен.
Выполнение атаки
Из-за “DruS-атаки” типа “грубой силы” вам нужно иметь множество компьютеров, которые должны быть одновременно скоординированы для атаки. Возвращаясь к нашему примеру с колл-центром, это потребовало бы, чтобы все злоумышленники знали, что они должны звонить в 9 утра и фактически звонить в это время. Хотя этот принцип, безусловно, сработает, когда речь заходит об атаке на веб-сервер, он становится значительно проще, когда используются компьютеры-зомби вместо реальных пилотируемых компьютеров.
Как вы, вероятно, знаете, существует множество вариантов вредоносных программ и троянских программ, которые, попав в вашу систему, бездействуют и иногда «звонят домой» для получения инструкций. Например, одной из этих инструкций может быть отправка повторных запросов на веб-сервер компании X в 9 часов утра. Таким образом, с помощью одного обновления исходного местоположения соответствующего вредоносного ПО, один злоумышленник может мгновенно координировать сотни тысяч скомпрометированных компьютеров для выполнения масштабной DDoS-атаки.
Прелесть использования зомби-компьютеров заключается не только в их эффективности, но и в анонимности, поскольку злоумышленнику вообще не нужно использовать свой компьютер для выполнения атаки.
Атака SQL-инъекций
Что это?
Атака «SQL-инъекция» (SQLI) – это эксплойт, использующий слабые методы веб-разработки и, как правило, в сочетании с ошибочной безопасностью базы данных. Результат успешной атаки может варьироваться от олицетворения учетной записи пользователя до полного взлома соответствующей базы данных или сервера. В отличие от DDoS-атаки, SQLI-атака полностью и легко предотвратима, если веб-приложение правильно запрограммировано.
Выполнение атаки
Каждый раз, когда вы входите на веб-сайт и вводите свое имя пользователя и пароль, для проверки ваших учетных данных веб-приложение может выполнить запрос, подобный следующему:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'myuser' И Пароль = 'mypass';
Примечание: строковые значения в запросе SQL должны быть заключены в одинарные кавычки, поэтому они появляются вокруг введенных пользователем значений.
Таким образом, комбинация введенного имени пользователя (myuser) и пароля (mypass) должна совпадать с записью в таблице Users для возврата идентификатора пользователя. Если совпадений нет, идентификатор пользователя не возвращается, поэтому учетные данные для входа недействительны. Хотя конкретная реализация может отличаться, механика довольно стандартная.
Итак, теперь давайте посмотрим на запрос проверки подлинности шаблона, в который мы можем подставить значения, которые пользователь вводит в веб-форме:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = ‘[user] ’AND Password =’ [pass]’
На первый взгляд это может показаться простым и логичным шагом для простой проверки пользователей, однако, если простая замена введенных пользователем значений выполняется на этом шаблоне, он подвержен атаке SQLI.
Например, предположим, что в поле имени пользователя введено «myuser’–», а в пароле – «неправильный пароль». Используя простую подстановку в нашем шаблонном запросе, мы получили бы это:
ВЫБЕРИТЕ ИДЕНТИФИКАЦИОННЫЙ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'myuser' - 'И Пароль =' неправильный пароль '
Ключом к этому утверждению является включение двух тире (-) . Это токен начала комментария для операторов SQL, поэтому все, что появляется после двух тире (включительно), будет игнорироваться. По сути, вышеуказанный запрос выполняется базой данных как:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'myuser'
Явным упущением здесь является отсутствие проверки пароля. Включив две черты как часть пользовательского поля, мы полностью обошли условие проверки пароля и смогли войти в систему как «myuser», не зная соответствующего пароля. Этот акт манипулирования запросом для получения непредвиденных результатов является атакой SQL-инъекции.
Какой урон можно нанести?
Атака SQL-инъекции вызвана небрежным и безответственным кодированием приложения и полностью предотвратима (о чем мы расскажем чуть позже), однако степень ущерба, который может быть нанесен, зависит от настройки базы данных. Чтобы веб-приложение могло взаимодействовать с внутренней базой данных, оно должно предоставить логин для базы данных (обратите внимание, что это отличается от логина пользователя для самого веб-сайта). В зависимости от того, какие разрешения требуются веб-приложению, этой соответствующей учетной записи базы данных может потребоваться что угодно, от разрешения на чтение/запись в существующих таблицах только до полного доступа к базе данных. Если сейчас это не ясно, несколько примеров должны помочь прояснить ситуацию.
На основе приведенного выше примера вы можете увидеть, что, введя, например, "youruser '-", "admin' -" или любое другое имя пользователя, мы можем сразу войти на сайт как этот пользователь, не зная пароля. Как только мы в системе, мы не знаем, что мы на самом деле не тот пользователь, поэтому у нас есть полный доступ к соответствующей учетной записи. Разрешения базы данных не обеспечат защитную сеть для этого, потому что, как правило, веб-сайт должен иметь по крайней мере доступ для чтения/записи к своей соответствующей базе данных.
Теперь давайте предположим, что веб-сайт имеет полный контроль над соответствующей базой данных, что дает возможность удалять записи, добавлять/удалять таблицы, добавлять новые учетные записи безопасности и т. Д. Важно отметить, что некоторым веб-приложениям могут потребоваться разрешения такого типа, поэтому автоматически не плохо, что полный контроль предоставляется.
Поэтому, чтобы проиллюстрировать ущерб, который может быть нанесен в этой ситуации, мы будем использовать пример, представленный в вышеприведенном комиксе, введя в поле имени пользователя следующее: "Robert '; DROP TABLE Users; -". После простой подстановки запрос аутентификации становится:
ВЫБЕРИТЕ UserID ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'Robert'; DROP TABLE Users; - 'AND Password =' неправильный пароль '
Примечание. Точка с запятой в SQL-запросе используется для обозначения конца определенного оператора и начала нового оператора.
Который выполняется базой данных как:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'Robert'
DROP TABLE Пользователи
Таким образом, мы использовали атаку SQLI для удаления всей таблицы Users.
Конечно, гораздо хуже может быть сделано, поскольку, в зависимости от разрешенных разрешений SQL, злоумышленник может изменить значения, сбросить таблицы (или всю базу данных) в текстовый файл, создать новые учетные записи для входа или даже взломать всю установку базы данных.
Предотвращение атаки с использованием SQL-инъекций
Как мы уже упоминали несколько раз ранее, атаку SQL-инъекцией легко предотвратить. Одно из основных правил веб-разработки заключается в том, что вы никогда не должны слепо доверять пользовательскому вводу, как мы делали, когда выполняли простую подстановку в нашем шаблонном запросе выше.
Атака SQLI легко предотвращается тем, что называется дезинфекцией (или выходом) ваших входных данных. Процесс sanitize на самом деле довольно тривиален, поскольку все, что он делает, по сути, обрабатывает любые встроенные символы одинарных кавычек (‘) таким образом, что их нельзя использовать для преждевременного завершения строки внутри оператора SQL.
Например, если вы хотите найти «O’neil» в базе данных, вы не сможете использовать простую подстановку, потому что одинарная кавычка после O приведет к преждевременному завершению строки. Вместо этого вы очищаете его, используя escape-символ соответствующей базы данных.Давайте предположим, что escape-символ для встроенной одинарной кавычки префиксирует каждую кавычку символом \. Так что «О’Нил» будет санирован как «О’Нил».
Этот простой акт санитарии в значительной степени предотвращает атаку SQLI. Чтобы проиллюстрировать это, давайте вернемся к нашим предыдущим примерам и увидим итоговые запросы, когда пользовательский ввод очищается.
myuser '- / неправильный пароль :
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'myuser \' - 'И Пароль =' неправильный пароль '
Поскольку после myuser используется одинарная кавычка (то есть она считается частью целевого значения), база данных будет буквально искать имя пользователя "myuser '-". Кроме того, поскольку включены тире внутри строкового значения, а не в самом операторе SQL, они будут считаться частью целевого значения, а не интерпретироваться как комментарий SQL.
Robert '; DROP TABLE Users; - / неправильный пароль :
ВЫБЕРИТЕ UserID ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = 'Robert \'; DROP TABLE Users; - 'AND Password =' неправильный пароль '
Просто избегая одинарной кавычки после Роберта, точка с запятой и тире содержатся в строке поиска UserName, поэтому база данных будет буквально искать "Robert '; DROP TABLE Users; -" вместо выполнения удаление таблицы
В итоге
Хотя веб-атаки развиваются и становятся все более изощренными или сосредоточены на другой точке входа, важно помнить о защите от проверенных и настоящих атак, которые послужили вдохновением для нескольких свободно доступных «хакерских инструментов», предназначенных для их использования.
Определенные типы атак, такие как DDoS, не могут быть легко предотвращены, в то время как другие, такие как SQLI, могут. Однако ущерб, который может быть нанесен этими типами атак, может варьироваться от неудобства до катастрофического в зависимости от принятых мер предосторожности.
