Php защита от обхода

Как защититься от атак с использованием межсайтовой подделки запроса (CSRF) в php

wikiHow работает по принципу вики, а это значит, что многие наши статьи написаны несколькими авторами. При создании этой статьи над ее редактированием и улучшением работали авторы-волонтеры.

Количество просмотров этой статьи: 9062.

Атака с использованием межсайтовой подделки запроса (CSRF) – это тип уязвимости веб-приложения, когда жертва непреднамеренно запускает скрипт в своем браузере, который использует текущую сессию авторизованного пользователя в определенном сайте. Атаки CSRF могут производиться через GET или POST запросы. Данная статья покажет вам, как защитить свое веб-приложение от атак CSRF.

Мы будем использовать два метода для защиты от CSRF атак ваших GET и POST запросов.

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

Второй метод – это использование случайных названий для каждого поля формы. Значение случайного имени для каждого поля хранится в сессионной переменной и после того, как форма отправлена (произошел сабмит), система генерирует новые случайные названия полей. То есть, если злоумышленник захочет произвести атаку, ему нужно будет знать эти случайные названия полей формы.

К примеру, запрос, который раньше выглядел вот так:

Источник

Парсим сайты с защитой от ботов

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

Речь не идет о каком-либо виде «взлома» или о создании повышенной нагрузки на сайт. Мы будем автоматизировать то, что и так можно сделать вручную. Если говорить конкретно о нас, то мы собираем характеристики товаров.

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

Как работает защита от автоматических запросов?

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

Давайте попробуем классифицировать способы, которые используют сайты, чтобы отфильтровать автоматические запросы.

1. Самописные решения.

1. Готовые модули для веб-cервера. По запросу “nginx bots protection module” находится много разных решений, и платных, и бесплатных, и открытых.

1. Сторонний сервис, специализирующийся на фильтрации автоматического трафика.

Для начала, давайте разберемся, что о нас известно серверу на той стороне, вне зависимости от того, каким из способов реализована проверка.

IP-адрес. По нему можно определить страну, город, провайдера. В большинстве случаев, по нему нельзя определить конкретное устройство или конкретного абонента, потому что абоненты находятся за NAT.

Заголовки HTTP. По ним можно определить браузер, используемый язык интерфейса, и некоторые другие параметры. В них же передаются Cookies, с их помощью которых можно сопоставить запросы из одного браузера. Так же с их помощью можно определить, выполняется ли на клиенте код на JavaScript.

Особенности реализации TCP, TLS и HTTP/2. Суть в том, что HTTP — это прикладной, самый последний уровень модели OSI, а на уровнях ниже используются протоколы, реализация которых в разных программах может иметь особенности.

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

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

Я установил Microsoft Network Monitor и посмотрел, как выглядят запросы из разных инструментов в виде кадров канального уровня. Примерно так:

Кадр из Microsoft Network Monitor

 Frame: Number = 306, Captured Frame Length = 277, MediaType = WiFi - WiFi: [Unencrypted Data] .T. (I) - MetaData: Version: 2 (0x2) Length: 32 (0x20) - OpMode: Extensible Station Mode StationMode: (. 0) Not Station Mode APMode: (. 0.) Not AP Mode ExtensibleStationMode: (. 1..) Extensible Station Mode Unused: (.0000000000000000000000000000. ) MonitorMode: (0. ) Not Monitor Mode Flags: 4294967295 (0xFFFFFFFF) RemData: Outbound TimeStamp: 01/14/2023, 14:02:35.627425 UTC - FrameControl: Version 0,Data, Data, .T. (0x108) Version: (. 00) 0 Type: (. 10..) Data SubType: (. 0000. ) Data DS: (. 01. ) STA to DS via AP MoreFrag: (. 0. ) No Retry: (. 0. ) No PowerMgt: (. 0. ) Active Mode MoreData: (..0. ) No ProtectedFrame: (.0. ) No Order: (0. ) Unordered Duration: 32768 (0x8000) BSSID: 2C9D1E DC642C SA: E470B8 CF3A50 DA: 2C9D1E DC641F - SequenceControl: Sequence Number = 0 FragmentNumber: (. 0000) 0 SequenceNumber: (000000000000. ) 0 - LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol) - DSAP: SNAP(Sub-Network Access Protocol), Individual DSAP Address: (1010101.) SNAP(Sub-Network Access Protocol) IG: (. 0) Individual Address - SSAP: SNAP(Sub-Network Access Protocol), Command Address: (1010101.) SNAP(Sub-Network Access Protocol) CR: (. 0) Command Frame - Unnumbered: UI - Unnumbered Information MMM: (000. ) 0 PF: (. 0. ) Poll Bit - No Response Solicited MM: (. 00..) Type: (. 11) Unnumbered(U) Frame - Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION OrganizationCode: XEROX CORPORATION, 0(0x0000) EtherType: Internet IP (IPv4), 2048(0x0800) - Ipv4: Src = 192.168.100.24, Dest = 49.12.20.235, Next Protocol = TCP, Packet Total IP Length = 213 - Versions: IPv4, Internet Protocol; Header Length = 20 Version: (0100. ) IPv4, Internet Protocol HeaderLength: (. 0101) 20 bytes (0x5) - DifferentiatedServicesField: DSCP: 0, ECN: 0 DSCP: (000000..) Differentiated services codepoint 0 ECT: (. 0.) ECN-Capable Transport not set CE: (. 0) ECN-CE not set TotalLength: 213 (0xD5) Identification: 3626 (0xE2A) - FragmentFlags: 16384 (0x4000) Reserved: (0. ) DF: (.1. ) Do not fragment MF: (..0. ) This is the last fragment Offset: (. 0000000000000) 0 TimeToLive: 128 (0x80) NextProtocol: TCP, 6(0x6) Checksum: 33089 (0x8141) SourceAddress: 192.168.100.24 DestinationAddress: 49.12.20.235 - Tcp: Flags=. AP. SrcPort=51677, DstPort=HTTPS(443), PayloadLen=173, Seq=3595707432 - 3595707605, Ack=850844191, Win=512 (scale factor 0x8) = 131072 SrcPort: 51677 DstPort: HTTPS(443) SequenceNumber: 3595707432 (0xD6522428) AcknowledgementNumber: 850844191 (0x32B6DA1F) - DataOffset: 80 (0x50) DataOffset: (0101. ) 20 bytes Reserved: (. 000.) NS: (. 0) Nonce Sum not significant - Flags: . AP. CWR: (0. ) CWR not significant ECE: (.0. ) ECN-Echo not significant Urgent: (..0. ) Not Urgent Data Ack: (. 1. ) Acknowledgement field significant Push: (. 1. ) Push Function Reset: (. 0..) No Reset Syn: (. 0.) Not Synchronize sequence numbers Fin: (. 0) Not End of data Window: 512 (scale factor 0x8) = 131072 Checksum: 0xF528, Disregarded UrgentPointer: 0 (0x0) TCPPayload: SourcePort = 51677, DestinationPort = 443 TLSSSLData: Transport Layer Security (TLS) Payload Data - TLS: TLS Rec Layer-1 HandShake: Encrypted Handshake Message. - TlsRecordLayer: TLS Rec Layer-1 HandShake: ContentType: HandShake: - Version: TLS 1.2 Major: 3 (0x3) Minor: 3 (0x3) Length: 168 (0xA8) - SSLHandshake: SSL HandShake EncryptedHandshakeMessage: Binary Large Object (168 Bytes)

Канальный уровень нас не интересует, данные о нем до удаленного сервера не дойдут. Нас интересуют инкапсулированные в кадре канального уровня пакеты сетевого уровеня и уровни выше.

Первое интересное наблюдение: IP-пакет содержит параметр TTL. Начальное значение этого параметра для TCP протокола отличается в разных операционных системах. Мне удалось найти такие значения для современных версий:

Источник