В запросе текст технической направленности из области разработки и тестирования программного обеспечения. Основной язык текста запроса — китайский язык.

Перевод:

В эпоху интернета с добавлением CDN, расширение защиты сетевого уровня становится необходимым. Статистика IP будет находиться в HTTP-заголовке, частота использования, количество и чёрный список будут обрабатываться по-прежнему.

Однако многие производители оборудования для очистки трафика имеют фиксированные поля для получения реального IP пользователя из HTTP-заголовка (X-FOR-F), которые нельзя настроить. Некоторые производители даже не имеют этой функции. Здесь мы не будем упоминать конкретные названия этих производителей. PS: На традиционном 4-уровневом уровне защиты проблем нет.

Применение:

Проверка тегов, установка файлов cookie, перенаправление URL, перенаправление через JS, проверка кода, вложение страниц, принудительное использование статического кэша и т. д. Защита должна быть адаптирована к точкам атаки. Например, если атака направлена на вложенный URL, мы не можем использовать перенаправления через JS или 302 кода проверки и другие методы; в реальных условиях многоуровневой защиты от CC, такие меры защиты уже неэффективны. Позже я поделюсь своим алгоритмом защиты и уже могу реализовать его в OpenStar.

Браузер может выполнять JS и Flash. Здесь я делюсь некоторыми методами защиты на основе JS. Для Flash требуется самостоятельная разработка (сложнее, чем JS), что позволяет обеспечить безопасность на уровне приложений и защиту от захвата страниц (пораскиньте мозгами).

1. Защита на стороне клиента: Использование JS для защиты переднего плана (распознавание браузера, определение траектории мыши, добавление хвоста к URL (аргументы), случайная задержка, получение событий мыши и клавиатуры и т.д.). Здесь очень сложно, например, браузер распознаёт IE, поддерживающий !-[1,] этот специальный JS, некоторые диалекты JS, некоторые браузеры имеют пользовательские теги и т. д.;

2. Защита на стороне сервера: Хвост, добавляемый к URL через аргументы, является динамически генерируемым токеном на сервере, а не статическим регулярным выражением для проверки его законности.

3. Специфические атаки: Этот тип атак можно быстро сопоставить по характеристикам (медленные атаки, HTTP-атака заголовка PHP5.3).

Простой сценарий:

1. Прямой доступ к URL пользователя (это лучше всего защищено):

Первый этап:

• Сетевой уровень: ограничение частоты доступа, превышение порога только для чёрного списка в течение определённого времени.
• Уровень приложения: перенаправление через JS, код проверки, стратегия Flash (перетаскивание распознавания и т. д.).

2. Вложенный URL (проверка AJAX, изображение кода подтверждения):

Первый этап:

• Сетевой уровень: ограничение частоты доступа, превышение порога только для чёрного списка в течение определённого времени.
• Уровень приложения: загрузка страницы атакованного URL, переписывание страницы и использование JS для управления ссылками на атакованный URL. JS случайным образом добавляет проверку строки в конце URL, и сервер проверяет её с помощью статического регулярного выражения.

Второй этап:

• Сетевое и прикладное уровни: IP пользователя находится в HTTP-заголовке. Необходимо извлечь IP из HTTP-заголовка для ограничения частоты. (На самом деле, после хорошей реализации этого уровня защиты, вам редко приходится переходить на третий уровень защиты приложения.)
• Уровень приложения: проверка строки использует токены, сгенерированные сервером, для строгой проверки токенов.

Третий этап:

• Уровень приложения: увеличение распознавания браузера (различные агенты соответствуют различным JS-диалектам), случайная задержка JS, подтверждение траектории мыши, подтверждение клавиатуры и мыши и другие проверки JS, а затем генерация строки проверки.

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

Защита на уровне приложения используется, когда защита на сетевом уровне и расширенном сетевом уровне неэффективна. Обычно она используется нечасто, потому что в защите OpenStar она редко требуется на третьем этапе. При защите от захвата страниц воображение полезно (JS — хороший помощник). Использование OpenStar может помочь вам быстро реализовать это; конечно, защита с использованием Flash лучше (недостаточно гибкая).