Translated plans for chapter "Session Management Flaws"

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

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

@@ -1,33 +1,31 @@
 <div align="Center"> 
-<p><b>Lesson Plan Title:</b> Session Fixation</p>
+<p><b>Название урока:</b> Закрепление сессии</p>
  </div>
  
-<p><b>Concept / Topic To Teach:</b> </p>
-How to steal a session with a 'Session Fixation'
+<p><b>Тема для изучения:</b> </p>
+Использование атак класса 'Закрепление сессии'
  <br> 
 <div align="Left"> 
 <p>
-<b>How the attacks works:</b>
+<b>Как работает данный вид атак:</b>
 </p>
-A user is recognized by the server by an unique Session ID. If a
-user has logged in and is authorized he does not have to 
-reauthorize when he revisits the application as the user is recognized
-by the Session ID. In some applications it is possible to deliver
-the Session ID in the Get-Request. Here is where the attack starts.
+Сервер может опознать конкретного пользователя по уникальному идентификатору сессии.
+Это позволяет клиентам проходить поцедуру авторизации всего 1 раз, а затем уже обращаться к
+приложению как авторизированное лицо. В некоторых приложениях идентификатор сессии
+передаётся в ссылках, в качестве одного из параметров GET-запроса. Здесь и начинаются главные проблемы.
 <br><br>
-An attacker can send a hyperlink to a victim with a chosen Session ID.
-This can be done for example by a prepared mail which looks like an 
-official mail from the application administrator.
-If the victim clicks on the link and logs in he is authorized
-by the Session ID the attacker has chosen. The attacker
-can visit the page with the same ID and is recognized as the victim and
-gets logged in without authorization.
+Атакующий может послать жертве гипер-ссылку содеращую в себе любой
+идентификатор сессии. Это может быть сделано, например, через почтовое
+сообщение, которое выглядит как обращение администрации сайта.
+Когда жертва, кликнув по ней, попадёт на сайт и пройдёт авторизацию, то идентификатор сессии, выбранный
+злоумышленником, станет идентификатором авторизованного пользователя-жертвы.
+Атакующий может пройти по любой ссылке передав серверу этот же идентификатор,
+и сможет действовать от чужого имени.
 </div>
-<p><b>General Goal(s):</b> </p>
+<p><b>Основные цели и задачи:</b> </p>
 <!-- Start Instructions -->
-This lesson has several stages. You play the attacker but also the victim.
-After having done this lesson it should be understood how
-a Session Fixation in general works. It should be also understood that
-it is a bad idea to use the Get-Request for Session IDs.
+Урок имеет несколько стадий. Вы играете роль и атакующего и жертвы.
+К концу урока вы поймёте что передача идентификаторов сессий в ссылках
+является очень плохой практикой.
 <!-- Stop Instructions -->
 

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

@@ -1,12 +1,19 @@
 <div align="Center"> 
-<p><b>Lesson Plan Title:</b> How to Spoof an Authentication Cookie </p>
+<p><b>Название урока:</b> How to Spoof an Authentication Cookie </p>
  </div>
  
-<p><b>Concept / Topic To Teach:</b> </p>
-
-Many applications will automatically log a user into their site if the right authentication cookie is specified. &nbsp; Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. &nbsp;Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. &nbsp;Some times the cookies maybe intercepted using Cross site scripting. &nbsp;This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.<br>
-<p><b>General Goal(s):</b> </p>
+<p><b>Тема для изучения:</b> </p>
+Многие сайты автоматически аутентифицируют пользователя если он имеет особые cookies.
+Иногда содержимое таких cookies может быть угадано если злоумышленник вычислил алгоритм их генерации.
+В других случаях cookies могут быть перехвачены, украдены через уязвимости в приложении (например через XSS)
+или системе пользователя. На этом уроке вы ознакомитесь с использованием таких cookies и
+попытаетесь обойти систему аутентификации основанную на них.
+<br>
+<p><b>Основные цели и задачи:</b> </p>
 <!-- Start Instructions -->
- The user should be able to bypass the authentication check.
-Login using the webgoat/webgoat account to see what happens. You may also try aspect/aspect. When you understand the authentication cookie, try changing your identity to alice.
+Пользователь должен обойти механизм проверки аутентификации.
+Войдите под аккаунтом webgoat/webgoat и посмотрите что получится.
+Вы также можете попробовать данные aspect/aspect. Как только вы поймёте
+как можно аутентифицироваться под другими именами, попробуйте войти под
+логином alice.
 <!-- Stop Instructions -->

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

@@ -1,9 +1,12 @@
 <div align="Center">
-<p><b>Lesson Plan Title:</b> How to Hijack a Session</p>
+<p><b>Название урока:</b> Похищение сессии</p>
 </div>
-<p><b>Concept / Topic To Teach:</b> </p>
+<p><b>Тема для изучения:</b> </p>
 <!-- Start Instructions -->
-Application developers who develop their own session IDs frequently forget to incorporate the complexity and randomness necessary for security. If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks.
-<p><b>General Goal(s):</b> </p>
-Try to access an authenticated session belonging to someone else.
+Разработчики приложений, создающие свои механизмы работы с сессиями, иногда
+забывают о том что идентификаторы сессий должны генерироваться случайным образом
+и иметь достаточную длинну. Иначе они могут быть банально подобраны злоумышленником
+методом грубой силы (brute force).
+<p><b>Основные цели:</b> </p>
+Попробуйте подобрать идентификатор рабочей сессии принадлежащей другому пользователю.
 <!-- Stop Instructions -->