Существует множество инструментов и методов, которыми пользуются эти группы, и хотя мы не пытаемся дать вам руководство для этого сами, полезно понять, что происходит. Две из атак, которые вы последовательно слышите о них, - это «(распределенный) отказ в обслуживании» (DDoS) и «SQL Injections» (SQLI). Вот как они работают.
Изображение XKCD
Атака на отказ в обслуживании
Что это?
Атака «отказ в обслуживании» (иногда называемая «распределенным отказом в обслуживании» или DDoS) происходит, когда система, в этом случае веб-сервер, получает столько запросов за один раз, что ресурсы сервера перегружены, система просто блокирует и закрывается. Цель и результат успешной атаки DDoS - это сайты на целевом сервере, недоступные для законных запросов трафика.
Как это работает?
Например, логистика атаки DDoS лучше всего объясняется примером.
Представьте, что миллион человек (нападавших) собираются вместе с целью помешать бизнесу компании X, сняв свой колл-центр. Нападавшие координируют так, что во вторник в 9 часов утра все они будут звонить по номеру телефона компании X. Скорее всего, телефонная система компании X не сможет обрабатывать миллион звонков сразу, так что все входящие линии будут привязаны злоумышленниками. В результате законные клиентские звонки (т. Е. Те, которые не являются злоумышленниками) не проходят, потому что телефонная система связана с обработкой вызовов от злоумышленников. Таким образом, по существу Компания X потенциально теряет бизнес из-за того, что законные запросы не могут пройти.
Атака DDoS на веб-сервере работает точно так же. Поскольку практически невозможно узнать, какой трафик поступает от законных запросов против злоумышленников, пока веб-сервер не обработает запрос, этот тип атаки обычно очень эффективен.
Выполнение атаки
Из-за «грубой силы» характера DDoS-атаки вам нужно иметь много компьютеров, все из которых скоординированы для атаки одновременно. Повторяя пример нашего колл-центра, это потребует, чтобы все злоумышленники оба знали, чтобы позвонить в 9 часов утра и фактически позвонить в это время. Хотя этот принцип, безусловно, будет работать, когда дело доходит до нападения на веб-сервер, становится значительно проще, когда используются компьютеры-зомби, а не фактические персональные компьютеры.
Как вы, наверное, знаете, существует множество вариантов вредоносных программ и троянов, которые, как только в вашей системе, лежат бездействующими и иногда «звонят домой» для получения инструкций. Одна из этих инструкций могла бы, например, отправить повторные запросы на веб-сервер компании X в 9 часов утра. Таким образом, при одном обновлении до исходного местоположения соответствующих вредоносных программ один атакующий может мгновенно координировать сотни тысяч компьютеров с угрозами для выполнения массивной атаки DDoS.
Красота использования зомби-компьютеров не только в эффективности, но и в ее анонимности, так как злоумышленник фактически не должен использовать свой компьютер для выполнения атаки.
SQL-инъекция
Что это?
Атака «SQL-инъекция» (SQLI) - это эксплойт, который использует плохие методы веб-разработки и, как правило, в сочетании с ошибочной безопасностью базы данных. Результат успешной атаки может варьироваться от олицетворения учетной записи пользователя до полного компрометации соответствующей базы данных или сервера. В отличие от атаки DDoS, атака SQLI полностью и легко предотвращается, если веб-приложение запрограммировано соответствующим образом.
Выполнение атаки
Всякий раз, когда вы входите на веб-сайт и вводите свое имя пользователя и пароль, чтобы проверить ваши учетные данные, веб-приложение может запускать запрос следующим образом:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Примечание: строковые значения в SQL-запросе должны быть заключены в одинарные кавычки, поэтому они появляются вокруг введенных пользователем значений.
Таким образом, комбинация введенного имени пользователя (myuser) и пароля (mypass) должна соответствовать записи в таблице Users, чтобы возвращаемый UserID возвращался. Если совпадения нет, идентификатор пользователя не возвращается, поэтому учетные данные для входа недействительны. Хотя конкретная реализация может отличаться, механика довольно стандартная.
Итак, теперь давайте посмотрим на запрос проверки подлинности шаблона, который мы можем подставить значениям, которые пользователь вводит в веб-форме:
SELECT UserID FROM Users WHERE UserName='[user]’ AND Password='[pass]’
На первый взгляд это может показаться простым и логичным шагом для простой проверки пользователей, однако, если для этого шаблона выполняется простая подстановка введенных пользователем значений, он восприимчив к атаке SQLI.
Например, предположим, что «myuser'-» вводится в поле имени пользователя, а «пароль» вводится «неправильный пароль». Используя простую замену в нашем запросе шаблона, мы получим следующее:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Ключом к этому утверждению является включение двух тире
(--)
Это токен начала комментария для операторов SQL, поэтому все, что появляется после двух тире (включительно), будет проигнорировано. По существу, вышеуказанный запрос выполняется базой данных следующим образом:
SELECT UserID FROM Users WHERE UserName='myuser'
Вопиющим упущением здесь является отсутствие проверки пароля.Включив две тире как часть поля пользователя, мы полностью обошли условие проверки пароля и смогли войти в систему как «myuser», не зная соответствующего пароля. Этот акт манипулирования запросом для создания непреднамеренных результатов - это инъекция SQL-инъекций.
Какой ущерб можно сделать?
Атака SQL-инъекций вызвана небрежным и безответственным применением кодирования и полностью предотвращается (что мы рассмотрим в одно мгновение), однако степень ущерба, который может быть нанесен, зависит от настройки базы данных. Чтобы веб-приложение связывалось с базой данных, приложение должно предоставить логин в базу данных (обратите внимание, что это отличается от входа пользователя на сам веб-сайт). В зависимости от того, какие разрешения требуется веб-приложению, эта соответствующая учетная запись базы данных может требовать от разрешения на чтение и запись в существующих таблицах только полного доступа к базе данных. Если это не ясно сейчас, несколько примеров должны помочь обеспечить определенную ясность.
На основании приведенного выше примера вы можете видеть, что, введя, например,
'youruser'--', 'admin'--'
или любое другое имя пользователя, мы можем мгновенно войти на сайт в качестве этого пользователя, не зная пароля. Как только мы находимся в системе, мы не знаем, что мы на самом деле не являемся этим пользователем, поэтому у нас есть полный доступ к соответствующей учетной записи. Разрешения для базы данных не предоставляют для этого защитную сетку, поскольку, как правило, веб-сайт должен иметь, по крайней мере, доступ для чтения / записи к своей соответствующей базе данных.
Теперь давайте предположим, что веб-сайт полностью контролирует свою соответствующую базу данных, которая дает возможность удалять записи, добавлять / удалять таблицы, добавлять новые учетные записи безопасности и т. Д. Важно отметить, что некоторым веб-приложениям может понадобиться этот вид разрешения, чтобы он не является автоматически плохим, что полный контроль предоставляется.
Поэтому, чтобы проиллюстрировать ущерб, который может быть нанесен в этой ситуации, мы будем использовать пример, приведенный в комиксе выше, введя следующее в поле имени пользователя:
'Robert'; DROP TABLE Users;--'.
После простой подстановки запрос аутентификации становится:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Примечание: точка с запятой в SQL-запросе используется для обозначения конца конкретного оператора и начала нового оператора.
Который выполняется в базе данных следующим образом:
SELECT UserID FROM Users WHERE UserName='Robert'
DROP TABLE Пользователи
Таким образом, мы использовали атаку SQLI для удаления всей таблицы Users.
Конечно, гораздо хуже может быть сделано, поскольку, в зависимости от разрешенных разрешений SQL, злоумышленник может изменять значения, дамп-таблицы (или всю базу данных) в текстовый файл, создавать новые учетные записи или даже захватывать всю установку базы данных.
Предотвращение атаки SQL-инъекций
Как мы уже говорили несколько раз ранее, атака SQL-инъекцией легко предотвращается. Одним из основных правил веб-разработки является то, что вы никогда не слепо доверяете пользовательскому вводу, как это было при выполнении простой подстановки в нашем запросе шаблона выше.
Атака SQLI легко пресекается тем, что называется дезинфекцией (или ускользанием) ваших входов. Процесс дезинфекции на самом деле довольно тривиален, поскольку все, что он по существу делает, - это обработать любые встроенные символы одиночной кавычки (') соответствующим образом, чтобы они не могли использоваться для преждевременного завершения строки внутри оператора SQL.
Например, если вы хотите найти «O'neil» в базе данных, вы не сможете использовать простую подстановку, потому что одинарная кавычка после O приведет к преждевременному завершению строки. Вместо этого вы дезинфицируете его, используя escape-символ соответствующей базы данных. Предположим, что escape-символ для встроенной одинарной кавычки предваряет каждую цитату символом. Таким образом, «О'неал» будет дезинфицирован как «О'Нейл».
Этот простой акт санитарии в значительной степени предотвращает атаку SQLI. Чтобы проиллюстрировать это, вернемся к нашим предыдущим примерам и посмотрим на возникающие запросы, когда пользовательский ввод будет дезинфицирован.
myuser'--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Поскольку одиночная кавычка после myuser экранирована (что означает, что она считается частью целевого значения), база данных будет в буквальном смысле искать имя пользователя
'myuser'--'.
Кроме того, поскольку тире включены в строковое значение, а не в сам оператор SQL, они будут считаться частью целевого значения, а не интерпретироваться как комментарий SQL.
Robert'; DROP TABLE Users;--
/ wrongpass:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Просто избегая одиночной цитаты после Роберта, точки с запятой и тире содержатся в строке поиска UserName, поэтому база данных будет искать в буквальном смысле поиск
'Robert'; DROP TABLE Users;--'
вместо выполнения удаления таблицы.
В итоге
В то время как веб-атаки развиваются и становятся более изощренными или сосредоточены на другой точке входа, важно помнить о том, чтобы защитить от попыток и истинных атак, которые были источником нескольких свободно доступных «хакерских инструментов», предназначенных для их использования.
Некоторые типы атак, такие как DDoS, не могут быть легко устранены, в то время как другие, такие как SQLI, могут. Однако ущерб, который может быть нанесен этими типами атак, может варьироваться от неудобства до катастрофического в зависимости от принятых мер предосторожности.
