6.7 KiB
XSS - cross-site -scripting - уязвимость, открывающая атакующему поставить под угрозу взаимодействие пользователя с уязвимым приложением. Позволяет обойти политику, котороая разработана для отделения сайтов друг от друга.
XSS позволяет маскироваться под обычного пользователя, выполняя все действия, которые он может выполнять и получить доступ к любой информации пользователя. Если пользователь-жертва имеет привелегилированный доступ к системе, то это позволит атакующему получить полный доступ к системе и всем данным.
Как оно работает?
XSS выполняется на стороне браузера жертвы. Атакующий манипулирует сайтом таким образом, что бы тот возвращал вредоносный JS юзерам. Когда вредоносный JS выполнится в браузере жертвы, атакующий сможет получить данные о всем взаимодействии с сервисом.
Проверка на наличие XXS
Вы можете подтвердить большинство xxs, исполнив произвольных java script код в своём браузере. Использование функции alert - общепринятая практика, так как она легкая, безвредная, и ее сложно пропустить при успешном вызове.
НО, если жертва ипользует chrome, то использовать alert() не получится, рекомендуется ипользовать print()
Типы xss
- Reflected XSS - вредоносный скрипт исходит от текущего http запроса
- Stored XSS - вредоносный скрипт исходит от базы данных сервиса
- DOM-based XXS - уязвимость находится на стороне клиента, а не сервиса
Reflected cross site-scripting (Reflected XSS)
Reflected XSS самый простой вариат XSS. Он возникает, когда сервис принимает данные в HTTP запросах и данные сразу возвращаются по небезопасному пути. Небольшой пример:
https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>
Сервис не выполняет обработку данных, атакующий может легко составить атаку таким образом:\
https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>
Если пользователь посетит ссылку, составленную атакующим, тогда скрипт атакующего выполнится в браузере жертвы. Скрипт может выполнять любое действие, получать любые данные к которым у пользователя есть доступ.
Stored cross-site scripting (Stored XSS)
Stored XSS, котрые так же извесны как постоянные или XSS второго порядка, возникают когда сервис получает от недоверенного рессурса и включает эти данные в свои последующие HTTP-ответы небезопасным способом.
Соответствующие данные могут быть отправлены в приложение через HTTP-запросы; например, комментарии к сообщению в блоге, псевдонимы пользователей в чате или контактные данные в заказе клиента. В других случаях данные могут поступать из других ненадежных источников; например, приложение веб-почты, отображающее сообщения, полученные через SMTP, маркетинговое приложение, отображающее сообщения в социальных сетях, или приложение мониторинга сети, отображающее пакетные данные из сетевого трафика.
Вот простой пример сохраненной XSS-уязвимости. Приложение доски объявлений позволяет пользователям отправлять сообщения, которые отображаются другим пользователям:
<p>Hello, this is my message!</p>
Никакой другой обработки данных приложение не выполняет, поэтому злоумышленник может легко отправить сообщение, атакующее других пользователей:
<p><script>/* Bad stuff here... */</script></p>
DOM XSS
DOM XSS возникают, когда сервис включает в сеюя некий javascript код на стороне клиента, который обрабатывает данные из недоверенных источников.
В приведенном ниже примере, сервис использует JS для чтения значения в полях ввода и записать считанные данные в HTML.
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;
Если атакующий может контролировать значение в поле ввода, то он легко может составить вирусное значение, которое может выполнить их код. Обычно, поле для ввода используется как HTTP запрос, что позволяет атакующему составить атаку используя вирусную ссылку, так же как в Reflective XSS
<img src=1 onerror='/* Bad stuff here... */'>