Атаки на веб-приложения через систему управления сессиями. Еще одним уязвимым местом являются веб-приложения. Конечно, разработка корпоративных веб-порталов обычно поручается профессионалам - веб-программистам, но системный администратор и тем более специалист по ИБ должны иметь представление о существующих уязвимостях в веб-при ложениях. Кроме того, в небольших компаниях сисадмин зачастую занимается разработкой и поддержкой корпоративного портала. Так что приведенная далее информация будет полезна многим. Современные веб-порталы используют в качестве веб-сервера преимущественно Apache. Существует, конечно, IIS (Internet Information Services), работающий под Windows, но большинство хостингов все равно используют связку FreeBSD/Linux+Apache. Для хранения данных, с которыми работает веб-портал, обычно используется MySQL или PostgreeSQL. В высоконагруженных промышленных системах может применяться Oracle. В качестве языка сценариев обычно используется PHP или Perl. Существуют также высокоуровневые средства разработки портальных решений от Microsoft, но в данном разделе мы не будем их касаться в силу меньшей их распространенности, по сравнению с бесплатными FreeBSD, Apache, MySQL, PHP. В качестве практического примера рассмотрим атаки на PHP-приложение через систему управления сессиями. Основными причинами возможности данных атак являются отсутствие проверки идентификатора сессии пользователя и отсутствие проверки данных, хранящихся в сессии. Рассмотрим возможные варианты атак на приложение. Кража сессии (Session Hijacking). Суть атаки заключается в использовании злоумышленником идентификатора сессии, принадлежащего легальному пользователю, для выдачи себя за владельца сессии. Узнать идентификатор чужой сессии можно с помощью перехвата трафика легального пользователя, организации XSS-атаки или посредством перебора. Общий алгоритм осуществления атаки следующий: 1) атакующий собирает информацию об IP-адресах жертвы и том ресурсе, доступ к которому необходимо получить; 2) затем необходимо дождаться, когда атакуемый подключится к целевому ресурсу; 3) далее злоумышленнику нужно запустить ARP relay; 4) когда жертва подключилась к целевому ресурсу и начала работу с ним, атакующий увидит в сниффере новое активное соединение. Далее взломщик производит атаку десинхронизацией TCP/IP, которая уже описывалась ранее. Соединение жертвы «отваливается» с помощью принудительной отправки RST-пакета; 5) далее злоумышленник может работать от имени жертвы и с ее учетными Правами; 6) атакуемый вынужден заново переподключиться к целевому ресурсу, справедливо полагая, что произошел аппаратный сбой соединения. Злоумышленник отправляет ему RST; 7) когда хакер закончит работу с системой, он прекращает посылать RST и отключает ARP-relay; 8) взломанный пользователь снова может работать с системой. Как нетрудно понять из описания, для реализации такой атаки необходимо быть подключенным к одному коммутатору, что и атакуемый. То есть фактически находиться в одной локальной сети с жертвой. В более простом случае злоумышленник может попробовать взломать чужую сессию с помощью подмены cookies. Вот небольшой пример подобной атаки на практике. Для ее реализации необходимы сниффер, например Wireshark, браузер (например, Firefox) и редактор Cookies (можно использовать add-on к Firefox). Атакуемый пользователь осуществляет подключение к порталу социальной сети. Взломщик производит сниффинг трафика. По окончании перехвата трафика злоумышленнику необходимо найти переданные пользователем cookies. Сделать это в Wireshark можно следующим образом. Нажать Ctrl+F или Edit - Find Packet. В поле By: необходимо выбрать String и Search In, опцию Packet details, в текстовом поле нужно указать Set-Cookie. Когда нужный пакет будет найден, необходимо нажать правую кнопку мыши и выбрать «Follow TCP Stream». Далее в этом потоке можно обнаружить пакет, аналогичный приведенному. Это и есть необходимый cookie. Далее нужно открыть редактор Cookie Editor (Tools - Cookie Editor). Потом нажать Add и указать следующее: Name: _twitter_sess Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture) Domain: . twitter.com Path: / В случае успешной реализации теперь для входа на сайт злоумышленнику не требуется указывать учетные данные, достаточно просто зайти на страницу. Кратко выполняются следующие действия: 1) перехват трафика; 2) обнаружение пакета, содержащего Set-Cookie; 3) установка Cookie в редакторе Cookie Editor add-on; 4) обращение к нужному сайту. Фиксация сессии (Session Fixation). Для осуществления этой атаки злоумышленнику не нужен идентификатор чужой сессии, достаточно установить идентификатор своей сессии легальному пользователю, прошедшему авторизацию. Как и в предыдущем случае, создается ситуация, когда злоумышленник и легальный пользователь имеют один и тот же идентификатор сессии. Фиксация сессии (Session Fixation) представляет собой метод нападения, который принудительно устанавливает идентификатор сессии в определенное значение. В зависимости от функциональности атакуемого сайта, чтобы «зафиксировать» идентификатор сессии, может быть применено множество различных методов. Затем идентификатор пользовательской сессии фиксируется, и злоумышленник ожидает тех, кто будет входить в систему. Как только пользователь сделает это, злоумышленник использует предопределенное значение идентификатора сессии, чтобы получить его онлайн-идентификацию со всеми вытекающими последствиями. Существует два типа систем управления сессиями: «свободные» и «строгие». Тип сессии определяется в зависимости от того, как формируются значения идентификаторов. Первый тип систем позволяет веб-браузерам указывать любой идентификатор. Второй тип систем принимает только значения, сформированные на сервере. В свободных системах произвольный идентификаторсессии обрабатывается вообще без обращения к веб-сайту. Строгие системы требуют от злоумышленника обслуживания «сессии-ловушки» с периодическим обращением к веб-сайту для предотвращения тайм-аутов по неактивности. Без активной защиты от фиксации сессии атака может быть предпринята против любого веб-сайта, использующего сессии для идентификации подлинности пользователей. Веб-сайты, использующие идентификаторы сессий, обычно применяют Cookie, также применяются URL и скрытые поля форм. К сожалению, сессии, основанные на Cookie, проще для нападений. В отличие от похищения идентификаторов сессий пользователей, выполняемых после их входа на веб-сайт, фиксация сессии предоставляет значительно более широкие возможности для нападения. Активная часть нападения делается до входа пользователей в систему. Рассмотрим пример классической фиксации пользовательской сессии. Существуют три этапа фиксации: 1) установка; 2) фиксация; 3) вхождение. На первом этапе злоумышленник устанавливает «сессию-ловушку» на атакуемый сайт и получает этот идентификатор сессии. Или злоумышленник для нападения может выбрать случайный идентификатор сессии. Но в этом случае значение, установленное сессией-ловушкой, должно поддерживаться (чтобы «быть живым») с повторными соединениями с веб-сайтом. Затем на следующем этапе злоумышленник помещает значение сессии-ловушки в браузер пользователя и фиксирует идентификатор пользовательской сессии. И на третьем этапе злоумышленник ожидает, пока пользователь не войдет в систему атакуемого сайта. Как только пользователь делает это, значение фиксированного идентификатора сессии будет использовано, и злоумышленник может начать работу со взломанной системой. Для фиксации идентификатора пользовательской сессии может быть выполнен один из следующих методов: выдача cookie с использованием клиентского скрипта; выдача нового значения идентификатора сессии в cookie с использованием клиентского скрипта. Межсайтовое программирование в слабых местах системы защиты веб-сайта может быть использовано для изменения текущего значения cookie. http://example/<script>document.cookie="sessionid=1234;%20domain=.example.сom";</script>.idc Вот пример выдачи cookie с использованием МЕТА-тега. Этот метод эффективен, особенно когда блокиратор межсайтового программирования предотвращает инъекцию тегов HTML-скриптов, но не META-тегов. http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.сom">.idc Выдача cookie c использованием HTTP-заголовка ответа. Злоумышленник вызывает или на целевом веб-сайте, или на любом из его поддоменов выдачу cookie с идентификатором сессии. Это может быть выполнено разными путями: взлом веб-сервера в домене (например, плохо поддерживаемый сервер); заражение пользовательского DNS-сервера, практически с добавлением веб-сервера злоумышленника в атакуемый домен (этот тип атак уже описывался чуть в постах, посвященном DNS); установка злонамеренного веб-сервера в атакуемый домен (например, на рабочей станции в Windows2000 домен, все рабочие станции также находятся в DNS-домене); использование атаки разбиение HTTP-ответа. Здесь также стоит отметить, что длительная атака фиксации сессии может быть выполнена выдачей постоянных cookies (например, со временем жизни 10 лет), которые будут держать фиксацию сессии даже после перезагрузки пользователем компьютера. Вот пример: http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc Отравление сессии (Session Poisoning). Угроза отравленной сессии возникает, если злоумышленник имеет возможность установить свой PHP-сценарий на сервере, где исполняется атакуемое приложение. Суть атаки заключается в том, что если PHP-приложения исполняются на одном сервере, то велика вероятность того, что, зная идентификатор сессии, злоумышленник сможет работать с данными сессии, созданной в атакуемом приложении. Отравление возможно, если атакуемое приложение имеет ошибку, позволяющую выполнять произвольный код, и если веб-приложение работает на сервере вместе с приложениями других пользователей хостинга. Цель данной атаки - получение доступа к значениям сессии с возможностью чтения/записи. В случае успеха злоумышленник сможет читать и/или фальсифицировать любое значение, хранящееся в сессии. Отравления используют для получения персональных данных других пользователей, а также для модификации собственной сессии, для выдачи себя за другого и/или повышения привилегий. Вот простейший пример данной атаки: $var = $_GET["something"]; $_SESSION["$var"] = $var2; Аутентификация с помощью форм. Когда клиент заходит на страницу и вводит логин и пароль, его учетные данные передаются на сервер. В случае если аутентификация успешно пройдена, сервер формирует сессионный билет для данного пользователя и при всех последующих обращениях к серверу используется уже этот билет, данные которого сохраняются в cookie. По умолчанию время жизни билета составляет 30 минут. По окончании этого времени билет может быть автоматически продлен. В случае если в течение определенного интервала времени обращений больше не было, сервер отправляет клиенту сообщение с предложением «забыть» этот билет, в результате чего браузер удаляет данный cookie, и пользователю надо заново вводить учетные данные, чтобы войти в систему. Казалось бы, все вполне логично и правильно. Но клиент (а точнее, злоумышленник) может периодически просить сервер продлевать свой билет, по сути неограниченное число раз. То есть сервер никак не контролирует, какое количество раз продлевался билет. И злоумышленник может просто игнорировать полученное от сервера предложение «забыть» свой билет и продолжать продлевать его и дальше. Таким образом, если злоумышленник смог похитить cookie с билетом, он сможет использовать пользовательскую сессию. Cross Site Request Forgery. Старый добрый CSRF актуален и для .NET. Напомним, что CSRF - это вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от ее лица тайно отправляется запрос на другой сервер (например, на сервер платежной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счет злоумышленника). Для осуществления этой атаки должно быть выполнено несколько условий. Во-первых, жертва должна быть аутентифицирована на том сервере, на котором выполняется запрос. Также этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть автоматизировано, то есть которое не может быть подделано атакующим скриптом. В качестве примера рассмотрим ситуацию, когда пользователь входит в систему с помощью проверки подлинности на основе тех самых форм, о которых мы говорили чуть раньше. Сервер выполняет проверку подлинности пользователя и выдает ответ, включающий билет пользователя в cookie. При этом сайт банка доверяет любому запросу, который он получает с допустимым билетом в cookie. Далее пользователь, не завершая принудительно сессию на сайте банка, посещает другой сайт, www.hacker.com , который содержит HTML-форму, в которой запрятана отправка в форме следующих данных: <form action=" https://bank.com/api/account" method="post"> <input type="hidden" name="Transaction" value="withdraw" /> <input type="hidden" name="Amount" value="1000000" /> <input type="submit" value="Click to collect your prize!" /> </form> Обратите внимание, что форма отправит данные именно на сайт банка. Это «межсайтовая» часть CSRF. Далее под каким-либо предлогом пользователю предлагается нажать кнопку, которая скрытно отправит данные формы. При отправке формы браузер автоматически отправит и билет в cookie для запрошенного домена, ведь пользователь формально еще залогинен на сайте банка. В результате запрос будет выполнен на сайте банка. Стоит отметить, что использование HTTPS не предотвращает атаки CSRF. Вредоносный сайт может отправлять запрос так же легко, как и небезопасный запрос. Такие атаки становятся возможными благодаря тому, что в браузере хранятся cookie, выданные приложением, эти cookie содержат в том числе сеансовые билеты прошедших проверку пользователей, и наконец браузер отправляет веб-приложению все cookie, связанные с доменом, независимо от того, как запрос к приложению был создан в браузере. Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных. Телеграм-канал: https://t.me/zashchitainformacii Группа в Телеграм: https://t.me/zashchitainformacii1 Сайт: https://legascom.ru Электронная почта: online@legascom.ru #защитаинформации #информационнаябезопасность
Компания ЛЕГАС: адвокат, юрист, жалобы в ЕСПЧ
Атаки на веб через управление сессиями.
Атаки на веб-приложения через систему управления сессиями.
Еще одним уязвимым местом являются веб-приложения. Конечно, разработка корпоративных веб-порталов обычно поручается профессионалам - веб-программистам, но системный администратор и тем более специалист по ИБ должны иметь представление о существующих уязвимостях в веб-при ложениях. Кроме того, в небольших компаниях сисадмин зачастую занимается разработкой и поддержкой корпоративного портала. Так что приведенная далее информация будет полезна многим.
Современные веб-порталы используют в качестве веб-сервера преимущественно Apache. Существует, конечно, IIS (Internet Information Services), работающий под Windows, но большинство хостингов все равно используют связку FreeBSD/Linux+Apache. Для хранения данных, с которыми работает веб-портал, обычно используется MySQL или PostgreeSQL. В высоконагруженных промышленных системах может применяться Oracle.
В качестве языка сценариев обычно используется PHP или Perl. Существуют также высокоуровневые средства разработки портальных решений от Microsoft, но в данном разделе мы не будем их касаться в силу меньшей их распространенности, по сравнению с бесплатными FreeBSD, Apache, MySQL, PHP.
В качестве практического примера рассмотрим атаки на PHP-приложение через систему управления сессиями. Основными причинами возможности данных атак являются отсутствие проверки идентификатора сессии пользователя и отсутствие проверки данных, хранящихся в сессии.
Рассмотрим возможные варианты атак на приложение.
Кража сессии (Session Hijacking).
Суть атаки заключается в использовании злоумышленником идентификатора сессии, принадлежащего легальному пользователю, для выдачи себя за владельца сессии. Узнать идентификатор чужой сессии можно с помощью перехвата трафика легального пользователя, организации XSS-атаки или посредством перебора.
Общий алгоритм осуществления атаки следующий:
1) атакующий собирает информацию об IP-адресах жертвы и том ресурсе, доступ к которому необходимо получить;
2) затем необходимо дождаться, когда атакуемый подключится к целевому ресурсу;
3) далее злоумышленнику нужно запустить ARP relay;
4) когда жертва подключилась к целевому ресурсу и начала работу с ним, атакующий увидит в сниффере новое активное соединение. Далее взломщик производит атаку десинхронизацией TCP/IP, которая уже описывалась ранее. Соединение жертвы «отваливается» с помощью принудительной отправки RST-пакета;
5) далее злоумышленник может работать от имени жертвы и с ее учетными Правами;
6) атакуемый вынужден заново переподключиться к целевому ресурсу, справедливо полагая, что произошел аппаратный сбой соединения. Злоумышленник отправляет ему RST;
7) когда хакер закончит работу с системой, он прекращает посылать RST и отключает ARP-relay;
8) взломанный пользователь снова может работать с системой.
Как нетрудно понять из описания, для реализации такой атаки необходимо быть подключенным к одному коммутатору, что и атакуемый. То есть фактически находиться в одной локальной сети с жертвой.
В более простом случае злоумышленник может попробовать взломать чужую сессию с помощью подмены cookies.
Вот небольшой пример подобной атаки на практике.
Для ее реализации необходимы сниффер, например Wireshark, браузер (например, Firefox) и редактор Cookies (можно использовать add-on к Firefox).
Атакуемый пользователь осуществляет подключение к порталу социальной сети.
Взломщик производит сниффинг трафика. По окончании перехвата трафика злоумышленнику необходимо найти переданные пользователем cookies. Сделать это в Wireshark можно следующим образом. Нажать Ctrl+F или Edit - Find Packet. В поле By: необходимо выбрать String и Search In, опцию Packet details, в текстовом поле нужно указать Set-Cookie.
Когда нужный пакет будет найден, необходимо нажать правую кнопку мыши и выбрать «Follow TCP Stream». Далее в этом потоке можно обнаружить пакет, аналогичный приведенному.
Это и есть необходимый cookie. Далее нужно открыть редактор Cookie Editor (Tools - Cookie Editor). Потом нажать Add и указать следующее:
Name: _twitter_sess
Content: copy paste the information from the TCP Stream (see the red box in the Session Cookie Found from TCP Stream picture)
Domain: . twitter.com Path: /
В случае успешной реализации теперь для входа на сайт злоумышленнику не требуется указывать учетные данные, достаточно просто зайти на страницу.
Кратко выполняются следующие действия:
1) перехват трафика;
2) обнаружение пакета, содержащего Set-Cookie;
3) установка Cookie в редакторе Cookie Editor add-on;
4) обращение к нужному сайту.
Фиксация сессии (Session Fixation).
Для осуществления этой атаки злоумышленнику не нужен идентификатор чужой сессии, достаточно установить идентификатор своей сессии легальному пользователю, прошедшему авторизацию. Как и в предыдущем случае, создается ситуация, когда злоумышленник и легальный пользователь имеют один и тот же идентификатор сессии.
Фиксация сессии (Session Fixation) представляет собой метод нападения, который принудительно устанавливает идентификатор сессии в определенное значение. В зависимости от функциональности атакуемого сайта, чтобы «зафиксировать» идентификатор сессии, может быть применено множество различных методов. Затем идентификатор пользовательской сессии фиксируется, и злоумышленник ожидает тех, кто будет входить в систему. Как только пользователь сделает это, злоумышленник использует предопределенное значение идентификатора сессии, чтобы получить его онлайн-идентификацию со всеми вытекающими последствиями.
Существует два типа систем управления сессиями: «свободные» и «строгие». Тип сессии определяется в зависимости от того, как формируются значения идентификаторов. Первый тип систем позволяет веб-браузерам указывать любой идентификатор. Второй тип систем принимает только значения, сформированные на сервере. В свободных системах произвольный идентификаторсессии обрабатывается вообще без обращения к веб-сайту. Строгие системы требуют от злоумышленника обслуживания «сессии-ловушки» с периодическим обращением к веб-сайту для предотвращения тайм-аутов по неактивности.
Без активной защиты от фиксации сессии атака может быть предпринята против любого веб-сайта, использующего сессии для идентификации подлинности пользователей. Веб-сайты, использующие идентификаторы сессий, обычно применяют Cookie, также применяются URL и скрытые поля форм. К сожалению, сессии, основанные на Cookie, проще для нападений.
В отличие от похищения идентификаторов сессий пользователей, выполняемых после их входа на веб-сайт, фиксация сессии предоставляет значительно более широкие возможности для нападения. Активная часть нападения делается до входа пользователей в систему.
Рассмотрим пример классической фиксации пользовательской сессии.
Существуют три этапа фиксации:
1) установка;
2) фиксация;
3) вхождение.
На первом этапе злоумышленник устанавливает «сессию-ловушку» на атакуемый сайт и получает этот идентификатор сессии. Или злоумышленник для нападения может выбрать случайный идентификатор сессии. Но в этом случае значение, установленное сессией-ловушкой, должно поддерживаться (чтобы «быть живым») с повторными соединениями с веб-сайтом.
Затем на следующем этапе злоумышленник помещает значение сессии-ловушки в браузер пользователя и фиксирует идентификатор пользовательской сессии. И на третьем этапе злоумышленник ожидает, пока пользователь не войдет в систему атакуемого сайта. Как только пользователь делает это, значение фиксированного идентификатора сессии будет использовано, и злоумышленник может начать работу со взломанной системой.
Для фиксации идентификатора пользовательской сессии может быть выполнен один из следующих методов:
выдача cookie с использованием клиентского скрипта;
выдача нового значения идентификатора сессии в cookie с использованием клиентского скрипта. Межсайтовое программирование в слабых местах системы защиты веб-сайта может быть использовано для изменения текущего значения cookie.
http://example/<script>document.cookie="sessionid=1234;%20domain=.example.сom";</script>.idc
Вот пример выдачи cookie с использованием МЕТА-тега. Этот метод эффективен, особенно когда блокиратор межсайтового программирования предотвращает инъекцию тегов HTML-скриптов, но не META-тегов.
http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.сom">.idc
Выдача cookie c использованием HTTP-заголовка ответа.
Злоумышленник вызывает или на целевом веб-сайте, или на любом из его поддоменов выдачу cookie с идентификатором сессии. Это может быть выполнено разными путями:
взлом веб-сервера в домене (например, плохо поддерживаемый сервер);
заражение пользовательского DNS-сервера, практически с добавлением веб-сервера злоумышленника в атакуемый домен (этот тип атак уже описывался чуть в постах, посвященном DNS);
установка злонамеренного веб-сервера в атакуемый домен (например, на рабочей станции в Windows2000 домен, все рабочие станции также находятся в DNS-домене);
использование атаки разбиение HTTP-ответа.
Здесь также стоит отметить, что длительная атака фиксации сессии может быть выполнена выдачей постоянных cookies (например, со временем жизни 10 лет), которые будут держать фиксацию сессии даже после перезагрузки пользователем компьютера. Вот пример:
http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2017%2000:00:00%20GMT";</script>.idc
Отравление сессии (Session Poisoning).
Угроза отравленной сессии возникает, если злоумышленник имеет возможность установить свой PHP-сценарий на сервере, где исполняется атакуемое приложение. Суть атаки заключается в том, что если PHP-приложения исполняются на одном сервере, то велика вероятность того, что, зная идентификатор сессии, злоумышленник сможет работать с данными сессии, созданной в атакуемом приложении. Отравление возможно, если атакуемое приложение имеет ошибку, позволяющую выполнять произвольный код, и если веб-приложение работает на сервере вместе с приложениями других пользователей хостинга.
Цель данной атаки - получение доступа к значениям сессии с возможностью чтения/записи. В случае успеха злоумышленник сможет читать и/или фальсифицировать любое значение, хранящееся в сессии. Отравления используют для получения персональных данных других пользователей, а также для модификации собственной сессии, для выдачи себя за другого и/или повышения привилегий.
Вот простейший пример данной атаки:
$var = $_GET["something"];
$_SESSION["$var"] = $var2;
Аутентификация с помощью форм.
Когда клиент заходит на страницу и вводит логин и пароль, его учетные данные передаются на сервер. В случае если аутентификация успешно пройдена, сервер формирует сессионный билет для данного пользователя и при всех последующих обращениях к серверу используется уже этот билет, данные которого сохраняются в cookie. По умолчанию время жизни билета составляет 30 минут. По окончании этого времени билет может быть автоматически продлен. В случае если в течение определенного интервала времени обращений больше не было, сервер отправляет клиенту сообщение с предложением «забыть» этот билет, в результате чего браузер удаляет данный cookie, и пользователю надо заново вводить учетные данные, чтобы войти в систему.
Казалось бы, все вполне логично и правильно. Но клиент (а точнее, злоумышленник) может периодически просить сервер продлевать свой билет, по сути неограниченное число раз. То есть сервер никак не контролирует, какое количество раз продлевался билет. И злоумышленник может просто игнорировать полученное от сервера предложение «забыть» свой билет и продолжать продлевать его и дальше.
Таким образом, если злоумышленник смог похитить cookie с билетом, он сможет использовать пользовательскую сессию.
Cross Site Request Forgery.
Старый добрый CSRF актуален и для .NET. Напомним, что CSRF - это вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от ее лица тайно отправляется запрос на другой сервер (например, на сервер платежной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счет злоумышленника).
Для осуществления этой атаки должно быть выполнено несколько условий. Во-первых, жертва должна быть аутентифицирована на том сервере, на котором выполняется запрос. Также этот запрос не должен требовать какого-либо
подтверждения со стороны пользователя, которое не может быть автоматизировано, то есть которое не может быть подделано атакующим скриптом.
В качестве примера рассмотрим ситуацию, когда пользователь входит в систему с помощью проверки подлинности на основе тех самых форм, о которых мы говорили чуть раньше. Сервер выполняет проверку подлинности пользователя и выдает ответ, включающий билет пользователя в cookie. При этом сайт банка доверяет любому запросу, который он получает с допустимым билетом в cookie. Далее пользователь, не завершая принудительно сессию на сайте банка, посещает другой сайт, www.hacker.com , который содержит HTML-форму, в которой запрятана отправка в форме следующих данных:
<form action=" https://bank.com/api/account" method="post">
<input type="hidden" name="Transaction" value="withdraw" />
<input type="hidden" name="Amount" value="1000000" />
<input type="submit" value="Click to collect your prize!" />
</form>
Обратите внимание, что форма отправит данные именно на сайт банка. Это «межсайтовая» часть CSRF. Далее под каким-либо предлогом пользователю предлагается нажать кнопку, которая скрытно отправит данные формы. При отправке формы браузер автоматически отправит и билет в cookie для запрошенного домена, ведь пользователь формально еще залогинен на сайте банка. В результате запрос будет выполнен на сайте банка. Стоит отметить, что использование HTTPS не предотвращает атаки CSRF. Вредоносный сайт может отправлять запрос так же легко, как и небезопасный запрос.
Такие атаки становятся возможными благодаря тому, что в браузере хранятся cookie, выданные приложением, эти cookie содержат в том числе сеансовые билеты прошедших проверку пользователей, и наконец браузер отправляет веб-приложению все cookie, связанные с доменом, независимо от того, как запрос к приложению был создан в браузере.
Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных.
Телеграм-канал: https://t.me/zashchitainformacii Группа в Телеграм: https://t.me/zashchitainformacii1 Сайт: https://legascom.ru Электронная почта: online@legascom.ru #защитаинформации #информационнаябезопасность