Уязвим, когда пользователь нажимает на вредоносную ссылку - PullRequest
Новая
       29

Уязвим, когда пользователь нажимает на вредоносную ссылку

0 голосов
/ 23 мая 2019

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

https://github.com/GrepSecurity/SessionFixationExample/blob/master/SessionFixationExample/SecureLoginFunc/SecureLogin.aspx.cs

Как только пользователь вошел в систему, на странице приветствия есть код в следующей ссылке для проверки подлинности пользователя. (Это наиболее распространенный код, который я смог найти для проверки подлинности пользователя)

https://github.com/GrepSecurity/SessionFixationExample/blob/master/SessionFixationExample/SecureLoginFunc/SecureLogout.aspx.cs

Я думал об одном сценарии, где это может потерпеть неудачу. Рассмотрим сценарий

  1. Жертва вошла в систему
  2. У жертвы будут 2 переменные сеанса, созданные на сервере. Пример: Сессия ["userLoggedin"] = "Жертва" Session ["AuthToken"] = "GUID"
  3. У жертвы будет файл cookie, созданный в его браузере. Пример: Cookie ["AuthToken"] = "GUID"
  4. Атакующий отправляет вредоносную ссылку жертве, которая вносит некоторые изменения в его состояние (отправляет запрос на добавление в друзья, удаляет пользователя, выводит жертву из системы ....). Предположим, что ссылка выглядит следующим образом: www.somewebsite.com/Logout, и пользователь выходит из системы.
  5. Жертва щелкает ссылку, проходит проверку подлинности, поскольку файл cookie из браузера, т. Е. «GUID», отправляется на сервер и проверяется по переменной сеанса.
  6. Пользователь выходит из системы

Я понимаю, что с упомянутыми выше возможностями нет серьезного эффекта, но все же, можно ли предотвратить этот сценарий? Или это даже правильный сценарий? Я что-то упустил?

Вот мои вопросы

  1. Может ли этот сценарий быть обработан? (Учитывая, что это допустимый сценарий)
  2. Имею ли я в виду защищенный код?
  3. Что это за уязвимость?
  4. Как я могу смягчить это?

1 Ответ

0 голосов
/ 03 июля 2019

В этом примере вы упомянули, что это был другой сценарий атаки (CSRF).

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

Для защиты от CSRF вам может потребоваться следовать руководству OWASP.(https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md)

Но для вашего примера. Предположим, вы хотите защитить действие под названием Order. На вашем сервере будет сгенерирован токен. Этот токен будет затем обработан или отправлен клиенту. ДействительныйЗапрос будет выглядеть как www.somewebsite.com/Order с почтовым параметром Order=Something & Token="RANDOM_TOKEN"

Этот токен будет впоследствии проверен сервером перед выполнением этой операции.

Злоумышленник, тем не менее, не будет иметь доступа к этому токену.если он просто отправляет этот запрос с другого сайта / домена, поскольку он был обработан на странице клиента.

Может ли злоумышленник получить доступ к этому токену?

Да, это возможно, если приложение уязвимо для (XSS). Используя JS, злоумышленник может отправить вредоносную ссылку жертве с помощью команды JS, которая будет

  • Извлекать визуализированный токен CSRF.
  • Выполните Действие с помощью токена.

Хотя в обычном сценарии XSS украдут куки жертвы, но в случаеооки были помечены HTTPOnly возможна атака CSRF.

...