XSS как вектор атаки, даже если данные XSS, не хранившие?
У меня есть вопрос о XSS
Формы могут использоваться в качестве вектора для XSS, даже если данные не хранятся в базе данных и используются позже?
т.е. в php код был бы этим:
<form input="text" value="<?= @$_POST['my_field'] ?>" name='my_field'>
Показ окна предупреждений (демонстрируют, что JS может быть выполнен) на Вашем собственном браузере тривиален с кодом выше. Но действительно ли это годно для использования через браузеры также? Единственный сценарий, который я вижу, - то, где Вы обманываете кого-то в посещение определенной страницы, т.е. комбинации CSRF и XSS.
"Сохраненный в базе данных и используемый позже": сценарий, который я понимаю о CSS, - то, где Вы можете разместить данные на сайт, который выполняет JavaScript и показан на странице в браузере, который имеет большие/отличавшиеся полномочия, чем Ваше собственное. Но, чтобы быть ясным, это не wat, я говорю о вышеупомянутом.
4 ответа
Да, это все еще вектор атаки.
Вы должны принять во внимание следующее:
Можно ли обманом заставить аутентифицированного пользователя просмотреть эту страницу со злонамеренно созданными данными?
В данном случае ответ положительный (при условии, что у вас есть аутентифицированные пользователи). Потому что можно направить кого-то на ваш сайт и передать в это поле вредоносные переменные.
Я думаю, что вы имеете в виду, поскольку Пользователь 2 не может отображать предыдущие данные, добавленные пользователем 1, так может ли случиться XSS? Итак, если Пользователь 1 взломал URL-адрес, чтобы некоторые параметры $ _GET также отображались на веб-странице (а затем даже изменили его на tinyurl), и распространяли этот URL-адрес, говоря, что действительно стоит увидеть эту страницу и т. Д., Тогда это могло быть возможно.
Так что все же лучше избегать всех параметров при отображении страницы.
Это абсолютно допустимая форма XSS. XSS существует в двух формах - сохраненной и отраженной. Отражение гораздо более распространено, но хранение может быть более опасным. Отраженный XSS обычно используется как часть атаки социальной инженерии. Злоумышленник создает URL-адрес, подобный следующему: http://host.com/page.php?my_field=malicious_code Они часто сокращают URL-адрес на tinyutl или bit.ly и получают его обычными методами социальной инженерии (электронная почта, доска объявлений, твиттер, взломанные учетные записи facebook и т. Д.)
Да, это все еще вектор атаки, хотя воздействие более ситуативно.
Вот надуманный сценарий, который расширяет предыдущие ответы, если форма требует аутентификации для доступа (и это проще, если сайт не заботится о том, отправляются ли формы через POST или GET):
1) Злоумышленник использует CSRF для входа в систему жертва использует учетные данные злоумышленника (например, ). Таким образом, злоумышленник приносит форму для жертвы, и не имеет значения, нет ли у жертвы учетной записи.
2) Злоумышленник использует другой CSRF для выполнения XSS для формы, которая запрашивает у жертвы некоторые учетные данные и т.д. site.)
Другой выдуманный сценарий, в котором уязвимая форма выполняет некоторые важные действия, такие как перевод денег между счетами:
0) Уязвимая форма использует скрытые поля формы со случайными значениями для предотвращения CSRF. Злоумышленник не знает значений и не может организовать надлежащую атаку.
1) Злоумышленник создает полезную нагрузку CSRF, которая включает JavaScript для чтения случайных токенов csrf формы (т. Е. Извлекает их из DOM браузера).
2) Жертва входит на сайт.
3) Злоумышленник заманивает жертву полезной нагрузкой CSRF,CSRF загружает запрос формы с правильными токенами csrf, потому что он выполняется в браузере жертвы, в том же источнике сайта жертвы и с использованием сеанса аутентификации жертвы. Злоумышленнику не нужно знать токены csrf, просто уметь манипулировать полями формы, в которых они хранятся.
4) Злоумышленник извлекает выгоду из того, что жертва отправляет форму - никаких всплывающих окон или социальной инженерии не требуется, кроме заманивания жертвы к полезной нагрузке CSRF, но форма должна делать что-то «полезное» для злоумышленника.