Как хакеры захватывают веб-сайты с помощью SQL-инъекций и DDoS
Даже если вы только слабо следили за событиями хакерских групп 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; -". После простой замены запрос аутентификации становится:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ ГДЕ UserName = "Robert"; DROP TABLE Users; - 'AND Password = "errorpass"
Примечание: точка с запятой в SQL-запросе используется для обозначения конца определенного оператора и начала нового оператора.
Который выполняется базой данных как:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = "Robert"DROP TABLE Пользователи
Таким образом, мы использовали атаку SQLI для удаления всей таблицы Users..
Конечно, гораздо хуже может быть сделано, поскольку, в зависимости от разрешенных разрешений SQL, злоумышленник может изменить значения, сбросить таблицы (или всю базу данных) в текстовый файл, создать новые учетные записи для входа или даже взломать всю установку базы данных..
Предотвращение атаки SQL-инъекцией
Как мы уже упоминали несколько раз ранее, атаку SQL-инъекцией легко предотвратить. Одно из основных правил веб-разработки заключается в том, что вы никогда не должны слепо доверять пользовательскому вводу, как мы делали, когда выполняли простую подстановку в нашем шаблонном запросе выше..
Атака SQLI легко предотвращается тем, что называется дезинфекцией (или выходом) ваших входных данных. Процесс sanitize на самом деле довольно тривиален, поскольку все, что он делает, по сути, обрабатывает любые встроенные символы одинарных кавычек (') таким образом, что их нельзя использовать для преждевременного завершения строки внутри оператора SQL..
Например, если вы хотите найти «O'neil» в базе данных, вы не сможете использовать простую подстановку, потому что одиночная кавычка после O приведет к преждевременному завершению строки. Вместо этого вы очищаете его, используя escape-символ соответствующей базы данных. Давайте предположим, что escape-символ для встроенной одинарной кавычки префиксирует каждую кавычку символом \. Таким образом, «О'Нил» будет очищен как «О'Нил».
Этот простой акт санитарии в значительной степени предотвращает атаку SQLI. Чтобы проиллюстрировать это, давайте вернемся к нашим предыдущим примерам и увидим итоговые запросы, когда пользовательский ввод очищается.
MyUser»-- / wrongpass:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = "myuser \" - 'AND Password = "errorpass"
Поскольку одиночная кавычка после myuser экранируется (то есть считается, что она является частью целевого значения), база данных будет буквально искать имя пользователя "MyUser" -". Кроме того, поскольку тире включены в строковое значение, а не в сам оператор SQL, они будут считаться частью целевого значения, а не интерпретироваться как комментарий SQL.
Роберт'; DROP TABLE Пользователи;-- / wrongpass:
ВЫБЕРИТЕ ИДЕНТИФИКАТОР ИЗ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ UserName = "Robert \"; DROP TABLE Users; - 'AND Password = "errorpass"
Просто избегая одинарной кавычки после Роберта, точка с запятой и тире содержатся в строке поиска UserName, поэтому база данных будет искать буквально "Robert '; пользователи DROP TABLE; -" вместо выполнения таблицы удалить.
В итоге
Хотя веб-атаки развиваются и становятся все более изощренными или сосредоточены на другой точке входа, важно помнить о защите от проверенных и настоящих атак, которые вдохновили несколько свободно доступных «хакерских инструментов», предназначенных для их использования..
Определенные типы атак, такие как DDoS, не могут быть легко предотвращены, в то время как другие, такие как SQLI, могут. Однако ущерб, который может быть нанесен этими типами атак, может варьироваться от неудобства до катастрофического в зависимости от принятых мер предосторожности..
