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>
+<p><b>Тема для изучения:</b> </p>
-How to steal a session with a 'Session Fixation'
+Использование атак класса 'Закрепление сессии'
  <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 
+Это позволяет клиентам проходить поцедуру авторизации всего 1 раз, а затем уже обращаться к
-reauthorize when he revisits the application as the user is recognized
+приложению как авторизированное лицо. В некоторых приложениях идентификатор сессии
-by the Session ID. In some applications it is possible to deliver
+передаётся в ссылках, в качестве одного из параметров GET-запроса. Здесь и начинаются главные проблемы.
-the Session ID in the Get-Request. Here is where the attack starts.
 <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>
+<p><b>Тема для изучения:</b> </p>
-
+Многие сайты автоматически аутентифицируют пользователя если он имеет особые cookies.
-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>
+Иногда содержимое таких cookies может быть угадано если злоумышленник вычислил алгоритм их генерации.
-<p><b>General Goal(s):</b> </p>
+В других случаях 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 -->