Влияние межсайтового скриптинга
С момента последнего момента межсайтовый скриптинг удерживает свои позиции в списке OWASP Top10, поскольку это один из самых важных и наиболее широко используемых методов атаки в Интернете.
Таким образом, эксплуатируя данную уязвимость, злоумышленник может:
· CWE-79: Неправильная нейтрализация ввода во время создания веб-страницы («Межсайтовый скриптинг»)
· CWE-80: неправильная нейтрализация связанных со скриптами HTML-тегов на веб-странице (базовый XSS)
Типы XSS
До сих пор у вас могло быть четкое представление о концепции JavaScript и XSS и их основных последствиях. Итак, давайте продолжим по тому же пути и разделим этот XSS на три основных типа:
§ Сохраненный XSS
§ Отраженный XSS
§ XSS на основе DOM
Сохраненный XSS
«Сохраненный XSS», часто называемый «Постоянный XSS» или «Тип I», поскольку благодаря этой уязвимости внедренный вредоносный сценарий постоянно сохраняется на сервере базы данных веб-приложения, а затем сервер отбрасывает его обратно, когда пользователь посещает соответствующий интернет сайт.
Однако это происходит как -. когда клиент щелкает или наводит курсор на конкретный зараженный раздел, внедренный JavaScript запускается браузером, поскольку он уже был в базе данных приложения. Следовательно, эта атака не требует каких-либо методов фишинга для нацеливания на своих пользователей.
Наиболее распространенным примером хранимого XSS является «опция комментариев» в блогах, которая позволяет любому пользователю вводить свой отзыв в форме комментариев для администратора или других пользователей.
Давайте рассмотрим это на примере:
Веб-приложение просит своего пользователя оставить отзыв, поскольку на его веб-странице есть два поля ввода - одно для имени, а другое для комментария.
Теперь, когда пользователь нажимает кнопку отправки, его запись сохраняется в базе данных. Чтобы было понятнее, я вызвал на экран таблицу базы данных как:
Здесь разработчик доверяет своим пользователям и не размещал никаких проверок в полях. Таким образом, злоумышленник обнаружил эту лазейку и поэтому воспользовался ею, поскольку - вместо того, чтобы отправлять отзыв, он прокомментировал свой вредоносный скрипт.
На приведенном ниже снимке экрана видно, что злоумышленник добился успеха, поскольку веб-приложение отображает всплывающее окно с предупреждением.
Теперь, вернувшись к базе данных, вы можете видеть, что таблица была обновлена с именем «Ignite», а поле Feedback пусто, это означает, что сценарий злоумышленника был успешно внедрен.
Итак, давайте переключимся на другой браузер как другой пользователь и снова попробуем оставить искренний отзыв.
Теперь, когда мы нажимаем кнопку «Отправить», наш браузер выполнит внедренный скрипт и отобразит его на экране.
Отраженный XSS
Отраженный XSS, также называемый «Non-Persistence XSS» или «Тип II», возникает, когда веб-приложение немедленно отвечает на ввод пользователя без проверки того, что пользователь ввел, это может привести к тому, что злоумышленник внедрит исполняемый код браузера в один ответ HTML. . Это называется «непостоянным», поскольку вредоносный сценарий не сохраняется в базе данных веб-сервера, поэтому злоумышленнику необходимо отправить вредоносную ссылку через фишинг, чтобы поймать пользователя.
Отраженный XSS является наиболее распространенным, и поэтому его можно легко найти в «полях поиска веб-сайта», где злоумышленник включает некоторые произвольные коды Javascript в текстовое поле поиска и, если веб-сайт уязвим, веб-страница возвращает событие в том виде, в котором оно было. описано в сценарии.
Reflect XSS - бывает двух типов:
§ Отраженный XSS GET
§ Отраженный XSS POST
Чтобы лучше понять концепцию Reflected XSS, давайте рассмотрим следующий сценарий.
Здесь мы создали веб-страницу, которая, таким образом, позволяет пользователю искать определенный учебный курс.
Итак, когда пользователь ищет «Bug Bounty», на экране снова появляется сообщение «Вы искали Bug Bounty».
Таким образом, этот мгновенный ответ и параметр «поиск» в URL-адресе показывают, что страница может быть уязвима для XSS, и даже данные были запрошены через метод GET.
Итак, давайте теперь попробуем сгенерировать несколько всплывающих окон, вставив коды Javascript в этот параметр «поиска» как
Супер!! На скриншоте ниже вы можете видеть, что мы получили предупреждение как «Добро пожаловать в статьи о взломе !!»
Интересно, почему все это произошло? Давайте посмотрим на следующий фрагмент кода.
С легкостью отображая сообщение на экране, разработчик не настраивал проверку ввода в функции ignite, а просто «эхо» «выводит сообщение поиска» с помощью ignite ($ search) через переменную «$ _GET». .
С момента последнего момента межсайтовый скриптинг удерживает свои позиции в списке OWASP Top10, поскольку это один из самых важных и наиболее широко используемых методов атаки в Интернете.
Таким образом, эксплуатируя данную уязвимость, злоумышленник может:
- Захват и доступ к аутентифицированным сеансовым cookie-файлам пользователя.
- Загружает фишинговую страницу, чтобы побудить пользователей к непреднамеренным действиям.
- Перенаправляет посетителей на другие вредоносные разделы.
- Раскрывать конфиденциальные данные пользователя.
- Манипулирует структурой веб-приложения или даже искажает ее.
· CWE-79: Неправильная нейтрализация ввода во время создания веб-страницы («Межсайтовый скриптинг»)
· CWE-80: неправильная нейтрализация связанных со скриптами HTML-тегов на веб-странице (базовый XSS)
Типы XSS
До сих пор у вас могло быть четкое представление о концепции JavaScript и XSS и их основных последствиях. Итак, давайте продолжим по тому же пути и разделим этот XSS на три основных типа:
§ Сохраненный XSS
§ Отраженный XSS
§ XSS на основе DOM
Сохраненный XSS
«Сохраненный XSS», часто называемый «Постоянный XSS» или «Тип I», поскольку благодаря этой уязвимости внедренный вредоносный сценарий постоянно сохраняется на сервере базы данных веб-приложения, а затем сервер отбрасывает его обратно, когда пользователь посещает соответствующий интернет сайт.
Однако это происходит как -. когда клиент щелкает или наводит курсор на конкретный зараженный раздел, внедренный JavaScript запускается браузером, поскольку он уже был в базе данных приложения. Следовательно, эта атака не требует каких-либо методов фишинга для нацеливания на своих пользователей.
Наиболее распространенным примером хранимого XSS является «опция комментариев» в блогах, которая позволяет любому пользователю вводить свой отзыв в форме комментариев для администратора или других пользователей.
Давайте рассмотрим это на примере:
Веб-приложение просит своего пользователя оставить отзыв, поскольку на его веб-странице есть два поля ввода - одно для имени, а другое для комментария.
Теперь, когда пользователь нажимает кнопку отправки, его запись сохраняется в базе данных. Чтобы было понятнее, я вызвал на экран таблицу базы данных как:
Здесь разработчик доверяет своим пользователям и не размещал никаких проверок в полях. Таким образом, злоумышленник обнаружил эту лазейку и поэтому воспользовался ею, поскольку - вместо того, чтобы отправлять отзыв, он прокомментировал свой вредоносный скрипт.
Код:
<script>alert("Hey!! This website belongs to Hacking Articles")</script>Теперь, вернувшись к базе данных, вы можете видеть, что таблица была обновлена с именем «Ignite», а поле Feedback пусто, это означает, что сценарий злоумышленника был успешно внедрен.
Итак, давайте переключимся на другой браузер как другой пользователь и снова попробуем оставить искренний отзыв.
Теперь, когда мы нажимаем кнопку «Отправить», наш браузер выполнит внедренный скрипт и отобразит его на экране.
Отраженный XSS
Отраженный XSS, также называемый «Non-Persistence XSS» или «Тип II», возникает, когда веб-приложение немедленно отвечает на ввод пользователя без проверки того, что пользователь ввел, это может привести к тому, что злоумышленник внедрит исполняемый код браузера в один ответ HTML. . Это называется «непостоянным», поскольку вредоносный сценарий не сохраняется в базе данных веб-сервера, поэтому злоумышленнику необходимо отправить вредоносную ссылку через фишинг, чтобы поймать пользователя.
Отраженный XSS является наиболее распространенным, и поэтому его можно легко найти в «полях поиска веб-сайта», где злоумышленник включает некоторые произвольные коды Javascript в текстовое поле поиска и, если веб-сайт уязвим, веб-страница возвращает событие в том виде, в котором оно было. описано в сценарии.
Reflect XSS - бывает двух типов:
§ Отраженный XSS GET
§ Отраженный XSS POST
Чтобы лучше понять концепцию Reflected XSS, давайте рассмотрим следующий сценарий.
Здесь мы создали веб-страницу, которая, таким образом, позволяет пользователю искать определенный учебный курс.
Итак, когда пользователь ищет «Bug Bounty», на экране снова появляется сообщение «Вы искали Bug Bounty».
Таким образом, этот мгновенный ответ и параметр «поиск» в URL-адресе показывают, что страница может быть уязвима для XSS, и даже данные были запрошены через метод GET.
Итак, давайте теперь попробуем сгенерировать несколько всплывающих окон, вставив коды Javascript в этот параметр «поиска» как
Код:
<script>alert("Welcome to hacking Articles!!")</script>Интересно, почему все это произошло? Давайте посмотрим на следующий фрагмент кода.
С легкостью отображая сообщение на экране, разработчик не настраивал проверку ввода в функции ignite, а просто «эхо» «выводит сообщение поиска» с помощью ignite ($ search) через переменную «$ _GET». .