Translated plans from chapter 'Cross-Site scriptiong'

git-svn-id: http://webgoat.googlecode.com/svn/trunk/webgoat@428 4033779f-a91e-0410-96ef-6bf7bf53c507

src/main/webapp/lesson_plans/ru/CSRF.html

@@ -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>
+<p><b>Тема для изучения:</b> </p>
- This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks.
+На данном уроке вы научитесь использовать уязвимости межсайтовой подделки запросов (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>&lt;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>"/&gt;</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 -->
 

src/main/webapp/lesson_plans/ru/CrossSiteScripting.html

@@ -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>
+<p><b>Основные цели и задачи:</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.
+На данном уроке вы научитесь использовать хранимые и отражаемые XSS-уязвимости.
+В конце вам придётся внести изменения в код приложения для устранения данных уязвимостей.
 <br>
 

src/main/webapp/lesson_plans/ru/CsrfPromptByPass.html

@@ -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>
+<p><b>Тема для изучения:</b> </p>
-This lesson teaches how to perform CSRF attacks that by-pass user confirmation prompts.
+На данном уроке вы научитесь проводить 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 
+CSRF является таким видом атак, при проведении которых браузер жертвы, без её ведома, отправляет
-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 
+запросить у пользователя их подтверждение. Этот ход может показаться решением проблем связанных с CSRF,
-the prompt is scriptable.  This lesson shows how to by-pass such a prompt by issuing another 
+но только не в случаях когда подтверждение реализовано средствами JavaScript. На данном уроке вы научитесь
-forged request.  This can also apply to a series of prompts such as a wizard or issuing multiple 
+обходить такие варианты подтверждений, как одиночных, так и многочисленных. Решением будет являться та же посылка
-unrelated forged requests.</p> 
+поддельных запросов, но уже не одного, а нескольких.
-
+</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 
+его подтверждение. Сначала URL, по которому будет произведено обращение, должен содержать параметр "transferFunds",
-parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the shortcut from the 
+равный "4000", затем его же, но со значением "CONFIRM". После того как сообщение отобразится на экране, браузер любого
-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.
 <!-- Stop Instructions -->
 

src/main/webapp/lesson_plans/ru/CsrfTokenByPass.html

@@ -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>
+<p><b>Тема для изучения:</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.
+На данном уроке вы научитесь осуществлять 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 
+CSRF-атаки заставляют браузер жертвы осуществлять необходимые злоумышленнику запросы
-loading a page that contains a 'forged request' to execute commands with the 
+к целевому серверу в невидимом режиме. Это позволяет атакующему вызывать выполнение различных операций
-victim's credentials.  </p>
+от лица атакованного пользователя с его правами и привилегиями.</p>
 
-<p>Token-based request authentication mitigates these attacks.  This technique 
+<p>Аутентификация запросов принимаемых от посетителей, основанная на уникальных токенах, предотвращает
-inserts tokens into pages that issue requests.  These tokens are required to 
+возможность CSRF-нападений. При использовании данной техники, при отправке важного запроса, серверу
-complete a request, and help verify that requests are not scripted.  CSRFGuard from OWASP uses 
+передаётся уникальный для каждого клиента токен, наличие которого подтверждает его легитимность.
-this technique to help prevent CSRF attacks.</p>
+Проект OWASP CSRFGuard как раз использует такой подход, позволяя защитить приложения от CSRF-нападений.
+</p>
 
-<p>However, this technique can be by-passed if CSS vulnerabilities exist on the same site.  
+<p>
-Because of the same-origin browser policy, pages from the same domain can read content from 
+Тем не менее, данный вид защиты можно обойти. Для этого достаточно обнаружить на атакуемом сайте XSS-уязвимость.
-other pages from the same domain.  </p>
+Её наличие поможет отправлять запросы от имени жертвы, ведь системы безопасности всех браузеров,
+основанных на политике одного источника, не запрещают обращаться к текущему домену.
+</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 
+которой расположена форма перевода денег. Для того чтоб увидеть форму, необходимо к текущему URL
-transfer funds page is the same as this lesson with an extra parameter "transferFunds=main". Load 
+дописать параметр "transferFunds=main". Загрузите эту страницу, считайте оттуда значение токена и осуществите перевод.
-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.
+появится зелёная отметка.
 <!-- Stop Instructions -->
 
-
+

src/main/webapp/lesson_plans/ru/DBCrossSiteScripting.html

@@ -1,24 +1,21 @@
 <div align="Center">
-<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting
+<p><b>Название урока:</b> Как проводить атаки межсайтового скриптинга (XSS)</p>
-(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
+XSS также может возникнуть когда введённая пользователем информация сразу же,
-response. In a reflected XSS attack, an attacker can craft a URL with
+без всяческих проверок, помещается в HTTP-запрос, но не сохраняется внутри приложения 
-the attack script and post it to another website, email it, or otherwise
+(отражаемые XSS). В таких случаях нападающий может сформировать URL, содержащий в себе 
-get a victim to click on it.
+вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
 <!-- Stop Instructions -->
-<p><b>General Goal(s):</b></p>
+<p><b>Основные цели:</b></p>
-For this exercise, you will perform a stored XSS attack.
+В данном упражнении вы научитесь осуществлять хранимые XSS-атаки.
-You will also implement code changes in the database to defeat
+В конце урока вам необходимо будет внести изменения в код базы данных для того, чтоб предотвратить подобые нападения.
-these attacks.
 <br>
 

src/main/webapp/lesson_plans/ru/HttpOnly.html

@@ -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
+Для того чтоб помешать проведению XSS-нападений компания Microsoft
-introduced a new cookie attribute entitled 'HttpOnly.' If this flag is
+ввела новый параметр для cookies, называемый 'HttpOnly'. Если данный флаг
-set, then the browser should not allow client-side script to access the
+активен, то браузер не разрешает работающим на стороне клиента скриптам
-cookie. Since the attribute is relatively new, several browsers neglect
+получать доступ к cookies. Некоторые браузеры, к сожалению, не учитывают
-to handle the new attribute properly.
+наличие 'HttpOnly' в своей работе. 
-<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>Список браузеров поддерживающих данный параметр можно найти здесь: <a href=http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly>OWASP HTTPOnly Support</a>
-<p><b>General Goal(s):</b></p>
+<p><b>Основные цели и задачи:</b></p>
-The purpose of this lesson is to test whether your browser supports the
+На данном уроке вы должны проверить, поддерживает ли ваш браузер флаг HTTPOnly применив его к
-HTTPOnly cookie flag. Note the value of the
+cookies с именем <strong>unique2u</strong>.
-<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.
 <br />
 <br />
-With the HTTPOnly attribute turned on, type
+Когда вы включите HTTPOnly, находясь на странице, cookies домена которой он защищает,
-"javascript:alert(document.cookie)" in the browser address bar. Notice
+впишите в адресную строку выражение "javascript:alert(document.cookie)". Вы увидите табличку со всеми
-all cookies are displayed except the unique2u cookie.
+cookies кроме unique2u.
 <!-- Stop Instructions -->

src/main/webapp/lesson_plans/ru/Phishing.html

@@ -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. 
+XSS-уязвимости возникают в том случае, когда непроверенные пользовательские данные
- With the help of XSS you can do a Phishing Attack and add content to a page
+возвращаются ему же в HTTP-ответе. С использованием XSS-уязвимостей вы можете совершать
- which looks official. It is very hard for a victim to determinate
+фишинг-атаки или же просто добавлять на уязвимую страницу какое-нибудь стороннее содержимое.
- that the content is malicious.
+В таких ситуациях посетителям-жертвам очень трудно отделить настоящую информацию на сайте от
+поддельной.
 <!-- Stop Instructions -->
-<p><b>General Goal(s):</b> </p>
+<p><b>Основные цели и задачи:</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
+http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName
 

src/main/webapp/lesson_plans/ru/ReflectedXSS.html

@@ -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. 
+XSS-уязвимости могут возникать в тех случаях, когда непроверенные пользовательские
- In a reflected XSS attack, an attacker can craft a URL with the attack 
+данные сразу помещаются в HTTP-ответ. В таких случаях нападающий может сформировать URL, содержащий в себе
- script and post it to another website, email it, or otherwise get a 
+вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
- victim to click on it. 
 <!-- Stop Instructions -->
-<p><b>General Goal(s):</b> </p>
+<p><b>Основные цели и задачи:</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.
+В этом упражнении вашей целью является отправка серверу специально сформированного
+вредоносного сообщения, которое, отобразившись в ответной странице,осуществит
+какие-нибудь опасные действия (например выполнит произвольный JS-код).

src/main/webapp/lesson_plans/ru/StoredXss.html

@@ -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>
+<p><b>Основные цели и задачи:</b> </p>
-The user should be able to add message content that cause another user to load an undesireable page or content.
+Вы должны добавить такое сообщение, которое при просмотре другим пользователем будет формировать
+на данной странице поддельное содержимое.

src/main/webapp/lesson_plans/ru/TraceXSS.html

@@ -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 -->