Сводка распространенных атак и средств защиты веб-безопасности

задняя часть внешний интерфейс Безопасность
Сводка распространенных атак и средств защиты веб-безопасности

Веб-безопасность — очень важная тема для веб-практиков, поэтому здесь представлен краткий обзор знаний о сетевых атаках и защите. Основное содержание этой статьи сегодня состоит в анализе нескольких распространенных видов атак и методов защиты.

Может быть, у вас есть определенное понимание всех вопросов безопасности, но самое главное — постоянно затягивать строку безопасности в процессе кодирования и проектирования, вам нужно неоднократно тщательно проверять каждую деталь реализации, а безопасность — это не тривиальное дело.
Демонстрация кода в этой статье основана на Node.js, и можно также сослаться на другие серверные языки.

XSS

Прежде всего, поговорим о самой распространенной XSS-уязвимости, XSS (Cross Site Script), атаке с использованием межсайтовых сценариев, поскольку аббревиатура пересекается с CSS (Cascading Style Sheets), поэтому ее можно назвать только XSS.

Принцип XSS заключается в том, что злоумышленник вставляет вредоносный исполняемый код сценария веб-страницы в веб-страницу. Когда пользователь просматривает страницу, код сценария, встроенный в Интернет, будет выполняться, чтобы злоумышленник мог украсть информацию о пользователе или другие нарушения. Цель безопасности и конфиденциальности пользователей. Методы XSS-атак постоянно меняются, но их можно условно разделить на несколько типов.

Непостоянный XSS

Непостоянные уязвимости XSS, также известные как отражающие уязвимости XSS, обычно отправляются другим путем отправки URL-адресов с параметрами кода вредоносного скрипта.При открытии URL-адреса уникальные параметры вредоносного кода анализируются и выполняются с помощью HTML.

非持久型 XSS

В качестве примера предположим, что ваша веб-страница содержит следующий код:

Select your language:
<select>
    <script>
        document.write(''
            + '<option value=1>'
            +     location.href.substring(location.href.indexOf('default=') + 8)
            + '</option>'
        );
        document.write('<option value=2>English</option>');
    </script>
</select>

Злоумышленник может напрямую передать URL-адрес (что-то вроде:спасибо.com/thank you?default=…) для внедрения кода исполняемого скрипта.

Непостоянные атаки XSS-уязвимости имеют следующие особенности:характерная черта:

  • Немедленно, без серверного хранилища, атака может быть завершена напрямую через HTTP-запросы GET и POST для получения данных о конфиденциальности пользователя.
  • Злоумышленник должен обмануть щелчок
  • Низкий уровень обратной связи, что затрудняет обнаружение и реагирование на исправления
  • Украсть важную и конфиденциальную информацию пользователя

дляПредотвращение непостоянных XSS-уязвимостей, вам необходимо убедиться в следующем:

  • Все содержимое или визуализированные данные, отображаемые веб-страницей, должны поступать с сервера.
  • старайтесь не начинать с URL,document.referrer,document.formsПодождите, пока данные, полученные из этого DOM API, будут обработаны напрямую.
  • попробуй не использоватьeval, new Function(),document.write(),document.writeln(),window.setInterval(),window.setTimeout(),innerHTML,document.creteElement()и другие методы исполняемых строк.
  • Если вы не можете сделать вышеуказанные точки, вы также должны избежать параметров строки, передаваемых методам, связанным с рендерингом DOM.
  • При внешнем рендеринге вам нужно выполнить escape-кодирование для любого поля.
Целью escape-экранирования является экранирование некоторых элементов, составляющих теги HTML, таких как<,>,空格д., бежать в<,>, и т. д. для отображения escape-символов. Есть много инструментов с открытым исходным кодом, которые могут помочь нам избежать побега.

Постоянный XSS

Постоянные уязвимости XSS, также известные как сохраненные уязвимости XSS, обычно существуют в интерактивных функциях, таких как отправка форм, таких как публикация сообщения, отправка текстовой информации и т. д., уязвимости XSS, используемые хакерами, отправка контента через обычные функции в базу данных для постоянного хранилище. Когда интерфейсная страница получает внедренный код, который серверная часть считывает из базы данных, она просто отображает и выполняет его.

Основной метод внедрения страниц аналогичен непостоянным XSS-уязвимостям, за исключением того, что постоянные — не из URL-адресов, рефереров, форм и т. д., а из данных, считываемых из базы данных бэкэндом. Постоянные XSS-атаки не должны обманывать клики, хакерам нужно только завершить инъекцию в месте отправки формы, но стоимость этой XSS-атаки относительно высока. Успешная атака требует одновременного выполнения следующих условий:

  • Серверная часть запроса POST для отправки формы сохраняется напрямую без экранирования.
  • Серверная часть извлекает данные из базы данных без экранирования и напрямую выводит их во внешний интерфейс.
  • Внешний интерфейс получает внутренние данные и отображает их непосредственно в DOM без экранирования.

Постоянный XSS имеет следующееФункции:

  • Постоянство, встроенное в базу данных
  • Ущерб обширен, и он может даже превратить машину пользователя в жаровню для DDoS-атак.
  • Украсть конфиденциальную личную информацию пользователей

дляПредотвращение постоянных XSS-уязвимостей, требует совместных усилий переднего и заднего концов:

  • Серверная часть должна решить не доверять никаким внешним данным перед сохранением и единообразно экранировать все поля.
  • Серверная часть равномерно избегает вывода данных во внешний интерфейс.
  • Внешний интерфейс должен не доверять каким-либо внутренним данным при рендеринге DOM страницы, и любые поля должны быть экранированы.

XSS на основе набора символов

На самом деле, многие браузеры и различные библиотеки с открытым исходным кодом специально разработаны для экранирования XSS и по умолчанию пытаются противостоять большинству атак XSS, но все еще существует множество способов обойти правила экранирования, что затрудняет предотвращение. Например, «XSS-атака на основе набора символов» — это метод атаки, позволяющий обойти эти экранирующие обработки. Например, набор символов некоторых веб-страниц не является фиксированным, и пользователь вводит символы в неожиданном наборе символов, иногда обходя escape-последовательность. правила фильтрации.

В качестве примера возьмем XSS на основе utf-7.
utf-7 — это набор символов, который может представлять весь Юникод в 7-битном формате (но теперь он удален из спецификации Юникода).
В этом наборе символов для представления всех символов 7-битным, за исключением чисел и некоторых символов, остальные части будут отображаться на основе кодировки base64.

<script>alert("xss")</script>
可以被解释为：
+ADw-script+AD4-alert(+ACI-xss+ACI-)+ADw-/script+AD4-

Причина, по которой может формироваться «XSS-атака на основе набора символов», заключается в том, что браузер имеет механизм автоматического определения кодировки, когда кодировка не указана в мета, поэтому этот тип атаки обычно происходит, когда кодировка метатега не указан или не был указан вовремя.

Итак, что мы можем сделать, чтобы избежать этого XSS?

  • не забудьте указать<meta charset="utf-8">
  • В XML не только набор символов должен быть указан как utf-8, но и теги должны быть закрыты
  • Ниу Вен рекомендует:drops.wooyun.org/papers/1327(Это очень подробно)

Межсайтовый XSS на основе Flash

Межсайтовый XSS на основе Flash также является разновидностью рефлексивного XSS.Хотя продуктовых линеек для разработки ActionScript почти нет, отмечу, что сценарии AS могут принимать пользовательский ввод и манипулировать файлами cookie, а злоумышленники могут сотрудничать с другими XSS (постоянными XSS). .type или непостоянный) метод для внедрения вредоносных SWF-файлов на страницу. В основном из-за того, что AS иногда необходимо взаимодействовать с JS для передачи параметров, злоумышленники будут подделывать параметры с помощью вредоносной инъекции XSS, красть файлы cookie и манипулировать ими.

Как избежать:

  • Строго управлять разрешениями на чтение и запись для файлов cookie.
  • Фильтрация и экранирование параметров, которые Flash может принимать при вводе пользователем.

Неподтвержденный переход XSS

В некоторых сценариях серверной части необходимо выполнить перенаправление 302 на входящий параметр URL-адреса для перенаправления, который может содержать некоторую конфиденциальную информацию о пользователе (файлы cookie). Если сервер выполняет переход 302, адрес перехода поступает из ввода пользователя, и злоумышленник может ввести злонамеренный адрес перехода для выполнения сценария.

В настоящее время вам необходимо предотвратить такие уязвимости:

  • Сделайте белый список или какую-либо фильтрацию правил для параметров URL, которые будут перенаправлены.
  • Серверная часть уделяет внимание защите конфиденциальной информации, такой как файлы cookie, с помощью проверки происхождения.

CSRF

CSRF (подделка межсайтовых запросов), китайское название: атака с подделкой межсайтовых запросов.

Так что же может CSRF? Понять это можно просто: злоумышленник может украсть ваши данные для входа и отправлять различные запросы под вашей личностью. Пока злоумышленник использует небольшие приемы социальной инженерии, такие как ссылки, отправляемые через программное обеспечение чата, такое как QQ (некоторые из них замаскированы под короткие доменные имена, пользователи не могут их различить), злоумышленник может заставить пользователя веб-приложения выполнить предустановку злоумышленника. , действовать. Например, когда пользователь входит в онлайн-банк, чтобы проверить баланс своего депозита, и щелкает ссылку, отправленную другом QQ, прежде чем выйти из системы, средства с банковского счета пользователя могут быть переведены на счет, указанный злоумышленником.

Поэтому при столкновении с CSRF-атакой она представляет серьезную угрозу для данных и инструкций конечного пользователя. Атаки CSRF ставят под угрозу все веб-приложение, если у скомпрометированного конечного пользователя есть учетная запись администратора.

Принципы CSRF

Следующий рисунок примерно описывает принцип CSRF-атаки, которую можно понимать как вора, который получил ключ от вашего дома, где вы предоставили ключ, а затем взял его и украл все, что он хотел украсть из вашего дома.

csrf原理

Для завершения атаки CSRF необходимо выполнить три условия:

  1. Пользователь вошел на сайт А, и файл cookie записывается локально.
  2. Не выходя из системы с сайта А (то есть с действующими файлами cookie), пользователь посещает опасный сайт Б (сайт Б требует доступа к сайту А), предоставленный злоумышленником.
  3. Сайт A не выполняет никакой защиты от CSRF

Вы можете спросить: «Если я не выполню ни одно из трех условий выше, CSRF не будет атаковать меня». На самом деле это можно сказать, но вы не можете гарантировать, что не произойдет следующее:

  • Вы не можете гарантировать, что после входа на веб-сайт вы больше не будете открывать вкладку и посещать другой веб-сайт, особенно теперь, когда браузеры поддерживают несколько вкладок.
  • Вы не можете гарантировать, что срок действия вашего локального файла cookie истечет сразу после закрытия браузера и завершения вашего последнего сеанса.
  • Так называемый атакующий веб-сайт B на приведенном выше рисунке может быть надежным и часто посещаемым веб-сайтом с другими уязвимостями.

Предотвратить CSRF

Защита от CSRF может начинаться как со стороны сервера, так и со стороны клиента, эффект защиты лучше со стороны сервера, теперь общая защита от CSRF также осуществляется на стороне сервера. Есть много способов предотвратить CSRF-атаки на стороне сервера, но идеи схожи, в основном, в следующих двух аспектах:

  • Надлежащее использование запросов GET, POST и файлов cookie
  • Добавить токен в запрос без GET

Вообще говоря, обычные веб-приложения в основном основаны на запросах GET и POST, а еще один запрос — это метод cookie. Обычно мы разрабатываем запросы приложений в соответствии со следующими правилами:

  • Запросы GET обычно используются при просмотре, перечислении, отображении и т. д. не требуют изменения атрибутов ресурсов (при запросе к базе данных)
  • POST-запросы часто используются при отправке формы From, при изменении свойств ресурса или выполнении каких-либо других действий (когда в базе данных есть вставка, обновление, удаление)

Когда запросы GET и POST используются правильно, все остальное — это добавление случайных чисел к запросам, отличным от GET. Есть примерно три способа сделать это:

  • Создайте уникальный токен cookie для каждого пользователя., все формы содержат одно и то же псевдослучайное значение.Эта схема является самой простой, так как злоумышленник не может получить сторонний cookie (теоретически), поэтому данные в форме не могут быть сконструированы.Поэтому эта схема должна быть безопасной без XSS.

  • Используйте капчу для каждого запроса POST, это решение относительно идеально, но требует от пользователя ввода кода подтверждения несколько раз, а взаимодействие с пользователем относительно плохое, поэтому оно не подходит для большого количества бизнес-приложений.

  • При отображении форм включите csrfToken для каждой формы., при отправке формы принесите csrfToken, а затем выполните проверку csrfToken на бэкенде.

Защита CSRF может быть выбрана в соответствии с различными сценариями применения. Защитная работа CSRF действительно принесет много дополнительного объема разработки на основе обычной бизнес-логики, но эта рабочая нагрузка того стоит, ведь конфиденциальность пользователей и безопасность собственности являются наиболее фундаментальными основами продукта.

SQL-инъекция

SQL Injection — одна из самых распространенных уязвимостей безопасности в веб-разработке. Его можно использовать для получения конфиденциальной информации из базы данных или использования характеристик базы данных для выполнения ряда вредоносных операций, таких как добавление пользователей и экспорт файлов, и даже возможно получить самые высокие привилегии базы данных и даже системы. пользователи.

Причина SQL-инъекции заключается в том, что у программы нет эффективного выхода для фильтрации ввода пользователя, так что злоумышленник успешно отправляет вредоносный код SQL-запроса на сервер, а программа ошибочно выполняет ввод злоумышленника как часть оператора запроса после получения it. , что приводит к изменению исходной логики запроса и дополнительному выполнению вредоносного кода, тщательно созданного злоумышленником.

Многие веб-разработчики не осознают, что SQL-запросы можно подделать, и рассматривают SQL-запросы как доверенные команды. Как всем известно, SQL-запросы могут обходить контроль доступа и, таким образом, обходить проверку подлинности и разрешений. Более того, с помощью SQL-запросов можно запускать команды уровня системы хоста.

Принцип внедрения SQL

Далее будет подробно объяснен принцип SQL-инъекций на некоторых реальных примерах.

Рассмотрим следующую простую форму входа администратора:

<form action="/login" method="POST">
    <p>Username: <input type="text" name="username" /></p>
    <p>Password: <input type="password" name="password" /></p>
    <p><input type="submit" value="登陆" /></p>
</form>

Внутренний оператор SQL может выглядеть следующим образом:

let querySQL = `
    SELECT *
    FROM user
    WHERE username='${username}'
    AND psw='${password}'
`;
// 接下来就是执行 sql 语句...

Цель состоит в том, чтобы проверить правильность имени пользователя и пароля. Само собой разумеется, что приведенный выше оператор SQL не является неверным на первый взгляд. Он действительно может достичь нашей цели, но вы только стоите в перспективе, что пользователи будут честно вводить в соответствии с к вашему дизайну. Приходите, чтобы увидеть проблему, если злоумышленник вводит имя пользователя, котороеzoumiaojiang' OR 1 = 1 --, введите пароль по желанию, и вы сможете напрямую войти в систему. ВФТ!

Успокойтесь и подумайте об этом, настоящий оператор SQL, который мы представили ранее, выглядит так:

SELECT * FROM user WHERE username='zoumiaojiang' AND psw='mypassword'

Странное имя пользователя злоумышленника может преобразовать вашу инструкцию SQL в следующую форму:

SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1 --' AND psw='xxxx'

В SQL,--— это значение содержимого после комментария, поэтому оператор запроса становится:

SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1

Условие запроса этого оператора SQL всегда истинно, поэтому это означает, что злоумышленник может войти в мою учетную запись без моего пароля, а затем может делать в ней все, что захочет, но это всего лишь самая простая инъекция, потрясающие эксперты по SQL-инъекциям. может даже запускать команды системного уровня хоста через SQL-запросы, чтобы сразу увидеть содержимое вашего хоста. У меня нет возможности слишком подробно объяснять эту способность. В конце концов, я не профессиональный исследователь этого типа атак , но с помощью приведенных выше примеров После понимания принципа SQL-инъекций мы в основном смогли найти решение для защиты от SQL-инъекций.

Как предотвратить SQL-инъекцию

Чтобы предотвратить SQL-инъекцию, основная причина заключается в том, что пользовательский ввод не может влиять на логику обычных операторов SQL.Когда уверенность пользователя в вводе будет использоваться для объединения операторов SQL, мы всегда должны выбирать не верить этому.Любое содержимое должно быть экранированы и отфильтрованы.Конечно, сделать этого недостаточно, вот некоторые меры предосторожности для предотвращения SQL-инъекций:

  • Строго ограничить права доступа к базе данных веб-приложения, предоставить этому пользователю минимальные привилегии, которые только могут удовлетворить его работу, тем самым минимизировать вред инъекционных атак на базу данных

  • Бэкэнд-код проверяет, что входные данные соответствуют ожиданиям., строго ограничивайте типы переменных, например, используйте регулярные выражения для некоторой обработки сопоставления.

  • Для специальных символов, поступающих в базу данных (',",\,<,>,&,*,;и т. д.) для экранирования или преобразования кодировки. В основном все языки бэкенда имеют методы для экранирования строк, такие как lodashlodash._escapehtmlcharбиблиотека.

  • Рекомендуется использовать параметризованный интерфейс запросов, предоставляемый базой данных, для всех операторов запросов., параметризованные операторы используют параметры вместо встраивания пользовательских входных переменных в оператор SQL, т. е. не объединяют оператор SQL напрямую. Например, библиотека mysqljs в Node.js.queryв методе?параметр-заполнитель.

mysql.query(`SELECT * FROM user WHERE username = ? AND psw = ?`, [username, psw]);

  • Перед выпуском приложения рекомендуется использовать профессиональный инструмент обнаружения SQL-инъекций., чтобы своевременно исправлять обнаруженные уязвимости SQL-инъекций. Для этого в Интернете есть много инструментов с открытым исходным кодом, таких как sqlmap, SQLninja и т. д.

  • Избегайте вывода веб-сайтом сообщений об ошибках SQL, такие как ошибки типов, несоответствия полей и т. д., для раскрытия инструкций SQL в коде, чтобы злоумышленники не могли использовать эту информацию об ошибках для внедрения SQL.

  • Не слишком детализируйте возвращаемое сообщение об ошибке, если цель состоит в том, чтобы облегчить отладку, используйте внутренний журнал и не выставляйте слишком много информации об ошибках в интерфейсе.В конце концов, реальных пользователей не волнует слишком много технических деталей, пока слова разумный.

При столкновении с кодом базы данных, которую нужно использовать, вы должны быть осторожны, будьте осторожны, чтобы сделать корабль на тысячи лет, найти еще несколько человек, чтобы просмотреть код несколько раз и выявить все проблемы, и вы должны быть хорошими при использовании инструментов, а код, связанный с работой с базой данных, является конфиденциальным.Все в порядке, не ходите на различные форумы, чтобы размещать операторы SQL вашего собственного сайта, что, если вы стали мишенью?

инъекция из командной строки

Уязвимость внедрения командной строки означает, что злоумышленник может напрямую проникнуть на хост через HTTP-запрос и выполнить команду оболочки, заданную злоумышленником.Во-первых, посмотрите на пример:

Если требование должно быть реализовано сейчас: пользователь отправляет некоторый контент на сервер, а затем выполняет некоторые системные команды на сервере, чтобы получить результат и вернуть его пользователю.Часть реализации интерфейса выглядит следующим образом:

// 以 Node.js 为例，假如在接口中需要从 github 下载用户指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* 用户输入的参数 */};
exec(`git clone ${params.repo} /some/path`);

Этот код действительно может удовлетворить потребности бизнеса, и обычные пользователи действительно могут загрузить желаемый код из указанного репозитория git, но, как и SQL-инъекция, этот код просто мил в глазах злоумышленников.

еслиparams.repoвходящийhttps://github.com/zoumiaojiang/zoumiaojiang.github.io.gitКонечно без проблем.
Но еслиparams.repoвходящийhttps://github.com/xx/xx.git && rm -rf /* &&Бывает, что ваш сервис запускается с root-правами.

Какие специфические злонамеренные злоумышленники могут сделать с впрыском командной строки, похожа на инъекцию SQL, а методы постоянно меняются, такие как «Инъекция отскока снаряда" и т. д., но принцип тот же, у нас определенно есть возможность предотвратить внедрение командной строки. Для предотвращения внедрения командной строки требуется несколько вещей:

  • Серверная часть должна полностью решить не верить контенту, представленному внешним интерфейсом, и наложить на него правила (например, регулярные выражения).
  • Выполнять экранирующую фильтрацию параметров командной строки для всех входящих параметров перед вызовом системных команд.
  • Не соединяйте операторы команд напрямую, используйте некоторые инструменты для объединения и обхода предварительной обработки, такие как Node.js.shell-escapeнпм-пакет.

Или предыдущий пример, мы можем сделать следующее:

const exec = require('mz/child_process').exec;
// 借助 shell-escape npm 包解决参数转义过滤问题
const shellescape = require('shell-escape');
let params = {/* 用户输入的参数 */};
// 先过滤一下参数，让参数符合预期
if (!/正确的表达式/.test(params.repo)) {
    return;
}
let cmd = shellescape([
    'git',
    'clone',
    params.repo,
    '/some/path'
]);
// cmd 的值: git clone 'https://github.com/xx/xx.git && rm -rf / &&' /some/path
// 这样就不会被注入成功了。
exec(cmd);

Независимо от языкового стандарта серверной части следует проявлять осторожность, когда речь идет о коде, вызывающем команды системной оболочки.

DDoS-атака

DDoS также называется Distributed Denial of Service, полное название Distributed Denial of Service.Его принцип заключается в использовании большого количества запросов, чтобы вызвать перегрузку ресурсов, что приводит к недоступности услуг.Эта атака не должна рассматриваться как проблема безопасности, но это следует рассматривать как альтернативное существование, потому что этот вид нападения Это в основном хулиганское существование, поведение «нанесение ран тысяче врагов и самоуничтожение восьмисот». С наступательной и оборонительной точки зрения защиты веб-приложений от атак давайте представим DDoS-атаки, которые, в конце концов, довольно распространены.

DDoS-атаку можно понимать так: «Вы открываете магазин, а соседний не выдерживает, поэтому вы нанимаете много бандитов, чтобы они сидели в вашем магазине, не тратили, а другие покупатели не могли зайти. , так что вы открыты для бизнеса. Почему вы говорите, что DDoS — это поведение «нанесения вреда тысяче врагов и самоуничтожения восьмисот»? В конце концов, магазин по соседству по-прежнему тратит много денег на наем преступного мира, но ничего не получает, верно? Цель DDoS-атаки в основном заключается в следующем:

  • Я так тебя ненавижу, я хочу тебя убить
  • Шантажировать вас, трахать вас, если вы не платите
  • Дурак, если ты не купишь мою услугу брандмауэра, найдутся "люди", которые продолжат тебя трахать

Возможно, ваш сайт подвергся DDoS-атаке, и это вопрос мнения о том, как интерпретировать конкретные причины. DDos-атаки можно разделить на атаки сетевого уровня и атаки прикладного уровня с точки зрения уровней, а также на атаки с быстрым трафиком и атаки с медленным трафиком с точки зрения методов атаки, но принцип заключается в том, чтобы вызвать перегрузку ресурсов и сделать службы недоступными.

DDoS-атаки сетевого уровня

DDoS-атаки сетевого уровня включаютSYN Flood,ACK Flood,UDP Flood,ICMP FloodЖдать.

SYN-флуд-атака

Атака SYN Flood в основном использует ошибку в процессе трехстороннего рукопожатия TCP.Все мы знаем, что процесс трехстороннего рукопожатия TCP заключается в отправке пакетов данных SYN, SYN + ACK, ACK обеим сторонам для установления соединения, и когда злоумышленник произвольно создает исходный IP-адрес для отправки SYN-пакета. Когда SYN + ACK, возвращенный сервером, не может быть ответом (поскольку IP-адрес создается произвольно), сервер попытается отправить повторно, и будет время ожидания не менее 30 секунд, что приводит к перенасыщению ресурсов и недоступным сервисам.Эта атака относится к медленной DDoS-атаке.

ACK-атака флудом

Атака ACK Flood заключается в том, что после установления TCP-соединения все TCP-пакеты передачи данных несут бит флага ACK. Когда хост получает пакет данных с битом флага ACK, ему необходимо проверить, что представляет собой пакет данных. существует, если он существует, проверьте, является ли состояние, представленное пакетом данных, допустимым, а затем передайте пакет данных на прикладной уровень. Если во время проверки будет обнаружено, что пакет данных является незаконным, например, порт назначения, на который указывает пакет данных, не открыт локально, стек протоколов хост-системы ответит на пакет RST, чтобы сообщить другой стороне, что порт не существует.

UDP-флуд-атака

Атака UDP Flood связана с тем, что UDP является протоколом без установления соединения, поэтому злоумышленники могут подделать большое количество исходных IP-адресов для отправки пакетов UDP.Этот тип атаки представляет собой атаку с большим трафиком. В нормальных условиях приложения двунаправленный трафик UDP-пакетов будет в основном одинаковым, поэтому злоумышленник, который инициирует эту атаку, потребляет свои собственные ресурсы при использовании ресурсов другой стороны.

ICMP-флуд-атака

Атака ICMP Flood — это атака с большим трафиком, принцип которой заключается в непрерывной отправке аномальных ICMP-пакетов (так называемая аномалия означает, что содержимое ICMP-пакета очень велико), что приводит к занятию целевой полосы пропускания, но ее также потребляются собственные ресурсы. В настоящее время многим серверам запрещено пинговать (брандмауэр может блокировать ICMP-пакеты), поэтому этот метод атаки устарел.

Защита от DDoS-атак на сетевом уровне

Суть DDoS-атак на сетевом уровне, от которых фактически невозможно защититься, что мы можем сделать, так это постоянно оптимизировать сетевую архитектуру самого сервиса и увеличивать пропускную способность сети. Конечно, выполнение следующих действий также поможет смягчить воздействие DDoS-атак на сетевом уровне:

  • Архитектура сети оптимизирована, а для разгрузки используется балансировка нагрузки.
  • Следите за тем, чтобы системные файлы сервера были последних версий и своевременно обновляйте системные патчи.
  • Добавьте анти-DDos устройство для очистки потока.
  • Ограничьте количество полусоединений SYN, открытых одновременно, и сократите время ожидания полусоединений SYN.
  • Ограничить частоту запросов одного IP.
  • Параметры защиты, такие как брандмауэры, запрещают пакеты ICMP и т. д.
  • Строго ограничьте исходящий доступ к серверам, открытым для внешнего мира.
  • Запустите портмаппер или сканер портов, чтобы тщательно проверить привилегированные и непривилегированные порты.
  • Отключите ненужные службы.
  • Внимательно проверьте журналы сетевых устройств и систем хост/сервер. Пока в логе есть дыра или меняется время, возможно, машина подверглась атаке.
  • Ограничьте обмен файлами с сетью за пределами брандмауэра. Это даст хакерам возможность перехватить системные файлы и предоставить хакерам информацию о хосте, что, несомненно, даст другой стороне возможность для вторжения.
  • Добавьте машину стека денег. .
  • Вызовите полицию. .

DDoS-атаки прикладного уровня

DDoS-атаки на уровне приложений происходят не на сетевом уровне, а после успешного установления связи TCP, когда приложение обрабатывает запрос.Многие распространенные DDoS-атаки являются атаками на уровне приложений. Атаки на прикладном уровне постоянно меняются, и их целью является использование вашей пропускной способности в сетевых приложениях.Ниже приведен список типичных типов атак.

CC-атака

В то время NSFOCUS разработала новое устройство под названием защита от DDoS-атак.Collapasarпродукты, которые могут эффективно защищать от атак SYN Flood. Для провокации хакеры разработалиChallenge CollapasarИнструмент атаки (сокращенно CC).

Принцип атаки CC состоит в том, чтобы постоянно инициировать аномальные запросы к страницам, которые потребляют много ресурсов, что приводит к исчерпанию ресурсов. Поэтому перед отправкой CC-атаки нам нужно найти страницы, которые загружаются медленно и потребляют больше ресурсов, например, страницы, которым необходимо запрашивать базу данных, читать и записывать файлы на жестком диске и т. д. С помощью атак CC сканеры используются для инициирования HTTP-запросов к определенным страницам, для загрузки которых требуется много ресурсов.

DNS Flood

Метод DNS-флуда заключается в отправке большого количества запросов на разрешение доменного имени на атакуемый сервер.Как правило, доменное имя, запрашиваемое для разрешения, генерируется случайным образом или доменное имя, которое не существует в онлайн-мире.Атакуемый DNS сервер получает запрос на разрешение доменного имени. В это время он сначала проверит, есть ли на сервере соответствующий кеш. Если он не может быть найден и доменное имя не может быть разрешено сервером напрямую, DNS-сервер рекурсивно запросит информацию о доменном имени со своего DNS-сервера верхнего уровня. Процесс разрешения доменного имени создает большую нагрузку на сервер, если количество запросов на разрешение доменного имени в секунду превышает определенное число, DNS-сервер отключится, когда доменное имя будет разрешено.

Согласно статистике Microsoft, верхний предел динамических запросов доменных имен, которые может выдержать DNS-сервер, составляет 9000 запросов в секунду. И мы знаем, что на ПК P3 можно легко построить десятки тысяч запросов на разрешение доменных имен в секунду, что достаточно, чтобы парализовать DNS-сервер с чрезвычайно высокой аппаратной конфигурацией, что показывает уязвимость DNS-сервера.

Атака медленного соединения HTTP

Для протокола HTTP сначала установите HTTP-соединение, установите большее Conetnt-Length и каждый раз отправляйте только несколько байтов, чтобы сервер всегда думал, что HTTP-заголовок не был передан, чтобы соединение появилось вскоре после этого. более одного соединения.

Защита от DDoS-атак на прикладном уровне

  • Определить поле User-Agent (ненадежно, потому что его можно создать по желанию)
  • Для IP+cookie ограничить частоту доступа (т.к. cookie можно изменить, IP может использовать прокси, или бройлер, тоже не надежно)
  • Закройте максимальное количество подключений к серверу и т. д. и разумно настройте промежуточное ПО для смягчения DDoS-атак.
  • Добавьте в запрос код подтверждения, например, если в запросе есть операция с базой данных.
  • При написании кода старайтесь оптимизировать и разумно использовать технологию кэширования, чтобы уменьшить количество операций чтения базы данных.
  • Добавьте машину стека денег. .
  • Вызовите полицию. .

Защита прикладного уровня иногда сложнее, чем защита сетевого уровня, потому что есть много факторов, которые вызывают DDoS-атаки на прикладной уровень. ресурсов, а иногда и из-за неправильной настройки промежуточного ПО и т. д. Суть защиты от DDoS-атак на уровне приложений состоит в том, чтобы различать людей и машины (краулеры), потому что большое количество запросов не может быть искусственным, а должно создаваться машинами. Следовательно, если поведение людей и рептилий можно эффективно отличить, от этой атаки можно будет хорошо защититься.

Другие DDoS-атаки

Инициирование DDoS также требует много ресурсов полосы пропускания, но Интернет подобен лесу, в лесу есть все виды птиц, DDoS-атаки могут найти и другие способы запуска дешевых и смертельных DDoS-атак.

Использование XSS

Например, если на странице 12306 обнаружена постоянная XSS-уязвимость, обнаруженная злоумышленниками, необходимо только выполнить скрипт в этой уязвимости во время пика билетов на Весенний фестиваль, чтобы сделать какой-либо запрос к небольшому сайту, а затем следить за посещением пользователя. По мере увеличения числа зараженных пользователей атакованный сайт, естественно, будет быстро парализован. Такого рода DDoS просто никуда не годится, не удивляйтесь, сейчас XSS-уязвимостей на большой станции не так уж и много.

От сетевой атаки P2P

Все мы знаем, что пользователей P2P и трафика в Интернете огромное количество. Если все они отправляются в назначенное место для загрузки данных и к ним подключены тысячи реальных IP-адресов, ни одно устройство не сможет их поддерживать. Возьмем, к примеру, BT-загрузку: создание торрентов с некоторыми популярными видео и размещение их в поисковых системах достаточно, чтобы обмануть многих пользователей и трафик, но это только базовая атака.
Расширенная атака P2P заключается в прямом обмане сервера управления ресурсами. Например, клиент Thunder загрузит найденные ресурсы на сервер управления ресурсами, а затем отправит их другим пользователям, которым необходимо загрузить те же ресурсы, таким образом будет опубликована ссылка. Путем реверсирования протокола злоумышленники подделывают большое количество информации о популярных ресурсах и распространяют ее через центр управления ресурсами, что может быть распространено по всей сети. P2P-сеть. Что еще более ужасно, так это то, что такую ​​атаку невозможно остановить, даже сам злоумышленник не может остановить, атака продолжается до тех пор, пока официальный представитель P2P не обнаружит проблему для обновления сервера, а пользователь загрузки не перезапустит загруженное программное обеспечение.

Подводя итог, предотвратить DDoS невозможно, так же, как ваш магазин может вместить только 50 человек, а в триаде 100 человек, вы можете измениться на большой магазин, который может вместить 500 человек, а затем триада найдет еще 1000 человек. Способ нагромождения людей - суть наступательного и оборонительного способа DDoS. , если не сработает - звоните в полицию.

Угон трафика

Угон трафика следует рассматривать как основную экономическую опору черной индустрии, верно? Это просто омерзительно, не будем жаловаться, продолжим разговор о галантерейных товарах.В основном есть два вида угона трафика:DNS 劫持а такжеHTTP 劫持, цель та же, то есть когда пользователь получает доступzoumiaojiang.com, показывая вам не или не совсемzoumiaojiang.comкоторый предоставил "содержание".

перехват DNS

Перехват DNS, также известный как перехват доменного имени, можно понять так:Вы взяли такси и хотели поехать в торговый центр, чтобы поесть, но такси, которое вы взяли, было отправлено небольшой мастерской, и оно было доставлено прямо в маленькую мастерскую для вас.», роль DNS заключается в сопоставлении доменного имени сетевого адреса с IP-адресом, который может распознать реальный компьютер, чтобы компьютер мог в дальнейшем взаимодействовать, передавать адрес веб-сайта и контент и т. д. Если, когда пользователь получает доступ к сайту через определенное доменное имя, поддельный DNS-сервер возвращает IP-адрес вредоносного фишингового сайта, пользователь перехватывается на вредоносный фишинговый сайт, а затем его фишингуют для ввода различной информации об учетной записи и пароле. Утечка конфиденциальности.

dns劫持

Этот вид захвата является либо призраком сетевого оператора. Как правило, небольшой сетевой оператор вступает в сговор с черной индустрией для захвата DNS, либо компьютер отравлен, а конфигурация DNS маршрутизатора была злонамеренно изменена. веб-мастерам трудно обнаружить, если нет отзывов пользователей, обновленная версия перехвата DNS может также использовать портреты пользователей для конкретных пользователей, определенных регионов и т. д. для фильтрации методов перехвата пользователей.Кроме того, такие рекламные объявления отображаются более случайным образом и меньше. Как правило, веб-мастерам трудно обнаружить, если пользователи не жалуются, и даже если они обнаруживают доказательства, об этом еще труднее сообщить. В любом случае, если вы получите отзыв о перехвате DNS, обязательно сделайте следующее:

  • Экспертиза очень важна, время, местоположение, IP, коммутируемая учетная запись, снимок экрана, URL-адрес и т. д. должны быть доступны.
  • Вы можете подавать жалобы и отзывы операторам связи в захваченном районе.
  • Если отзыв о жалобе недействителен, обратитесь напрямую в Министерство промышленности и информационных технологий, чтобы подать жалобу.Вообще говоря, ваше доменное имя будет забелено.

HTTP-перехват

Вы можете понять перехват HTTP следующим образом:Вы взяли такси и хотели поужинать в торговом центре, но по дороге водитель вручил вам рекламу небольшой мастерской.», перехват HTTP в основном означает, что когда пользователь посещает сайт, он проходит через сеть оператора, и незаконный оператор и черная индустрия могут вступить в сговор для перехвата возвращаемого содержимого HTTP-запроса, а также могут подделать содержимое и затем вернуть его пользователю, тем самым захватывая страницу. , начиная от вставки небольших рекламных объявлений или прямого вмешательства в фишинговые страницы веб-сайта, чтобы обмануть конфиденциальность пользователей. Фундаментальная причина перехвата трафика заключается в том, что протокол HTTP не имеет возможности проверить личность взаимодействующей стороны и проверить целостность данных. Если эту проблему удастся решить, перехват трафика будет непростым делом. так предотвратить Единственный метод перехвата HTTP — это шифрование содержимого, чтобы угонщик не мог взломать и подделать его, чтобы можно было предотвратить перехват HTTP.

Протокол HTTPS — это безопасный зашифрованный сетевой протокол прикладного уровня, основанный на протоколе SSL, который может предотвратить перехват HTTP. Вот статьястатьяХорошо сказано. HTTPS здесь подробно не обсуждается, я расскажу о HTTPS отдельно, когда у меня будет возможность позже. Если вы не хотите, чтобы ваш сайт был взломан HTTP, быстро конвертируйте свой сайт в HTTPS.

Уязвимость сервера

В дополнение к известным уязвимостям и печально известным атакам, упомянутым выше, на самом деле в сервере есть много других уязвимостей, которые часто легко упустить из виду.В этом разделе кратко представлены некоторые из них.

Уязвимость при несанкционированных операциях

Если ваша система имеет контроль над входом в систему, вы должны быть особенно осторожны, потому что очень вероятно, что ваша система имеет уязвимость для несанкционированных операций.Уязвимость для несанкционированных операций можно просто резюмировать как "Пользователь А может просматривать или управлять личным контентом пользователя Б.», если у вас все еще есть контроль разрешений в вашей системе, вам нужно быть более осторожным. Таким образом, каждый запрос должен выполнять оценку идентификатора пользователя.

Ниже приведен фрагмент кода уязвимой серверной схемы:

// ctx 为请求的 context 上下文
let msgId = ctx.params.msgId;
mysql.query(
    'SELECT * FROM msg_table WHERE msg_id = ?',
    [msgId]
);

Приведенный выше код заключается в том, что любой может запросить информацию любого пользователя, пока есть msg_id, это типичная несанкционированная уязвимость, и ее необходимо улучшить следующим образом:

// ctx 为请求的 context 上下文
let msgId = ctx.params.msgId;
let userId = ctx.session.userId; // 从会话中取出当前登陆的 userId
mysql.query(
    'SELECT * FROM msg_table WHERE msg_id = ? AND user_id = ?',
    [msgId, userId]
);

Ну, это, вероятно, что это означает.Если есть более строгий контроль разрешений, каждая операция, связанная с базой данных, должна быть строго проверена в первую очередь, а также связь учетной записи userId и ассоциации Permission.

Уязвимость обхода каталога

Уязвимость обхода каталога определяется созданием URL-адреса или параметра../,./И аналогичная кодировка ASCII, кодировка Unicode строк в родительских каталогах, полные переходы к каталогам, чтение конфиденциальных файлов в различных каталогах операционной системы, также известные как «уязвимости произвольного чтения файлов».

Принцип уязвимости обхода каталога: программа недостаточно фильтрует пользовательский ввод../Например, символы перехода в каталог, чтобы пользователи могли перемещаться по любому файлу на сервере, отправляя переход в каталог. использовать несколько..символ, продолжайте прыгать вверх и, наконец, оставайтесь у корня/, чтобы прочитать любой файл по абсолютному пути.

Существует несколько примеров и тестов для уязвимостей обхода каталогов.Как правило, URL-адреса создаются, а затем доступны непосредственно через браузер или обнаруживаются с помощью инструментов сканирования веб-уязвимостей, и, конечно же, вы также можете написать программы для тестирования.

http://somehost.com/../../../../../../../../../etc/passwd
http://somehost.com/some/path?file=../../Windows/system.ini
# 借助 %00 空字符截断是一个比较经典的攻击手法
http://somehost.com/some/path?file=../../Windows/system.ini%00.js
# 使用了 IIS 的脚本目录来移动目录并执行指令
http://somehost.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c:\

защитаМетод заключается в том, что вам нужно выполнить URL или параметр../,./Избегайте фильтрации других символов.

утечки физического пути

Утечка физического пути является дефектом с низким уровнем риска, и его вред обычно описывается как «злоумышленники могут использовать эту уязвимость для получения информации для дальнейшей атаки на систему», что обычно вызвано сообщением системы об ошибке 500 и возвратом непосредственно на страницу. для наглядности. Получение физического пути иногда может принести злоумышленнику некоторую полезную информацию, например: вы можете примерно понять структуру файловых каталогов системы; вы можете увидеть стороннее программное обеспечение, используемое системой; возможно, вы получите легитимное имя пользователя (Поскольку многие люди используют свое имя пользователя в качестве имени каталога веб-сайта).

Способ предотвратить подобную утечку — хорошо поработать над обработкой ошибок бэкэнд-программы и настроить специальную страницу ошибки 500.

Уязвимость к исходному коду

Подобно раскрытию физического пути, злоумышленник может напрямую получить внутренний исходный код вашего сайта с помощью запроса, а затем продолжить изучение атаки на систему. Так что же заставляет исходный код быть открытым? В основном это происходит в конфигурации сервера.Сервер может указать, к каким файлам пути можно получить прямой доступ.Вот пример службы koa.Обычный koa сервер может указать каталог статических ресурсов через koa-static middleware., так что к статическим ресурсам можно получить доступ через маршрут маршрута. Например, каталог исходного кода вашей системы выглядит так:

|- project
    |- src
    |- static
    |- ...
|- server.js

Вы хотите настроить статическую папку как каталог статических ресурсов, вы должны находиться вserver.jsВыполните следующую настройку:

const Koa = require('koa');
const serve = require('koa-static');
const app = new Koa();
app.use(serve(__dirname + '/project/static'));

Однако, если каталог статических ресурсов настроен неправильно, может возникнуть большая проблема, например:

// ...
app.use(serve(__dirname + '/project'));

Таким образом, ко всем исходным кодам можно получить доступ через маршрутизацию, а все серверы предоставляют механизм статических ресурсов, поэтому при настройке каталогов статических ресурсов и путей через сервер необходимо уделять внимание проверке, иначе могут быть лазейки.

Наконец, я надеюсь, что веб-разработчики смогут управлять конфиденциальностью своего кода и обращать внимание на вопросы безопасности кода, например, не размещать код продукта, содержащий конфиденциальную информацию, на стороннем внешнем сайте или предоставлять его внешним пользователям, особенно фронтальным. конец кода, закрытый ключ аналогичен Конфиденциальные вещи не должны быть напрямую выведены в код или на страницу. Может быть много моментов, на которые стоит обратить внимание, но в конечном счете для каждой строки кода по-прежнему необходимо тщательно проверять строку безопасности.

вызов. . . Я так устала.Я пишу от случая к случаю уже несколько дней.Если будут какие-то упущения или недочеты, я продолжу добавлять их позже~

Эта статья является оригинальной статьей, и точки знаний будут часто обновляться, а некоторые ошибки будут исправлены.Поэтому, пожалуйста, сохраняйте первоисточник для перепечатки, что удобно для отслеживания источника, избежания введения в заблуждение устаревшими неправильными знаниями и наличия лучший опыт чтения.
При воспроизведении указать источник:Перейти Miaojiang.com/article/com…
Категории