-Welcome to a short introduction to WebGoat.
-Here you will learn how to use WebGoat and additional tools for the lessons.
+Добро пожаловать в краткую инструкцию по работе с WebGoat.
+Здесь вы научитель использовать сам WebGoat, а также инструменты, необходимые для некоторых уроков.
-WebGoat uses the Apache Tomcat server. It is configured to run on localhost although this can be -easily changed. This -configuration is for single user, additional users can be added in the tomcat-users.xml file. -If you want to use WebGoat in a laboratory or in -class you might need to change this setup. Please refer to the Tomcat Configuration -in the Introduction section.
+WebGoat работает под управлением Apache Tomcat. По умолчанию он настроен на работу на хосте localhost, +однако в случае необходимости имя хоста может быть легко изменено. +Кроме того, по умолчанию WebGoat настроен на работу лишь с одним пользователем. Дополнительные учётные записи +вы можете добавить в файле tomcat-users.xml. +Если вы хотите использовать WebGoat в лаборатории или классе вам обязательно нужно изменить его базовую конфигурацию. +Для этого пройдите в раздел "Введение" и прочтите главу "Настройка Tomcat" + -
-1. These are Lesson Categories in WebGoat. Click on a Category to see all Lessons in it.
-2. This will show technical hints to solve the lesson.
-3. This will show the HTTP Request Parameters
-4. This will show the HTTP Request Cookies
-5. This will show goals and objectives of the lesson.
-6. This will show the underlying Java source code.
-7. This will show the complete solution of the selected lesson.
-8. If you want to restart a lesson you can use this link.
-Always start with the lessons plan. Then try to solve the lesson and if necessary, -use the hints. The last hint is the solution text if applicable. If you cannot solve the lesson using the hints, you may view the -solution for complete details.
-
-To read and edit Parameters you need a local proxy to intercept the HTTP request.
-Here we use WebScarab. More information on WebScarab can be found in the "Useful Tools" Chapter.
-After installing WebScarab and configuring your browser to use it as proxy on localhost we can start.
+Для чтения и редактирования параметров вам необходимо иметь локальный прокси-сервер способный перехватывать
+HTTP-запросы. Здесь вы можете использовать WebScarab. Более подробную информацию о нём вы можете получить в разделе
+"Используемые инструменты". После установки WebScarab и настройки браузера на работу с ним можно начинать прохождение уроков.
+
-We have to select "Intercept Request" in the tab "Intercept". If we send a HTTP request we get a new WebScarab window.
+Мы ставим галочку в поле "Intercept Request" на закладке "Intercept". Если мы сейчас пошлём из браузера какой-либо запрос, то сразу
+же появится новое окно WebScarab.
-Here we can read and edit the intercepted parameter. After "Accept changes" the request will be sent to the server.
+Здесь мы можем смотреть и редактировать перехватываемые параметры. После нажатия "Accept Changes" запрос пойдёт дальше на сервер.
-Often it is not only necessary to change the value of the parameters but to change the value of cookies.
-We can use WebScarab to intercept the request and change cookies values just like parameter data as explained in the last topic.
+Почти всегда редактирование Cookies происходит точно также как и редактирование параметров запроса.
+Мы можем использовать WebScarab для перехвата запроса и изменения значений имеющихся в нём Cookies
+точно также как описывалось выше.
+
-We get a new window on sending a HTTP request. On the screenshot you see where we can find cookies and how to edit the values of them.
+При отправке нового запроса появится уже знакомое окно. На скриншоте вы видите где может располагаться
+строка с Cookies и как можно редактировать её значение.
Lesson Plan Title: Http Basics
+Название урока: Основы Http
Concept / Topic To Teach:
- This lesson presents the basics for understanding the transfer of data between the browser and the web application.Тема изучения:
+В данном уроке представлены основы необходимые для понимания процесса передачи данных между браузером и веб-приложением.-How HTTP works: +Как работает HTTP:
-All HTTP transactions follow the same general format. Each client request and server response has three parts: the request or response line, a header section, and the entity body. The client initiates a transaction as follows:General Goal(s):
+Основные цели и задачи:
-Enter your name in the input field below and press "go" to submit. The server will accept the request, reverse the input, and display it back to the user, illustrating the basics of handling an HTTP request. +Введите ваше имя в поле расположенное ниже и нажмите "go" для отправки формы. Сервер примет ваш запрос, выстроит +полученную строку в обратном порядке и выведет результат на экран. Данный пример иллюстрирует основы обработки данных +полученных из HTTP-запроса.Lesson Plan Title: How to Perform HTTP Splitting
+Название урока: Проводение атак HTTP Splitting
Concept / Topic To Teach:
- This lesson teaches how to perform HTTP Splitting attacks. +Тема изучения:
+На данном уроке вы ознакомитесь с атаками класса HTTP Splitting-How the attack works: +Как работают такие атаки:
-The attacker passes malicious code to the web server together with normal input. -A victim application will not be checking for CR (carriage return, also given by %0d or \r) -and LF (line feed, also given by %0a or \n) characters. These characters not only give attackers control -of the remaining headers and body of the response the application intends to send, -but they also allows them to create additional responses entirely under their control.
-The effect of an HTTP Splitting attack is maximized when accompanied with a Cache Poisoning. The goal of -Cache Poisoning attack is to poison the cache of the victim by fooling the cache into believing that the page -hijacked using the HTTP splitting is an authentic version of the server's copy.
-The attack works by using the HTTP Splitting attack plus adding the Last-Modified: header and setting it -to a future date. This forces the browser to send an incorrect If-Modified-Since request header on future requests. -Because of this, the server will always report that the (poisoned) page has not changed, and the victim's browser -will continue to display the attacked version of the page.
-A sample of a 304 response is: +
+ Атакующий посылает веб-серверу вредоносные данные вместе с ожидаемыми. Уязвимое приложение не проверяет полученную +информацию на наличие символов CR (возврат коретки, обозначается с помощью %0d или \r) и LF (перевод строки, обозначается +с помощью %0a или \n). Данные символы не только позволяют атакующему контролировать возвращаемые сервером заголовки и тело ответа, +но и дают ему возможность создавать поддельные ответы, содержимое которых будет ему полностью подконтрольно. +
++ Эффект от таких атак может усиливаться когда они проводятся вместе с атаками класса "Отравление кеша" (Cache Poisoning). +Смысл их в отравлении кеша жертвы по средствам подсовывания ей с помощью HTTP Splitting поддельной страницы, +пришедшей якобы от сервера. +
++Вместе с этим, с помощью уязвимостей позволяющих провести разбиение HTTP-ответа, злоумышленник может заставить сервер +отослать клиенту поддельный заголовок Last-Modified: с датой из будущего. От этого браузер клиента станет посылать серверу +неверное содержимое в заголовке If-Modified-Since. Сервер, в свою очередь, всегда будет отвечать клиенту что (отравленная) +страница не изменилась и клиент постоянно будет видеть страницу подсунутую злоумышленником. +
+Простой пример ответа с кодом 304:
HTTP/1.1 304 Not Modified
Date: Fri, 30 Dec 2005 17:32:47 GMT
General Goal(s):
+Основные цели и задачи:
-This lesson has two stages. Stage 1 teaches you how to do HTTP Splitting attacks while stage 2 builds on that to teach you how to elevate HTTP Splitting to Cache Poisoning.
-Enter a language for the system to search by. You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) and LF (%0a) characters to exploit the attack. Your goal should be to force the server to send a 200 OK. If the screen changed as an effect to your attack, just go back to the homepage. After stage 2 is exploited successfully, you will find the green check in the left menu.
+Данный урок имеет две стадии. На первой вы изучаете проведение атак HTTP Splitting, а на второй научитесь совмещать +их с отравлением кеша.
++Введите любой язык в форму поиска. После отправки формы приложение осуществит переадресацию на другую ссылку, +расположенную на этом же сервере. С помощью помещения CR (%0d) и LF (%0a) в название языка вы должны изучить проведение атак +данного типа. +Ваша цель состоит в том, чтоб заставить сервер отправить ответ 200 ОК. Если содержимое экрана изменится от вашей атаки, +просто перейдите на главную страницу. Как только шаг 2 будет выполнен успешно вы увидите что в левом меню появилась новая +зелёная отметка на против этого раздела. +
diff --git a/src/main/webapp/lesson_plans/ru/NewLesson.html b/src/main/webapp/lesson_plans/ru/NewLesson.html index 234b170d8..04197bd54 100644 --- a/src/main/webapp/lesson_plans/ru/NewLesson.html +++ b/src/main/webapp/lesson_plans/ru/NewLesson.html @@ -1,13 +1,13 @@ -
-Adding lessons to WebGoat is very easy. If you have an idea that would be suitable
-for a new lesson, follow these few simple instructions to implement it:
-* Download the source code from here.
-* Setup framework: follow the simple instructions in "HOW TO create the WebGoat workspace.txt" that comes with the project.
-* You need to add two files for each new lesson:
- - YourLesson.java to org.owasp.webgoat.lessons
- - YourLesson.html to WebContent/lesson_plans
WebGoat comes with default configurations for Tomcat. This page will explain these configurations -and other possible configurations for Tomcat. This is just -a short description which should be enough in most cases. For more advanced tasks please -refer to the Tomcat documentation. Please note that all solutions -are written for the standard configurations on port 80. If you use another port you have -to adjust the solution to your configuration.
- -There are two standard Tomcat configurations. In the basic configurations you use the server on your localhost. - Both are identically with the only difference - that in one tomcat is running on port 80 and 443 (SSL) and in the other tomcat is running on port 8080 and 8443. In Linux you have - to start WebGoat as root or with sudo if you want to run it on port 80 and - 443. - As running software as root is dangerous we strongly advice to use -the port 8080 and 8443. In Windows you can -run WebGoat.bat to run it on port 80 and WebGoat_8080.bat to run it on port 8080. In Linux you -can use webgoat.sh and run it with webgoat.sh start80 or webgoat.sh start8080. The user in these -configurations is guest with password guest +
WebGoat распространяется с конфигурацией Tomcat по умолчанию. На данной странице вы найдёте её короткое описание и +список возможных вариантов различных настроек. В случаях когда данное описание вам не помогает обращайтесь к официальной +документации Tomcat. +Кроме того, нужно сказать что всё нижеописанное относится к стандартной конфигурации сервера работающего на 80-ом порту. +Если вы используете для сервера другой порт, то вам необходимо будет изменить конфигурацию соответствующим образом.
--If you are a single user of WebGoat the standard configurations should be -enough but if you want to use WebGoat in laboratory or in class there -might be the need to change the configurations. Before changing -the configurations we recommend doing a backup of the files you change. +
Здесь имеется две стандартных конфигурации Tomcat. При их использовании доступ к серверу можно получить обращаясь к хосту localhost. +Они полностью идентичны, за исключением того что в первом случае сервисы Tomcat запускаются на портах 80 и 443 (SSL), а во втором - +на портах 8080 и 8443. В Linux вы должны запустить WebGoat как root или с использованием sudo если хотите чтоб он работал на портах +80 и 443. +Помните, что запуск ПО из под root`а очень опасное занятие, поэтому мы настоятельно рекомендуем использовать порты 8080 и 8443. +В Windows вы можете запустить WebGoat.bat для работы на 80-ом порту, или же WebGoat_8080.bat для работы на порту 8080. +В Linux ту же самую работу выполняет скрипт WebGoat.sh и для того же результата его необходимо запустить либо командой +"webgoat.sh start80", либо "webgoat.sh start8080". Пользователь, для доступа к приложению, +в стандартной конфигурации - guest с паролем guest.
--To change the ports open the server_80.xml which you find in tomcat/conf and change the -non-SSL port. If you want to use it on port 8079 for example: +Если вы единственный кто будет использовать WebGoat, то стандартной конфигурации вам +будет вполне достаточно. Если же вы будете запускать его в лаборатории или классе, то конфигурацию +нужно будет менять. Перед этим советуем вам сделать её резервную копию. +
+ ++ Для изменения портов откройте файл server_80.xml, котрый можно найти в tomcat/conf, и измените + не-SSL порт. Например, если вы хотите использовать порт 8079:
@@ -40,8 +38,7 @@ non-SSL port. If you want to use it on port 8079 for example: <Connector address="127.0.0.1" port="8079"...
-You can also change the SSL connector to another port of course. -In this example to port 8442: +Конечно же вы можете изменить и порт SSL-соединения. Вот пример переноса SSL на порт 8442:
<!-- Define a SSL HTTP/1.1 Connector on port 8442 --> @@ -49,38 +46,37 @@ In this example to port 8442:
THIS MAKES IT POSSIBLE TO REALLY ATTACK YOUR SERVER! DO NOT DO THIS - UNTIL YOU KNOW WHAT YOU ARE DOING. THIS CONFIGURATION SHOULD BE ONLY USED IN -SAFE NETWORKS!
-By its default configurations WebGoat is only -reachable within the localhost. In a laboratory or a class -there is maybe the need of having a server and a few clients. -In this case it is possible to make WebGoat reachable. +
ЭТО ОТКРЫВАЕТ ВАШ СЕРВЕР ДЛЯ РЕАЛЬНЫХ АТАК ИЗ ВНЕ! НЕ ДЕЛАЙТЕ ЭТОГО ЕСЛИ ВЫ НА 100% + НЕ УВЕРЕНЫ В НЕОБХОДИМОСТИ ДАННОГО ШАГА. ЭТА КОНФИГУРАЦИЯ МОЖЕТ БЫТЬ ИСПОЛЬЗОВАНА ТОЛЬКО + В ДОВЕРЕННЫХ СЕТЯХ. +
+По умолчанию WebGoat доступен только при обращении к хосту localhost. В лаборатории или классе +у вас может возникнуть необходимость организовать сервер с множеством клиентов. В данном случае +вы можете настроить WebGoat соответствующим образом. +
+Причина того что WebGoat доступен только на localhost - параметр address тега Connector в файле server_80.xml. + Изначально его значение установлено в 127.0.0.1 . При запуске приложение начинает проверять прописанные в настройках порты + только на этом адресе и принимает соединения если они появляются. Если вы удалите данный параметр, то приложение + начнёт прослушивать соответствующие порты на всех доступных IP-адресах.
-The reason why WebGoat is only reachable within the localhost is -the parameter address in the connectors for the non-SSL and SSL connection in server_80.xml. It is set -to 127.0.0.1. The applications only listens on the port of this address for -incoming connections if it is set. If you remove this parameter the server listens on all IPs on the -specific port.
--If you have made WebGoat reachable it is reachable for -all clients. If you want to make it reachable only for certain clients specified -by there IP you can archive this by using a 'Remote Address Filter'. -The filter can be set in a whitebox or blackbox approach. Here is -only discussed the whitebox approach. You have to add following lines to the Host section of web_80.xml: +Выше описывался способ разрешения соединений с WebGoat для любых клиентов. +Если вы хотите разрешить доступ к приложению только с определённых адресов, воспользуйтесь +фильтром удалённых адресов (Remote Address Filter). Для этого добавьте следующюю строку +в файл web_80.xml:
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1,ip1,ip2"/>-
In this case only localhost, ip1 and ip2 are permitted to connect.
+В этом случае только localhost, ip1 и ip2 смогут устанавливать соединения с сервером.
-
-WebGoat requires the following users and roles to be configured in order for the application to run.
+WebGoat`у для нормальной работы необходимо наличие следующих пользователей и ролей:
>role rolename="webgoat_basic"/< @@ -91,19 +87,19 @@ WebGoat requires the following users and roles to be configured in order for the >user username="guest" password="guest" roles="webgoat_user"/<-
-Usually using WebGoat you just use the user guest with the password guest. -But maybe in laboratory you have made a setup with one server and a lot of -clients. In this case you might want to have a user for every client - and you have to alter tomcat-users.xml -in tomcat/conf as the users are stored there. We recommend not to use real passwords -as the passwords are stored in plain text in this file! +Обычно для нормальной работы с WebGoat вам достаточно будет пользователя guest с паролем guest. +Но когда вы развернёте его в лоборатории или классе может возникнуть необходимость создания отдельного +пользователя для каждого клиента. Для этого вам необходимо изменить файл tomcat-users.xml, которых находится в tomcat/conf. +Мы настоятельно не рекомендуем хранить реальные действующие пароли в данном файле т.к. +там они прописываются в виде простого текста!
--Adding a user is straight forward. You can use the guest entry as an example. The added -users should have the same role as the guest user. Add lines like this to the file: + Процедура добавления пользователя очень проста. В качестве наглядного примера вы можете использовать + строку с пользователем guest. Помните что каждый вновь добавляемый пользователь должен иметь определённую роль. + Для добавления новых аккаунтов впишите в вышеуказанный файл строки типа этих:
<user name="student1" password="password1" roles="webgoat_user"/> diff --git a/src/main/webapp/lesson_plans/ru/UsefulTools.html b/src/main/webapp/lesson_plans/ru/UsefulTools.html index e69db2dce..74bfe257d 100644 --- a/src/main/webapp/lesson_plans/ru/UsefulTools.html +++ b/src/main/webapp/lesson_plans/ru/UsefulTools.html @@ -1,42 +1,44 @@ -Useful Tools
+Используемые инструменты
-Below is a list of tools we've found useful in solving the WebGoat lessons. You will need WebScarab or Paros to solve most of the lessons.
+Ниже находится список инструментов, которые, по нашему мнению, могут вам пригодиться при прохождении уроков WebGoat. +Для выполнения большинства заданий вам понадобится WebScarab или Paros.WebScarab:
-Like WebGoat, WebScarab is a part of OWASP. -WebScarab is a proxy for analyzing applications that -communicate using the HTTP and HTTPS protocols. Because WebScarab -operates as an intercepting proxy, we can review and modify requests -and responses.
+Как и WebGoat, WebScarab - это часть OWASP. Он представляет из себя прокси-сервер +для исследования приложений использующих протоколы HTTP и HTTPS. Так как WebScarab +является перехватывающим прокси-сервером, то мы с его помощью можем просматривать и изменять +содержимое запросов и ответов на них. +
-Webpage:http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project +Его страничка:http://www.owasp.org/index.php/Category:OWASP_WebScarab_ProjectFirebug:
-Firebug is an add-on for the Firefox browser. We can use it to inspect, edit and monitor CSS, HTML and JavaScript.
+Firebug - это дополнение к браузеру Firefox. Мы можем использовать его для проверки, редактирования и мониторинга CSS, HTML и JavaScript.
-Webpage:http://www.getfirebug.com +Его страничка:http://www.getfirebug.com
IEWatch:
-IEWatch is a tool to analyze HTTP and HTML for users of the Internet Explorer.
+IEWatch - это утилита для анализа HTTP и HTML для пользователей Internet Explorer.
-Webpage:http://www.iewatch.com +Её страничка:http://www.iewatch.comWireshark
-Wireshark is a network protocol analyzer. You can sniff network traffic and gather useful -informations this way.
-
+Wireshark - это анализатор сетевого трафика. С его помощью вы можете отлавливать сетевой трафик и получать из него интересную информацию.
-Webpage:http://www.wireshark.org +Его страничка:http://www.wireshark.orgScanner:
+Сканнер:
-There are many vulnerability scanners for your own web applications. They can find XSS, Injection Flaws and other vulnerabilities. Below are links to two open source scanner.
+В данный момент имеется большое количество сканеров для веб-приложений. Они могут находить XSS, инъективные и другие уязвимости. +Ниже представлены ссылки на два сканера с открытым исходным кодом. +
Nessus:http://www.nessus.org
Paros:http://www.parosproxy.org
