Translated plans from chapter 'Cross-Site scriptiong'
git-svn-id: http://webgoat.googlecode.com/svn/trunk/webgoat@428 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
white.tiger.russia@gmail.com
parent
a66e8d4c78
commit
22a8385c77
@ -1,26 +1,40 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Request Forgery. </p>
|
||||
<p><b>Название урока:</b> Проведение атак межсайтовой подделки запросов. </p>
|
||||
</div>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks.
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
На данном уроке вы научитесь использовать уязвимости межсайтовой подделки запросов (CSRF).
|
||||
<br>
|
||||
<div align="Left">
|
||||
<p>
|
||||
<b>How the attacks works:</b>
|
||||
<b>Как работает данный тип атак:</b>
|
||||
</p>
|
||||
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page that contains img links like the one below:
|
||||
При проведении атак межсайтовой подделки запросов жертву заставляют каким-либо образом
|
||||
загрузить страницу содержащую опасную картинку, типа той что представлена ниже:
|
||||
|
||||
<pre><img src="<a href="http://www.mybank.com/transferFunds.do?acctId=123456" class='external free' title="http://www.mybank.com/transferFunds.do?acctId=123456" rel="nofollow">http://www.mybank.com/sendFunds.do?acctId=123456</a>"/></pre>
|
||||
|
||||
When the victim's browser attempts to render this page, it will issue a request to www.mybank.com to the transferFunds.do page with the specified parameters. The browser will think the link is to get an image, even though it actually is a funds transfer function.
|
||||
Когда браузер жертвы обрабатывает такую страницу, он автоматически совершает обращение
|
||||
к сайту www.mybank.com, к скрипту transferFunds.do передавая необходимый злоумышленнику параметр.
|
||||
Браузер будет думать что это простое изображение, тогда как на самом деле обращение к этому
|
||||
адресу вызовет перевод денег.
|
||||
|
||||
The request will include any cookies associated with the site. Therefore, if the user has authenticated to the site, and has either a permanent cookie or even a current session cookie, the site will have no way to distinguish this from a legitimate user request.
|
||||
Вместе с запросом, уходящим на сайт банка, будут переданы и cookies клиента. Следовательно,
|
||||
если в этот момент пользователь будет авторизирован на www.mybank.com, и в его cookies будет хранится
|
||||
идентификатор активной сессии, скрипт transferFunds.do примет этот запрос за легитимный и
|
||||
совершит необходимую злоумышленнику операцию.
|
||||
|
||||
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, or any other function provided by the vulnerable website
|
||||
Таким образом, атакующий может производить практически все действия, которые способен делать
|
||||
настоящий пользователь.
|
||||
</div>
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
<p><b>Основные цели и задачи:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Your goal is to send an email to a newsgroup that contains an image whose URL is pointing to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.
|
||||
Ваша цель - послать в новостную группу письмо, содержащее в себе изображение со
|
||||
специально сформированным адресом. Картинка должна иметь размер 1*1px и производить
|
||||
CSRF-атаку, заставляя браузер обращаться к текущей странице, но с дополнительным параметром
|
||||
в URL - "transferFunds=4000". Когда вы отошлёте сообщение и оно отобразится на экране,
|
||||
браузер автоматически осуществит необходимый запрос. Как только вы решили что выполнили это задание
|
||||
просто обновите страницу. Если всё сделано верно, то в главном меню, на против соответствующего урока,
|
||||
появится зелёная отметка.
|
||||
<!-- Stop Instructions -->
|
||||
|
||||
|
||||
@ -1,12 +1,21 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
<p><b>Название урока:</b> Как проводить атаки межсайтового скриптинга (XSS)</p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b></p>
|
||||
<p><b>Тема для изучения:</b></p>
|
||||
<!-- Start Instructions -->
|
||||
It is always a good practice to scrub all inputs, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere. Users should not be able to create message content that could cause another user to load an undesirable page or undesirable content when the user's message is retrieved.<br>
|
||||
XSS can also occur when unvalidated user input is used in an HTTP response. In a reflected XSS attack, an attacker can craft a URL with the attack script and post it to another website, email it, or otherwise get a victim to click on it.
|
||||
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
|
||||
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
|
||||
БД. Это важно и для тех данных, которые будут сохранены где-то
|
||||
внутри приложения. Посетители не должны иметь возможность публикации на сайте
|
||||
таких сообщений, которые могут изменять структуру страницы при их просмотре.
|
||||
<br>
|
||||
XSS также может возникнуть когда введённая пользователем информация сразу же,
|
||||
без всяческих проверок, помещается в HTTP-запрос, но не сохраняется внутри приложения
|
||||
(отражаемые XSS). В таких случаях нападающий может сформировать URL, содержащий в себе
|
||||
вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>General Goal(s):</b></p>
|
||||
For this exercise, you will perform stored and reflected XSS attacks. You will also implement code changes in the web application to defeat these attacks.
|
||||
<p><b>Основные цели и задачи:</b></p>
|
||||
На данном уроке вы научитесь использовать хранимые и отражаемые XSS-уязвимости.
|
||||
В конце вам придётся внести изменения в код приложения для устранения данных уязвимостей.
|
||||
<br>
|
||||
|
||||
|
||||
@ -1,32 +1,31 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b>CSRF User Prompt By-Pass</p><br/>
|
||||
<p><b>Название урока:</b>CSRF, обход мезанизмов подтверждений</p><br/>
|
||||
</div>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
This lesson teaches how to perform CSRF attacks that by-pass user confirmation prompts.
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
На данном уроке вы научитесь проводить CSRF-нападения в обход механизмов подтверждения операций.
|
||||
<br>
|
||||
<div align="Left">
|
||||
<p>
|
||||
<b>How the attacks works:</b>
|
||||
<b>Как работает данный класс атак:</b>
|
||||
<p>
|
||||
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page
|
||||
that contains a 'forged request' to execute commands with the victim's credentials. Prompting
|
||||
a user to confirm or cancel the command might sound like a solution, but can be by-passed if
|
||||
the prompt is scriptable. This lesson shows how to by-pass such a prompt by issuing another
|
||||
forged request. This can also apply to a series of prompts such as a wizard or issuing multiple
|
||||
unrelated forged requests.</p>
|
||||
|
||||
CSRF является таким видом атак, при проведении которых браузер жертвы, без её ведома, отправляет
|
||||
на целевой сайт запросы нужные злоумышленнику. Иногда, при проведении важных операций, сервер может
|
||||
запросить у пользователя их подтверждение. Этот ход может показаться решением проблем связанных с CSRF,
|
||||
но только не в случаях когда подтверждение реализовано средствами JavaScript. На данном уроке вы научитесь
|
||||
обходить такие варианты подтверждений, как одиночных, так и многочисленных. Решением будет являться та же посылка
|
||||
поддельных запросов, но уже не одного, а нескольких.
|
||||
</p>
|
||||
|
||||
|
||||
</div>
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
<p><b>Цели и задачи:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains multiple
|
||||
malicious requests: the first to transfer funds, and the second a request to confirm the prompt
|
||||
that the first request triggered. The URL should point to the CSRF lesson with an extra
|
||||
parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the shortcut from the
|
||||
left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever
|
||||
receives this email and happens to be authenticated at that time will have his funds transferred.
|
||||
When you think the attack is successful, refresh the page and you will find the green check on
|
||||
the left hand side menu.
|
||||
Как и в прошлом уроке, вашей целью является отправка электронного письма в новостную группу. Письмо, при просмотре,
|
||||
должно вызывать отправку нескольких поддельных запросов: первый на осуществление денежного перевода, второй на
|
||||
его подтверждение. Сначала URL, по которому будет произведено обращение, должен содержать параметр "transferFunds",
|
||||
равный "4000", затем его же, но со значением "CONFIRM". После того как сообщение отобразится на экране, браузер любого
|
||||
кто его увидит сам сделает всё что нужно. В конце работы обновите текущую страницу. Если задание выполнено верно, то в
|
||||
главном меню, на против этого урока, появится зелёная отметка.
|
||||
<!-- Stop Instructions -->
|
||||
|
||||
|
||||
@ -1,37 +1,41 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b>CSRF Token Prompt By-Pass</p><br/>
|
||||
<p><b>Название урока:</b>Обход CSRF-защиты основанной на токенах</p><br/>
|
||||
</div>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
This lesson teaches how to perform CSRF attacks on sites that use tokens to mitigate CSRF attacks, but are vulnerable to CSS attacks.
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
На данном уроке вы научитесь осуществлять CSRF-нападения на сайты, использующие токены в качестве защиты
|
||||
от CSRF-атак.
|
||||
<br>
|
||||
<div align="Left">
|
||||
<p>
|
||||
<b>How the attacks works:</b>
|
||||
<b>Как работают эти атаки:</b>
|
||||
</p>
|
||||
<p>
|
||||
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into
|
||||
loading a page that contains a 'forged request' to execute commands with the
|
||||
victim's credentials. </p>
|
||||
CSRF-атаки заставляют браузер жертвы осуществлять необходимые злоумышленнику запросы
|
||||
к целевому серверу в невидимом режиме. Это позволяет атакующему вызывать выполнение различных операций
|
||||
от лица атакованного пользователя с его правами и привилегиями.</p>
|
||||
|
||||
<p>Token-based request authentication mitigates these attacks. This technique
|
||||
inserts tokens into pages that issue requests. These tokens are required to
|
||||
complete a request, and help verify that requests are not scripted. CSRFGuard from OWASP uses
|
||||
this technique to help prevent CSRF attacks.</p>
|
||||
<p>Аутентификация запросов принимаемых от посетителей, основанная на уникальных токенах, предотвращает
|
||||
возможность CSRF-нападений. При использовании данной техники, при отправке важного запроса, серверу
|
||||
передаётся уникальный для каждого клиента токен, наличие которого подтверждает его легитимность.
|
||||
Проект OWASP CSRFGuard как раз использует такой подход, позволяя защитить приложения от CSRF-нападений.
|
||||
</p>
|
||||
|
||||
<p>However, this technique can be by-passed if CSS vulnerabilities exist on the same site.
|
||||
Because of the same-origin browser policy, pages from the same domain can read content from
|
||||
other pages from the same domain. </p>
|
||||
<p>
|
||||
Тем не менее, данный вид защиты можно обойти. Для этого достаточно обнаружить на атакуемом сайте XSS-уязвимость.
|
||||
Её наличие поможет отправлять запросы от имени жертвы, ведь системы безопасности всех браузеров,
|
||||
основанных на политике одного источника, не запрещают обращаться к текущему домену.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
<p><b>Основные цели и задачи:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains a malicious
|
||||
request to transfer funds. To successfully complete you need to obtain a valid request token.
|
||||
The page that presents the transfer funds form contains a valid request token. The URL for the
|
||||
transfer funds page is the same as this lesson with an extra parameter "transferFunds=main". Load
|
||||
this page, read the token and append the token in a forged request to transferFunds. When you think
|
||||
the attack is successful, refresh the page and you will find the green check on the left hand side menu.
|
||||
Как и в прошлом уроке, вашей целью является отправка письма в новостную группу для вызова нелегитимного
|
||||
перевода денег. Для её достижения вам необходимо узнать действующий токен. Он находится в коде страницы на
|
||||
которой расположена форма перевода денег. Для того чтоб увидеть форму, необходимо к текущему URL
|
||||
дописать параметр "transferFunds=main". Загрузите эту страницу, считайте оттуда значение токена и осуществите перевод.
|
||||
В конце работы обновите текущую страницу. Если задание выполнено верно, то в главном меню, на против этого урока,
|
||||
появится зелёная отметка.
|
||||
<!-- Stop Instructions -->
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,24 +1,21 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting
|
||||
(XSS)</p>
|
||||
<p><b>Название урока:</b> Как проводить атаки межсайтового скриптинга (XSS)</p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b></p>
|
||||
<p><b>Тема для изучения:</b></p>
|
||||
<!-- Start Instructions -->
|
||||
It is always a good practice to scrub all inputs, especially those
|
||||
inputs that will later be used as parameters to OS commands, scripts,
|
||||
and database queries. It is particularly important for content that will
|
||||
be permanently stored somewhere. Users should not be able to create
|
||||
message content that could cause another user to load an undesirable
|
||||
page or undesirable content when the user's message is retrieved.
|
||||
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
|
||||
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
|
||||
БД. Это важно и для тех данных, которые будут сохранены где-то
|
||||
внутри приложения. Посетители не должны иметь возможность публикации на сайте
|
||||
таких сообщений, которые могут изменять структуру страницы при их просмотре.
|
||||
<br>
|
||||
XSS can also occur when unvalidated user input is used in an HTTP
|
||||
response. In a reflected XSS attack, an attacker can craft a URL with
|
||||
the attack script and post it to another website, email it, or otherwise
|
||||
get a victim to click on it.
|
||||
XSS также может возникнуть когда введённая пользователем информация сразу же,
|
||||
без всяческих проверок, помещается в HTTP-запрос, но не сохраняется внутри приложения
|
||||
(отражаемые XSS). В таких случаях нападающий может сформировать URL, содержащий в себе
|
||||
вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>General Goal(s):</b></p>
|
||||
For this exercise, you will perform a stored XSS attack.
|
||||
You will also implement code changes in the database to defeat
|
||||
these attacks.
|
||||
<p><b>Основные цели:</b></p>
|
||||
В данном упражнении вы научитесь осуществлять хранимые XSS-атаки.
|
||||
В конце урока вам необходимо будет внести изменения в код базы данных для того, чтоб предотвратить подобые нападения.
|
||||
<br>
|
||||
|
||||
|
||||
@ -1,26 +1,24 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> HttpOnly Test</p>
|
||||
<p><b>Название урока:</b> Проверка HttpOnly</p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b></p>
|
||||
<p><b>Тема для изучения:</b></p>
|
||||
<!-- Start Instructions -->
|
||||
To help mitigate the cross site scripting threat, Microsoft has
|
||||
introduced a new cookie attribute entitled 'HttpOnly.' If this flag is
|
||||
set, then the browser should not allow client-side script to access the
|
||||
cookie. Since the attribute is relatively new, several browsers neglect
|
||||
to handle the new attribute properly.
|
||||
<p>For a list of supported browsers see: <a href=http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly>OWASP HTTPOnly Support</a>
|
||||
<p><b>General Goal(s):</b></p>
|
||||
The purpose of this lesson is to test whether your browser supports the
|
||||
HTTPOnly cookie flag. Note the value of the
|
||||
<strong>unique2u</strong>
|
||||
cookie. If your browser supports HTTPOnly, and you enable it for a
|
||||
cookie, client side code should NOT be able to read OR write to that
|
||||
cookie, but the browser can still send its value to the server. Some
|
||||
browsers only prevent client side read access, but don't prevent write
|
||||
access.
|
||||
Для того чтоб помешать проведению XSS-нападений компания Microsoft
|
||||
ввела новый параметр для cookies, называемый 'HttpOnly'. Если данный флаг
|
||||
активен, то браузер не разрешает работающим на стороне клиента скриптам
|
||||
получать доступ к cookies. Некоторые браузеры, к сожалению, не учитывают
|
||||
наличие 'HttpOnly' в своей работе.
|
||||
<p>Список браузеров поддерживающих данный параметр можно найти здесь: <a href=http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly>OWASP HTTPOnly Support</a>
|
||||
<p><b>Основные цели и задачи:</b></p>
|
||||
На данном уроке вы должны проверить, поддерживает ли ваш браузер флаг HTTPOnly применив его к
|
||||
cookies с именем <strong>unique2u</strong>.
|
||||
Если да, то включив его вы не сможете получить доступ к их содержимому через
|
||||
код на клиентской стороне. Вы также не сможете записывать новые данные в них, или изменять
|
||||
уже имеющиеся (хотя некоторые браузеры запрещают только считывание).
|
||||
Но при этом браузер исправно будет предавать их серверу.
|
||||
<br />
|
||||
<br />
|
||||
With the HTTPOnly attribute turned on, type
|
||||
"javascript:alert(document.cookie)" in the browser address bar. Notice
|
||||
all cookies are displayed except the unique2u cookie.
|
||||
Когда вы включите HTTPOnly, находясь на странице, cookies домена которой он защищает,
|
||||
впишите в адресную строку выражение "javascript:alert(document.cookie)". Вы увидите табличку со всеми
|
||||
cookies кроме unique2u.
|
||||
<!-- Stop Instructions -->
|
||||
@ -1,16 +1,17 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> Phishing with XSS </p>
|
||||
<p><b>Название урока:</b> Фишинг, основанный на применении XSS </p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
It is always a good practice to validate all input on the server side.
|
||||
XSS can occur when unvalidated user input is used in an HTTP response.
|
||||
With the help of XSS you can do a Phishing Attack and add content to a page
|
||||
which looks official. It is very hard for a victim to determinate
|
||||
that the content is malicious.
|
||||
Проверка всех принимаемых от пользователей данных всегда считается хорошей практикой.
|
||||
XSS-уязвимости возникают в том случае, когда непроверенные пользовательские данные
|
||||
возвращаются ему же в HTTP-ответе. С использованием XSS-уязвимостей вы можете совершать
|
||||
фишинг-атаки или же просто добавлять на уязвимую страницу какое-нибудь стороннее содержимое.
|
||||
В таких ситуациях посетителям-жертвам очень трудно отделить настоящую информацию на сайте от
|
||||
поддельной.
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
The user should be able to add a form asking for username
|
||||
and password. On submit the input should be sent
|
||||
to http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName
|
||||
<p><b>Основные цели и задачи:</b> </p>
|
||||
Пользователь должен каким-либо образом добавить на страницу форму
|
||||
запроса логина и пароля. При её отправке введённые данные должны уходить на адрес
|
||||
http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName
|
||||
|
||||
|
||||
@ -1,13 +1,14 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title: </b>How to Perform Reflected Cross Site Scripting (XSS)</p>
|
||||
<p><b>Название урока: </b>Использование отражённых XSS-уязвимостей</p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
It is always a good practice to validate all input on the server side.
|
||||
XSS can occur when unvalidated user input is used in an HTTP response.
|
||||
In a reflected XSS attack, an attacker can craft a URL with the attack
|
||||
script and post it to another website, email it, or otherwise get a
|
||||
victim to click on it.
|
||||
Всегда хорошей практикой считалась проверка всех входящих данных на стороне сервера.
|
||||
XSS-уязвимости могут возникать в тех случаях, когда непроверенные пользовательские
|
||||
данные сразу помещаются в HTTP-ответ. В таких случаях нападающий может сформировать URL, содержащий в себе
|
||||
вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
For this exercise, your mission is to come up with some input containing a script. You have to try to get this page to reflect that input back to your browser, which will execute the script and do something bad.
|
||||
<p><b>Основные цели и задачи:</b> </p>
|
||||
В этом упражнении вашей целью является отправка серверу специально сформированного
|
||||
вредоносного сообщения, которое, отобразившись в ответной странице,осуществит
|
||||
какие-нибудь опасные действия (например выполнит произвольный JS-код).
|
||||
@ -1,9 +1,14 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Stored Cross Site Scripting (XSS) </p>
|
||||
<p><b>Название урока:</b> Проведение хранимых XSS</p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved.
|
||||
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
|
||||
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
|
||||
БД. Это важно и для тех данных, которые будут сохранены где-то
|
||||
внутри приложения. Посетители не должны иметь возможность публикации на сайте
|
||||
таких сообщений, которые могут изменять структуру страницы при их просмотре.
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
The user should be able to add message content that cause another user to load an undesireable page or content.
|
||||
<p><b>Основные цели и задачи:</b> </p>
|
||||
Вы должны добавить такое сообщение, которое при просмотре другим пользователем будет формировать
|
||||
на данной странице поддельное содержимое.
|
||||
@ -1,9 +1,14 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Tracing (XST) Attacks </p>
|
||||
<p><b>Название урока:</b> Проведение XST-атак (Cross Site Tracing/Trace-XSS) </p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<p><b>Тема для изучения:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved.
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
Tomcat is configured to support the HTTP TRACE command. Your goal is to perform a Cross Site Tracing (XST) attack.
|
||||
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
|
||||
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
|
||||
БД. Это важно и для тех данных, которые будут сохранены где-то
|
||||
внутри приложения. Посетители не должны иметь возможность публикации на сайте
|
||||
таких сообщений, которые могут изменять структуру страницы при их просмотре.
|
||||
<p><b>Основные цели:</b> </p>
|
||||
Tomcat настроен на поддержку команды HTTP TRACE. Ваша цель с её помощью осуществить
|
||||
XST-нападение.
|
||||
<!-- Stop Instructions -->
|
||||
Loading…
x
Reference in New Issue
Block a user