Restructured the baseline to remove extra src/main directory structure. Added eclipes project file

git-svn-id: http://webgoat.googlecode.com/svn/branches/webgoat-6.0@485 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
mayhew64@gmail.com
2012-11-19 23:57:51 +00:00
parent fb938e0933
commit 6a96547ef0
1204 changed files with 85 additions and 2 deletions

View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Название урока:</b> Использование матрицы контроля доступа</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
В схемах основанных на ролях сама роль представляет из себя набор разрешений доступа и привилегий.
Пользователю одновременно может быть присвоена одна или более ролей.
Подобные схемы чаще всего включают в себя два механизма: механизм работы с разрешениями доступа и
механизм назначения привилегий. В случаях когда реализация данной схемы имеет какие-то изъяны пользователь может получить
доступ к функционалу, к которому ему обращаться не разрешено. Или он может каким-либо образом повысить свои
привилегии в приложении.
<p><b>Основные цели и задачи:</b> </p>
Каждый пользователь имеет свою роль(и), наличие которой позволяет ему получать доступ к строго определённым ресурсам.
Вашей целью является изучение механизма разграничения доступа на данном сайте и поиск в нём изъянов.
Только пользователи из группы [Admin] должны иметь доступ к разделу управления аккаунтами.
<!-- Stop Instructions -->

View File

@ -0,0 +1,23 @@
<div align="Center">
<p><b>Название урока:</b> Как осуществляется помещение вредоносных конструкций в БД.</p>
</div>
<p><b>Тема для изучения:</b> </p>
Помещение вредоносных конструкций в БД
<br>
<div align="Left">
<p>
<b>Как работает данный вид атаки:</b>
</p>
База данных обычно используется как backend веб-приложений в качестве хранилища важных данных. В процессе атаки злоумышленник
может помещать в неё различные вредоносные конструкции, например опасные триггеры. Триггеры вызываются
каждый раз при выполнении базой определённой операции (выборка, вставка, обновление данных и т.д.). Например атакующий
может создать триггер который будет у всех регистрирующихся пользователей менять почтовые адреса на подконтрольный ему email.
</div>
<p><b>Основная цель(и):</b> </p>
<!-- Start Instructions -->
* Вы должны понять как с помощью эксплуатации уязвимого запроса создать триггер
* У вас не получится создать в данном приложении настоящий вредоносный триггер т.к. БД используемая WebGoat`ом не поддерживает триггеров.
* Ваш ID для входа - 101.
<!-- Stop Instructions -->

View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Название урока:</b> Основная аутентификация </p>
</div>
<p><b>Тема для изучения:</b></p>
<!-- Start Instructions -->
Основная аутентификация используется для защиты ресурсов расположенных на стороне сервера.
При получении запроса от пользователя веб-сервер отправляет ему ответ с кодом 401.
Получив его браузер запрашивает у пользователя логин и пароль в специальном диалоговом окне. После
ввода браузер кодирует полученные данные по алгоритму base64 и отсылает веб-серверу.
Последний, в свою очередь, проверяет полученную информацию и, если всё правильно, отдаёт клиенту запрашиваемый
документ. Указанные пользователем данные далее автоматически отсылаются браузером при каждом обращении к
защищённым ресурсам.
<p><b>Основная цель(и):</b></p>
На этом уроке вашей целью является понимание механизмов основной аутентификации и ответ на вопросы которые находятся ниже.
<!-- Stop Instructions -->

View File

@ -0,0 +1,25 @@
<div align="Center">
<p><b>Название темы:</b> Использование слепых SQL-инъекций </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
SQL-инъекции представляют серьёзную опасность для сайтов, чья работа основывается на БД.
Методы осуществления таких атак очень просты в освоении и ущерб наносимый ими нельзя недооценивать т.к. злоумышленник
с их помощью в некоторых случаях может добиться полной компрометации системы.
Несмотря на всю опасность SQL-инъекций каждый день появляется множество уязвимых к ним веб-приложений.
<br>
На самом деле сейчас опасность данного вида уязвимостей сильно преувеличивают. Есть множество способов благодаря которым
любой разработчик практически полностью может защитить своё приложение от них.
Вообще проверка всех входящих данных является очень хорошей практикой не только при работе с БД, но и
в случаях с выполнением команд ОС, скриптов и т.д.
<br>
<!-- Stop Instructions -->
<p><b>Главная цель(и):</b> </p>
Форма, расположенная ниже, позволяет пользователю вводить номер аккаунта и проверять действителен он или нет.
Воспользуйтесь данной формой для того чтоб через уязвимость на стороне сервера получить
возможность извлекать произвольные данные из БД.
<br><br>Ascii-значения символов которые могут вам понадобиться: 'A' = 65 'Z' = 90 'a' = 97 'z' = 122
<br><br>Целью является получение содержимого поля first_name в таблице user_data для записи с номером 15613.
Поместите его имя в эту форму для того чтоб закончить урок.

View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Название урока:</b> Эксплуатация уязвимостей переполнения буффера</p>
</div>
<!-- Start Instructions -->
<p><b>Тема для изучения:</b> </p>
Как проводить эксплуатацию уязвимостей переполнения буффера.
<p><b>Основные цели и задачи:</b> </p>
Для данного урока требуется автор.
<!-- Stop Instructions -->

View File

@ -0,0 +1,40 @@
<div align="Center">
<p><b>Название урока:</b> Проведение атак межсайтовой подделки запросов. </p>
</div>
<p><b>Тема для изучения:</b> </p>
На данном уроке вы научитесь использовать уязвимости межсайтовой подделки запросов (CSRF).
<br>
<div align="Left">
<p>
<b>Как работает данный тип атак:</b>
</p>
При проведении атак межсайтовой подделки запросов жертву заставляют каким-либо образом
загрузить страницу содержащую опасную картинку, типа той что представлена ниже:
<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>
Когда браузер жертвы обрабатывает такую страницу, он автоматически совершает обращение
к сайту www.mybank.com, к скрипту transferFunds.do передавая необходимый злоумышленнику параметр.
Браузер будет думать что это простое изображение, тогда как на самом деле обращение к этому
адресу вызовет перевод денег.
Вместе с запросом, уходящим на сайт банка, будут переданы и cookies клиента. Следовательно,
если в этот момент пользователь будет авторизирован на www.mybank.com, и в его cookies будет хранится
идентификатор активной сессии, скрипт transferFunds.do примет этот запрос за легитимный и
совершит необходимую злоумышленнику операцию.
Таким образом, атакующий может производить практически все действия, которые способен делать
настоящий пользователь.
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
Ваша цель - послать в новостную группу письмо, содержащее в себе изображение со
специально сформированным адресом. Картинка должна иметь размер 1*1px и производить
CSRF-атаку, заставляя браузер обращаться к текущей странице, но с дополнительным параметром
в URL - "transferFunds=4000". Когда вы отошлёте сообщение и оно отобразится на экране,
браузер автоматически осуществит необходимый запрос. Как только вы решили что выполнили это задание
просто обновите страницу. Если всё сделано верно, то в главном меню, на против соответствующего урока,
появится зелёная отметка.
<!-- Stop Instructions -->

View File

@ -0,0 +1,7 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Putting it all together </p>
</div><br/>
<p><b>Concept / Topic To Teach:</b></p>
This lesson creates a challenge that will help the student apply all that they have learned.<br/>
<b>General Goal(s):</b><br/>
Display the secret message.

View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Название урока: </b>Фильтрация данных на стороне клиента</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Всегда считается хорошей практикой отправлять на сторону клиента только ту информацию, доступ к которой он имеет.
В данном уроке на сторону клиента будет отправлено очень много информации, что создаст серьёзные проблемы с контролем доступа к ней.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Ваша цель состоит в том, чтоб среди принимаемых со стороны сервера данных найти ту
информацию, доступа к которой у вас нет.

View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Название урока: </b>Insecure Client Storage</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Хорошей практикой является проверка на стороне сервера абсолютно всех принимаемых данных.
Реализация механизмов проверки только на стороне клиента делает приложение уязвимым.
Запомните, всё что отправляется на сторону клиента не должно содержать критически важных
данных или механизмов.
<!-- Stop Instructions -->
<p><b>Основные цели:</b> </p>
В данном упражнении первая ваша задача - обнаружить действующий код купона обеспечивающего скидку.
Далее необходимо исследовать механизм проверки вводимых данных и добиться покупки товара за нулевую цену.

View File

@ -0,0 +1,18 @@
<div align="Center">
<p><b>Название урока:</b> Использование инъекций команд</p>
</div>
<p><b>Тема для изучения:</b></p>
<!-- Start Instructions -->
Атаки класса "Инъекция команд" представляют собой серьёзную угрозу для сайтов принимающих
от пользователей какие-либо данные. Методика их использования достаточно тривиальна, но в тоже
время они могут приводить к полной компрометации атакованной системы. Несмотря на это количество
приложений имеющих подобные уязвимости неуклонно растёт.<br/>
На самом деле подобные угрозы могут быть полностью устранены с помощью принятия разработчиками
простейших мер направленных на обеспечение безопасности приложения. В данном уроке
будет продемонстрированно множество примеров проведения инъекций через поступающие
из вне параметры.<br/>
Запомните что проверка всех получаемых от пользователя данных, особенно тех, которые будут использоваться
в командах ОС, скриптах или запросах к БД, является хорошей практикой<br/>
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b></p>
Попробуйте найти уязвимость через которую можно выполнить какую-нибудь команду операционной системы.

View File

@ -0,0 +1,31 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>План урока</title>
</head>
<body>
<div align="Center">
<p><b>Название урока:</b> Уязвимость при одновременной работе с товарной корзиной</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-приложения могут обрабатывать множество HTTP-запросов одновременно.
Часто разработчики используют конструкции не приспособленные к многопоточной работе, и
это создаёт возможность использования ошибок связанных с одновременными обращениями.
Например когда одна и та же страница открывается одновременно разными пользователями и один их них видит
на ней данные другого.
Под приспособленностью к многопоточной работе подразумевается способность полей классов и объектов
всегда находиться в верном состоянии при выполнении множества одних и тех же операций вызываемых
разными потоками. Поскольку все потоки используют одно и то же рабочее пространство вызываемых методов, и в данном
пространстве хранятся данные всех свойств отдельно взятых классов, то множественные одновременные попытки
обращений к ним могут привести к неожиданным результатам.<br>
<!-- Stop Instructions -->
<p><b>Основные цели:</b> </p>
Ваша цель - проэксплуатировать уязвимость этого типа для того чтоб получить возможность покупать товары по заниженной цене.
<br>
</body>
</html>

View File

@ -0,0 +1,21 @@
<div align="Center">
<p><b>Название урока:</b> Как проводить атаки межсайтового скриптинга (XSS)</p>
</div>
<p><b>Тема для изучения:</b></p>
<!-- Start Instructions -->
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
БД. Это важно и для тех данных, которые будут сохранены где-то
внутри приложения. Посетители не должны иметь возможность публикации на сайте
таких сообщений, которые могут изменять структуру страницы при их просмотре.
<br>
XSS также может возникнуть когда введённая пользователем информация сразу же,
без всяческих проверок, помещается в HTTP-запрос, но не сохраняется внутри приложения
(отражаемые XSS). В таких случаях нападающий может сформировать URL, содержащий в себе
вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b></p>
На данном уроке вы научитесь использовать хранимые и отражаемые XSS-уязвимости.
В конце вам придётся внести изменения в код приложения для устранения данных уязвимостей.
<br>

View File

@ -0,0 +1,31 @@
<div align="Center">
<p><b>Название урока:</b>CSRF, обход мезанизмов подтверждений</p><br/>
</div>
<p><b>Тема для изучения:</b> </p>
На данном уроке вы научитесь проводить CSRF-нападения в обход механизмов подтверждения операций.
<br>
<div align="Left">
<p>
<b>Как работает данный класс атак:</b>
<p>
CSRF является таким видом атак, при проведении которых браузер жертвы, без её ведома, отправляет
на целевой сайт запросы нужные злоумышленнику. Иногда, при проведении важных операций, сервер может
запросить у пользователя их подтверждение. Этот ход может показаться решением проблем связанных с CSRF,
но только не в случаях когда подтверждение реализовано средствами JavaScript. На данном уроке вы научитесь
обходить такие варианты подтверждений, как одиночных, так и многочисленных. Решением будет являться та же посылка
поддельных запросов, но уже не одного, а нескольких.
</p>
</div>
<p><b>Цели и задачи:</b> </p>
<!-- Start Instructions -->
Как и в прошлом уроке, вашей целью является отправка электронного письма в новостную группу. Письмо, при просмотре,
должно вызывать отправку нескольких поддельных запросов: первый на осуществление денежного перевода, второй на
его подтверждение. Сначала URL, по которому будет произведено обращение, должен содержать параметр "transferFunds",
равный "4000", затем его же, но со значением "CONFIRM". После того как сообщение отобразится на экране, браузер любого
кто его увидит сам сделает всё что нужно. В конце работы обновите текущую страницу. Если задание выполнено верно, то в
главном меню, на против этого урока, появится зелёная отметка.
<!-- Stop Instructions -->

View File

@ -0,0 +1,41 @@
<div align="Center">
<p><b>Название урока:</b>Обход CSRF-защиты основанной на токенах</p><br/>
</div>
<p><b>Тема для изучения:</b> </p>
На данном уроке вы научитесь осуществлять CSRF-нападения на сайты, использующие токены в качестве защиты
от CSRF-атак.
<br>
<div align="Left">
<p>
<b>Как работают эти атаки:</b>
</p>
<p>
CSRF-атаки заставляют браузер жертвы осуществлять необходимые злоумышленнику запросы
к целевому серверу в невидимом режиме. Это позволяет атакующему вызывать выполнение различных операций
от лица атакованного пользователя с его правами и привилегиями.</p>
<p>Аутентификация запросов принимаемых от посетителей, основанная на уникальных токенах, предотвращает
возможность CSRF-нападений. При использовании данной техники, при отправке важного запроса, серверу
передаётся уникальный для каждого клиента токен, наличие которого подтверждает его легитимность.
Проект OWASP CSRFGuard как раз использует такой подход, позволяя защитить приложения от CSRF-нападений.
</p>
<p>
Тем не менее, данный вид защиты можно обойти. Для этого достаточно обнаружить на атакуемом сайте XSS-уязвимость.
Её наличие поможет отправлять запросы от имени жертвы, ведь системы безопасности всех браузеров,
основанных на политике одного источника, не запрещают обращаться к текущему домену.
</p>
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
Как и в прошлом уроке, вашей целью является отправка письма в новостную группу для вызова нелегитимного
перевода денег. Для её достижения вам необходимо узнать действующий токен. Он находится в коде страницы на
которой расположена форма перевода денег. Для того чтоб увидеть форму, необходимо к текущему URL
дописать параметр "transferFunds=main". Загрузите эту страницу, считайте оттуда значение токена и осуществите перевод.
В конце работы обновите текущую страницу. Если задание выполнено верно, то в главном меню, на против этого урока,
появится зелёная отметка.
<!-- Stop Instructions -->

View File

@ -0,0 +1,21 @@
<div align="Center">
<p><b>Название урока:</b> Как проводить атаки межсайтового скриптинга (XSS)</p>
</div>
<p><b>Тема для изучения:</b></p>
<!-- Start Instructions -->
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
БД. Это важно и для тех данных, которые будут сохранены где-то
внутри приложения. Посетители не должны иметь возможность публикации на сайте
таких сообщений, которые могут изменять структуру страницы при их просмотре.
<br>
XSS также может возникнуть когда введённая пользователем информация сразу же,
без всяческих проверок, помещается в HTTP-запрос, но не сохраняется внутри приложения
(отражаемые XSS). В таких случаях нападающий может сформировать URL, содержащий в себе
вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
<!-- Stop Instructions -->
<p><b>Основные цели:</b></p>
В данном упражнении вы научитесь осуществлять хранимые XSS-атаки.
В конце урока вам необходимо будет внести изменения в код базы данных для того, чтоб предотвратить подобые нападения.
<br>

View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform SQL Injection</p>
</div>
<p><b>Concept / Topic To Teach:</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. Users should not be able to alter the intent of
commands that are executed on the server, in many cases as a privileged user.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform a SQL Injection attack.
You will also implement code changes in the database to defeat
these attacks.
<br>

View File

@ -0,0 +1,23 @@
<div align="Center">
<p><b>Название урока:</b> Выполнение атаки класса 'DOM-инъекция'. </p>
</div>
<p><b>Тема для изучения:</b> </p>
Выполнение атаки класса 'DOM-инъекция'.
<br>
<div align="Left">
<p>
<b>Как работают атаки данного вида:</b>
</p>
Некое приложение использует технологию AJAX для манипулирования DOM страницы и его обновления
по средствам JavaScript, DHTML и функции eval().<br>
В данном случае атакующий может каким-либо образом попытаться прехватить ответ сервера, и поместить
в него набор вредоносных JavaScript-команд.
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
* Ваша жертва - это система требующая от клиентов ключ активации для её использования.<br>
* Ваша задача состоит в том, чтоб каким-либо образом разблокировать кнопку активации.<br>
* Уделите немного времени просмотру HTML-кода страницы и вы поймёте как работает весь механизм активации.<br>
<!-- Stop Instructions -->

View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Название урока: </b>Межсайтовый скриптинг основанный на DOM (DOM XSS)</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Объектная модель документа (DOM), с точки зрения безопаности, создаёт собой одну интересную проблему.
Она позволяет содержимому веб-страниц динамически меняться, что само по себе является хорошей возможностью
не только для веб-мастеров, но и для злоумышленников. С её помощью нападающие могут помещать в код страниц
вредоносные вставки (XSS), если в процессе модификации их содержимого на стороне клиента не происходит
достаточной проверки данных вводимых пользователем.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
В данном упражнении вам необходимо с использованием этой уязвимости поместить вредоносный код
в объектную модель документа. А в самом конце вы исправите ошибку приводящую к её появлению.

View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Название урока:</b> Отказ в обслуживании при нескольких одновременных попытках авторизации</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Атаки класса "Отказ в обслуживании" являются главной проблемой веб-приложений. Ситуации, при которых конечный пользователь
долгое время не может получить доступ к важному приложению или сервису, могут принести большие убытки.
<p><b>Основные цели и задачи:</b> </p>
Данный сайт позволяет нескольким пользователям авторизироваться одновременно. В то же время
веб-приложение может устанавливать с БД только 2 соединения за раз. Вы должны получить
список существующих пользователей и попытаться одновременно произвести вход от 3 логинов.
<!-- Stop Instructions -->

View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Название урока: </b>Опасное использование eval()</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Хорошей практикой является проверка на стороне сервера всех принимаемых данных.
В случаях когда непроверенные пользовательские данные напрямую отражаются в HTTP-ответе имеется
риск появления XSS-уязвимостей. В текущем приложении не проходящие проверку пользовательские данные помещаются
в строку передаваемую функции eval(). В подобных ситуациях (они называются отражёнными XSS-уязвимостями)
злоумышленник может составить URL содержащий специальные вредоносные вставки, и опубликовать его
на стороннем веб-сайте, отправить по почте или любым другим способом донести его до жертвы.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Ваша цель - добиться выполнения произвольного JavaScript-кода в данном приложении используя
уже имеющийся в странице вызов eval(). Для того чтоб успешно завершить урок вы дложны вызвать выполнение строки
'alert(document.cookie)'.

View File

@ -0,0 +1,10 @@
<div align="Center">
<p><b>Название урока:</b> Использование основной кодировки</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
По множеству причин содержимое веб-приложения может храниться в нескольких разных кодировках.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Данный урок предназначается для тех, кто знаком с понятием кодировок и понимает
чем они отличаются друг от друга.

View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Название урока:</b> Использование уязвимостей ложной аутентификации </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
На данном уроке вы ознакомитесь с основами возникновения условий, приводящих к
ложной аутентификации пользователей. Например, ложная аутентификация может происходить в тех случаях,
когда возникающая в процессе работы приложения ошибка (например неперехваченное исключение)
не позволяет программе точно определить верность вводимых пользователем данных.<br>
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Вы должны обойти механизм проверки аутентификации.

View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Название урока:</b> Обращение к скрытым ресурсам. </p>
</div>
<p><b>Тема для изучения:</b> </p>
Как производить обращение к скрытым ресурсам
<br>
<div align="Left">
<p>
<b>Как работают такие атаки:</b>
</p>
Эта техника используется хакерами для обращения к тем ресурсам, ссылок на которые
на сайте нет, но доступ к которым никак не ограничен.
Одним из примеров такой техники является затирание части URL для того чтоб просмотреть содержимое
незащищённой директории.
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
* Вашей целью является угадывание URL интерфейса конфигурации.<br>
* Ссылка на него видна только управляющему персоналу.<br>
* Приложение не проверяет наличие соответствующих привилегий при доступе к нему
<!-- Stop Instructions -->

View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Название урока:</b> Как можно использовать страницу восстановления пароля</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-приложения очень часто предоставляют своим пользователям возможность восстановления забытого пароля.
К сожалению, во многих из них данный механизм реализован не безопасно. Информация, требуемая для идентификации
пользователя, как правило, очень проста.
<p><b>Основные цели:</b> </p>
Пользователи могут восстановить их пароль если у них получится ответить на секретный вопрос. На странице
восстановления нет никаких мезанизмов связанных с блокировкой аккаунтов. Ваше имя пользователя - 'webgoat',
любимый цвет - красный (red). Цель урока - восстановить пароль к аккаунту другого пользователя.
<!-- Stop Instructions -->

View File

@ -0,0 +1,17 @@
<div align="Center">
<p><b>Название урока:</b> Использование скрытых полей форм </p>
</div>
<p><b>Тема для изучения:</b> </p>
Разработчики используют скрытые поля форм для хранения на загруженной клиентом странице
информации о ценах, авторизации, отслеживания переходов по сайту и многом другом.
Очень часто программисты пренебрегают проверкой данных получаемых из них.
На этом уроке вы научитесь находить hidden-поля и изменять их содержимое для того чтоб
устанавливать товарам нужную вам цену.
<br>
<p><b>Основные цели и задачи:</b> </p>
Пользователь должен манипулируя значениями скрытых полей приобрести товар по ненастоящей цене.
<!-- Start Instructions -->
Попробуйте заказать HDTV намного дешевле чем он стоит на самом деле.
<!-- Stop Instructions -->

View File

@ -0,0 +1,55 @@
<!-- Start Instructions -->
<h1>Как работать с WebGoat</h1>
<p>
Добро пожаловать в краткую инструкцию по работе с WebGoat.<br>
Здесь вы научитель использовать сам WebGoat, а также инструменты, необходимые для некоторых уроков.<br><br>
</p>
<h2>Информация о среде работы WebGoat</h2>
<p>
WebGoat работает под управлением Apache Tomcat. По умолчанию он настроен на работу на хосте localhost,
однако в случае необходимости имя хоста может быть легко изменено.
Кроме того, по умолчанию WebGoat настроен на работу лишь с одним пользователем. Дополнительные учётные записи
вы можете добавить в файле tomcat-users.xml.
Если вы хотите использовать WebGoat в лаборатории или классе вам обязательно нужно изменить его базовую конфигурацию.
Для этого пройдите в раздел "Введение" и прочтите главу "Настройка Tomcat"
</p>
<h2>Интерфейс WebGoat</h2>
<p>
<img src="images/introduction/interface.jpg"><br><br>
1. Здесь располагаются категории уроков WebGoat. Кликните по любой категории и вы увидите какие уроки в неё входят.<br>
2. При клике здесь находятся подсказки которые помогут вам проходить уроки.<br>
3. При клике здесь отобразятся параметры текущего HTTP-запроса<br>
4. При клике здесь отобразятся текущие Cookies<br>
5. При клике здесь отобразятся цели и задачи текущего урока.<br>
6. При клике здесь отобразится исходный код урока на Java.<br>
7. При клике здесь отобразится решение текущего урока.<br>
8. В случае если вы хотите начать урок заново кликите на эту ссылку.</p>
<h2>Решение уроков</h2>
<p>
Всегда начинайте работу по плану текущего урока. Если вдруг решить урок у вас никак не получается,
воспользуйтесь подсказками к нему. В том случае, если урок не получается решить даже с помощью подсказок
вы можете посмотреть подробное его решение.</p>
<h2>Чтение и редактирование параметров</h2>
<p>
Для чтения и редактирования параметров вам необходимо иметь локальный прокси-сервер способный перехватывать
HTTP-запросы. Здесь вы можете использовать WebScarab. Более подробную информацию о нём вы можете получить в разделе
"Используемые инструменты". После установки WebScarab и настройки браузера на работу с ним можно начинать прохождение уроков.
<br><br>
<img src="images/introduction/HowToUse_1.jpg"><br><br>
Мы ставим галочку в поле "Intercept Request" на закладке "Intercept". Если мы сейчас пошлём из браузера какой-либо запрос, то сразу
же появится новое окно WebScarab.<br><br>
<img src="images/introduction/HowToUse_2.jpg"><br><br>
Здесь мы можем смотреть и редактировать перехватываемые параметры. После нажатия "Accept Changes" запрос пойдёт дальше на сервер.
</p>
<h2>Просмотр и редактирование Cookies</h2>
<p>
Почти всегда редактирование Cookies происходит точно также как и редактирование параметров запроса.
Мы можем использовать WebScarab для перехвата запроса и изменения значений имеющихся в нём Cookies
точно также как описывалось выше.
<br><br>
<img src="images/introduction/HowToUse_3.jpg"><br><br>
При отправке нового запроса появится уже знакомое окно. На скриншоте вы видите где может располагаться
строка с Cookies и как можно редактировать её значение.
</p>
<!-- Stop Instructions -->

View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Название урока:</b> How to Discover Clues in the HTML </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Многие разработчики, к сожалению, забывают удалять из рабочих версий кода всевозможные отметки типа FIXME, TODO, небольшие хаки и т.д.
&nbsp;Исследование исходного кода на наличие различных комментариев&nbsp;, паролей, бэкдоров и прочего может очень
сильно вам помочь. Ниже представлена форма авторизации. Попробуйте исследовать код страницы и найти
зацепки которые позволят вам войти как легитимный пользователь.
<!-- Stop Instructions -->
<br>
<p><b>Основные цели и задачи:</b> </p>
Вы должны обойти систему авторизации.

View File

@ -0,0 +1,33 @@
<div align="Center">
<p><b>Название урока:</b> Основы Http </p>
</div>
<p><b>Тема изучения:</b> </p>
В данном уроке представлены основы необходимые для понимания процесса передачи данных между браузером и веб-приложением.<br>
<div align="Left">
<p>
<b>Как работает HTTP:</b>
</p>
Все обращения по протоколу HTTP имеют один основной формат. Кажный запрос клиента или ответ сервера состоит из трёх частей:
строка запроса или ответа, заголовок и тело. Клиент начинает предачу данных следующим образом: <br>
<br>
Он соединяется с сервером и отправляет запрос для получения документа <br>
</div>
<br>
<ul>GET /index.html?param=value HTTP/1.0</ul>
Далее он шлёт различную информацию в разделе заголовка чтоб уведомить сервер о своей конфигурации и возможностях
(например какие кодировки и типы документов поддерживаются клиентом).<br>
<br>
<ul>User-Agent: Mozilla/4.06<br />Accept: image/gif,image/jpeg, */*</ul>
После отправки запроса и заголовков клиент может отправить дополнительные данные. Они в большинстве случаев
предназначаются для CGI-программ использующих метод POST для принятия информации.<br>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
Введите ваше имя в поле расположенное ниже и нажмите "Вперёд!" для отправки формы. Сервер примет ваш запрос, выстроит
полученную строку в обратном порядке и выведет результат на экран. Данный пример иллюстрирует основы обработки данных
полученных из HTTP-запроса.
<br/><br/>
Пользователю необходимо ознакомится с использованием функций WebGoat, таких как просмотр подсказок, отображение параметров HTTP-запроса,
отображение Cookies и исходных кодов Java. Первое время, в качестве практики, для просмотра параметров и Cookies
запросов вы можете использовать WebScarab.
<!-- Stop Instructions -->

View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Название урока:</b> Проверка HttpOnly</p>
</div>
<p><b>Тема для изучения:</b></p>
<!-- Start Instructions -->
Для того чтоб помешать проведению 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 />
Когда вы включите HTTPOnly, находясь на странице, cookies домена которой он защищает,
впишите в адресную строку выражение "javascript:alert(document.cookie)". Вы увидите табличку со всеми
cookies кроме unique2u.
<!-- Stop Instructions -->

View File

@ -0,0 +1,47 @@
<div align="Center">
<p><b>Название урока:</b> Проводение атак HTTP Splitting </p>
</div>
<p><b>Тема изучения:</b> </p>
На данном уроке вы ознакомитесь с атаками класса HTTP Splitting
<br />
<div align="Left">
<p>
<b>Как работают такие атаки:</b>
</p>
<p>
Атакующий посылает веб-серверу вредоносные данные вместе с ожидаемыми. Уязвимое приложение не проверяет полученную
информацию на наличие символов CR (возврат коретки, обозначается с помощью %0d или \r) и LF (перевод строки, обозначается
с помощью %0a или \n). Данные символы не только позволяют атакующему контролировать возвращаемые сервером заголовки и тело ответа,
но и дают ему возможность создавать поддельные ответы, содержимое которых будет ему полностью подконтрольно.
</p>
<p>
Эффект от таких атак может усиливаться когда они проводятся вместе с атаками класса "Отравление кеша" (Cache Poisoning).
Смысл их в отравлении кеша жертвы по средствам подсовывания ей с помощью HTTP Splitting поддельной страницы,
пришедшей якобы от сервера.
</p>
<p>
Вместе с этим, с помощью уязвимостей позволяющих провести разбиение HTTP-ответа, злоумышленник может заставить сервер
отослать клиенту поддельный заголовок <b>Last-Modified:</b> с датой из будущего. От этого браузер клиента станет посылать серверу
неверное содержимое в заголовке <b>If-Modified-Since</b>. Сервер, в свою очередь, всегда будет отвечать клиенту что (отравленная)
страница не изменилась и клиент постоянно будет видеть страницу подсунутую злоумышленником.
</p>
<p>Простой пример ответа с кодом 304:
<blockquote>HTTP/1.1 304 Not Modified <br />
Date: Fri, 30 Dec 2005 17:32:47 GMT</blockquote>
</p>
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
<p>Данный урок имеет две стадии. На первой вы изучаете проведение атак HTTP Splitting, а на второй научитесь совмещать
их с отравлением кеша. </p>
<p>
Введите любой язык в форму поиска. После отправки формы приложение осуществит переадресацию на другую ссылку,
расположенную на этом же сервере. С помощью помещения CR (%0d) и LF (%0a) в название языка вы должны изучить проведение атак
данного типа.
Ваша цель состоит в том, чтоб заставить сервер отправить ответ 200 ОК. Если содержимое экрана изменится от вашей атаки,
просто перейдите на главную страницу. Как только шаг 2 будет выполнен успешно вы увидите что в левом меню появилась новая
зелёная отметка на против этого раздела.
</p>
<!-- Stop Instructions -->

View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Название урока:</b> Insecure Login</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Чувствительная информация никогда не должна посылаться в виде открытого текста!
Многие приложения устанавливают защищённые соединения только после авторизиации.
Это помогает хакерам, в том плане что они могут перехватить отправленные пользователем данные
ещё до установки им безопасного соединения. В хороших веб-приложениях важная информация
никогда не передаётся в открытом виде.
<p><b>Основные цели и задачи:</b> </p>
Посмотрите как легко прочесть пароль передающийся открытым текстом. Так вы<br>
лучше поймёте преимущества передачи информации по защищённому соединению.
<!-- Stop Instructions -->

View File

@ -0,0 +1,25 @@
<div align="Center">
<p><b>Название урока:</b> Выполнение атак класса 'JSON-инъекция'</p>
</div>
<p><b>Тема для изучения:</b> </p>
На данном уроке вы научитесь осуществлять атаки класса 'JSON-инъекция'
<br>
<div align="Left">
<p>
<b>Как работают такие атаки:</b>
</p>
JSON - это простой, &quot;легковесный&quot; и эффективный формат передачи данных. Данные,
передаваемые с его помощью, могут иметь различные формы. Например это может быть массив, список, хеш-таблица и т.д.
JSON обычно используется в AJAX- и Web2.0-приложениях, постепенно вытесняя XML за счёт своей простоты и скорости обработки.
В то же время JSON, как и XML, предрасположен к атакам инъективного класса. Например злоумышленник может перехватить ответ
сервера и внедрить в него произвольные данные.
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
* Вы летите из Бостона, с аэропорта с кодом BOS, в Сиэтл, в аэропорт с кодом SEA.<br>
* Когда вы введёте трёхзначные коды аэропортов, на сервер, средствами AJAX, уйдёт запрос о цене билета.<br>
* Вам сообщат что есть два доступных варианта - один без остановок, а второй с двумя остановками.<br>
* Ваша задача попытаться заказать билет без остановок за цену билета с двумя остановками.
<!-- Stop Instructions -->

View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Название урока:</b> Обход валидации данных реализованной на клиентской стороне с помощью JavaScript </p>
</div>
<p><b>Тема для изучения:</b> </p>
Проверку данных, реализованную на клиентской стороне, не стоит рассматривать
как какой-то механизм повышающий безопасность приложения. Она лишь призвана сократить
количество неверных данных обрабатываемых сервером, которые могут поступать от простых
пользователей не знающих правильный формат определённых полей. Атакующие могут
легко обойти такие механизмы множеством способов. Поэтому проверка вводимой информации на клиентской стороне
обязательно должна иметь свои аналог на серверной части приложения. Это сильно снизит возможность
попадания в важные механизмы приложения опасных данных.
<br>
<p><b>Основные цели:</b> </p>
На этом уроке веб-сайт проверяет содержимое формы с помощью определённых механизмов.
Ваша цель обойти их и отправить форму с такими данными, которых сайт не ожидает.
<br>
<!-- Start Instructions -->
На данном сайте реализована проверка поступающих данных и на клиентской, и на серверной стороне.
Вашей задачей является нарушение работы клиентского механизма проверки и отправка сайту неожиданной
для него информации. <b> Вы должны нарушить работу всех 7 валидаторов. </b>
<!-- Stop Instructions -->

View File

@ -0,0 +1,17 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> </p>
</div>
<!-- Start Instructions -->
<p><b>Concept / Topic To Teach:</b> </p>
<p><b>Standards Addressed:</b> </p>
<p><b>General Goal(s):</b> </p>
<p><b>Specific Objectives:</b> </p>
<p><b>Required Materials:</b> </p>
<p><b>Anticipatory Set (Lead-In):</b> </p>
<p><b>Step-By-Step Procedures:</b> </p>
<p><b>Plan For Independent Practice:</b> </p>
<p><b>Closure (Reflect Anticipatory Set):</b> </p>
<p><b>Assessment Based On Objectives:</b> </p>
<p><b>Extensions (For Gifted Students):</b> </p>
<p><b>Possible Connections To Other Subjects:</b> </p>
<!-- Stop Instructions -->

View File

@ -0,0 +1,20 @@
<div align="Center">
<p><b>Название урока:</b> Подделка записей в лог-файлах. </p>
</div>
<p><b>Тема для изучения:</b> </p>
На этом уроке рассматривается простой обман человеческих глаз.
<br>
<div align="Left">
<p>
<b>Как работает данный тип атак:</b>
Целью этих атак является подделка записей лог-файла за счёт помещения в него специально сформированной строки.
Это позволит атакующему запутать администратора и скрыть свои следы.
</p>
</div>
<p><b>Основные цели:</b> </p>
<!-- Start Instructions -->
* В сером поле, расположенном ниже, отображается содержимое которое будет в несено в лог-файл.<br>
* Вашей целью является создание такой записи, в которой сообщено будто пользователь "admin" вошёл успешно<br/>
* Кроме этого попробуйте поместить в лог-файл какую-нибудь JS-вставку.
<!-- Stop Instructions -->

View File

@ -0,0 +1,19 @@
<div align="Center">
<p><b>Название урока:</b> Многоуровневая авторизация 1</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Многоуровневая авторизация обеспечивается добавленим дополнительного варианта
проверки пользователя. Например, после того как вы зайдёте под своим именем и паролем, при
совершении важной операции приложение может попросить вас указать идентификационный номер транзакции (TAN).
Обычно такие схемы используются в онлайн-банкинге. Банк даёт вам список допустимых
номеров транзакций которые уникальны для каждого клиента. Один TAN может быть использован
только один раз. Кроме того, TAN может отправляться клиенту по SMS. В данном случае
упор делается на то, что злоумышленнику очень трудно узнать номера транзакций имеющиеся
у пользователя.
<p><b>Основные цели и задачи:</b> </p>
В данном уроке вы должны исследовать похожую система аутентификации.
Из исходных данных у вас есть имя пользователя, пароль и
уже использованые TAN. Вы должны узнать принимает ли сервер номера транзакций ставшие недействительными.
<!-- Stop Instructions -->

View File

@ -0,0 +1,17 @@
<div align="Center">
<p><b>Название урока:</b> Многоуровневая авторизация 2</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Многоуровневая авторизация обеспечивается добавленим дополнительного варианта
проверки пользователя. Например, после того как вы зайдёте под своим именем и паролем, при
совершении важной операции приложение может попросить вас указать идентификационный номер транзакции (TAN).
Обычно такие схемы используются в онлайн-банкинге. Банк даёт вам список допустимых
номеров транзакций которые уникальны для каждого клиента. Один TAN может быть использован
только один раз. Кроме того, TAN может отправляться клиенту по SMS. В данном случае
упор делается на то, что злоумышленнику очень трудно узнать номера транзакций имеющиеся
у пользователя.
<p><b>Основные цели и задачи:</b> </p>
У вас уже есть аккаунт для системы 'WebGoat Financial', но вам нужно
войти под другим аккаунтом зная лишь его логин.
<!-- Stop Instructions -->

View File

@ -0,0 +1,13 @@
<!-- Start Instructions -->
<h1>Создание уроков WebGoat</h1>
<p>
Добавлять уроки в WebGoat очень просто. Если у вас есть хорошая идея<br>
для нового урока, следуйте этой простой инструкции чтоб реалиовать её:<br><br>
* Скачайте исходный код <a href="http://code.google.com/p/webgoat/">здесь.</a><br><br>
* Установите фреймворк: следуйте простым инструкциям в "HOW TO create the WebGoat workspace.txt" (данный файл поставляется вместе с WebGoat).<br><br>
* Вам необходимо добавить 2 файла с содержимым вашего урока: <br>
&nbsp;&nbsp;- YourLesson.java в org.owasp.webgoat.lessons<br>
&nbsp;&nbsp;- YourLesson.html в WebContent/lesson_plans</p>
<!-- Stop Instructions -->

View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Название урока:</b> Стойкость пароля</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Аккаунты защищены на столько, на сколько защищены их пароли. Многие пользователи
везде стремятся использовать самые простые варианты паролей. Если вы хотите защитить их от атаки методом простого
перебора (brute-force), вам следует предъявлять к ним серьёзные требования. Пользовательский пароль обязательно должен содержать
как минимум буквы верхнего и нижнего регистров и цифры. Чем длиннее пароль, тем лучше.
<!-- Stop Instructions -->
<br>
<p><b>Основные цели и задачи:</b> </p>
Попробуйте проверить несколько используемых вами паролей на стойкость вот на этом сервисе - <a href="https://www.cnlab.ch/codecheck" target="_blank">https://www.cnlab.ch/codecheck</a>

View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Название урока:</b> Обход схем контроля доступа основанных на путях файловой системы. </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
В схемах контроля доступа основанных на путях файловой системы атакующий может попытаться передать приложению
относительный путь, вместо ожидаемых данных, для обхода ограничений безопасности. Следовательно, злоумышленник может
получить доступ к файлам, которые находятся вне текущей директории и к которым при нормальной работе приложения обращаться нельзя.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Пользователь должен получить доступ к файлу, находящемуся вне текущей директории.

View File

@ -0,0 +1,17 @@
<div align="Center">
<p><b>Название урока:</b> Фишинг, основанный на применении XSS </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Проверка всех принимаемых от пользователей данных всегда считается хорошей практикой.
XSS-уязвимости возникают в том случае, когда непроверенные пользовательские данные
возвращаются ему же в HTTP-ответе. С использованием XSS-уязвимостей вы можете совершать
фишинг-атаки или же просто добавлять на уязвимую страницу какое-нибудь стороннее содержимое.
В таких ситуациях посетителям-жертвам очень трудно отделить настоящую информацию на сайте от
поддельной.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Пользователь должен каким-либо образом добавить на страницу форму
запроса логина и пароля. При её отправке введённые данные должны уходить на адрес
http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName

View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Название урока: </b>Использование отражённых XSS-уязвимостей</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Всегда хорошей практикой считалась проверка всех входящих данных на стороне сервера.
XSS-уязвимости могут возникать в тех случаях, когда непроверенные пользовательские
данные сразу помещаются в HTTP-ответ. В таких случаях нападающий может сформировать URL, содержащий в себе
вредоносный код и передать его жертве(ам) через сторонний веб-сайт, почту или любым другим способом.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
В этом упражнении вашей целью является отправка серверу специально сформированного
вредоносного сообщения, которое, отобразившись в ответной странице,осуществит
какие-нибудь опасные действия (например выполнит произвольный JS-код).

View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Название урока: </b>Доступ к скрытым ресурсам сайта</p>
</div>
<p><b>Тема для изучения:</b> </p>
Приложения очень часто имеют административные интерфейсы позволяющие привилегированным пользователям
получать доступ к такому функционалу, к которому обычные пользователи не допускаются. Кроме того,
сам сервер приложения может иметь административный интерфейс.
<p><b>Стандартные адреса:</b> </p>
<p><b>Основные цели и задачи:</b>
<!-- Start Instructions -->
Попробуйте получить доступ к административному интерфейсу WebGoat. Вы также можете попытаться обратиться к административному
интерфейсу Tomcat. Располагается он по адресу /admin. Обратите внимание на то что непосредственного отношения к данному уроку
он не имеет.
<!-- Stop Instructions -->
</p>

View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Название урока:</b> Контроль доступа основанный на ролях</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
В схемах основанных на ролях сама роль представляет из себя набор разрешений доступа и привилегий.
Пользователю одновременно может быть присвоена одна или более ролей.
Подобные схемы чаще всего включают в себя два механизма: механизм работы с разрешениями доступа и
механизм назначения привилегий. В случаях когда реализация данной схемы имеет какие-то изъяны пользователь может получить
доступ к функционалу, к которому ему обращаться не разрешено. Или он может каким-либо образом повысить свои
привилегии в приложении.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Ваша цель состоит в изучении правил контроля доступа данного сайта.
Каждая роль имеет разрешения на доступ к определённому ресурсу (A-F). Каждому пользователю присвоена одна или более ролей.
Только пользователи имеющие роль [Admin] могу получать доступ к F-ресурсам. В случае удачного проведения атаки
пользователь не имеющий роль [Admin] должен получить доступ к F-ресурсам.
<p><b>Учебные ресурсы:</b> </p>
<a href="lessons/RoleBasedAccessControl/images/orgChart.jpg" onclick="makeWindow(this.href, 'Org Chart');return false;" target="orgChartWin">Схема организации</a>
<br>
<a href="lessons/RoleBasedAccessControl/images/accessControl.jpg" onclick="makeWindow(this.href, 'Access Control Matrix');return false;" target="accessControlWin">Матрица контроля доступа</a>
<br>
<a href="lessons/RoleBasedAccessControl/images/dbSchema.jpg" onclick="makeWindow(this.href, 'Access Control Matrix');return false;" target="accessControlWin">Структура базы данных</a>

View File

@ -0,0 +1,20 @@
<div align="Center">
<p><b>Название урока:</b> Проведение SQL-инъекци</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
SQL-инъекции представляют из себя очень серьёзную угрозу для сайтов основанных на БД.
Методы их использования достаточно легки в освоении, а ущерб создаваемый ими огромен и
при определённых условиях может произойти к компрометации всей системы. Тем не менее,
количество интернет-сайтов с уязвимостями данного типа постоянно растёт.
<br><br>
На самом деле всегда можно избежать появления уязвимостей этого класса
если в процессе написания приложений соблюдать общие меры предосторожности.
Например фильтровать все поступающие от пользователя данные. Особенно те, которые
будут помещены в SQL-запросы.
<br>
<p><b>Основные цели и задачи:</b> </p>
В данном упражнении вы научитесь использовать SQL-инъекции. Кроме того, вам нужно будет
внести в код правки, которые устранят эту уязвимость в тестовом приложении.
<!-- Stop Instructions -->

View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Название урока: </b>Защита с помощью политики одного источника (Same Origin Policy)</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Ключевым элементом технологии AJAX является компонент XMLHttpRequest (XHR). Он позволяет с помощью JavaScript
отправлять запросы на сторону сервера в асинхронном режиме. Из соображений безопасности запрос можно отправить
только на тот домен, с которого загружена текущая страница.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Упражнение демонстрирует механизмы защиты обеспеченные политикой одного источника (Same Origin Policy)
Через компонент XHR можно отправлять запрос лишь на тот сервер, с которого была загружена текущая
страница. Попытки отправить запрос на другой сервер потерпят неудачу. ";

View File

@ -0,0 +1,31 @@
<div align="Center">
<p><b>Название урока:</b> Закрепление сессии</p>
</div>
<p><b>Тема для изучения:</b> </p>
Использование атак класса 'Закрепление сессии'
<br>
<div align="Left">
<p>
<b>Как работает данный вид атак:</b>
</p>
Сервер может опознать конкретного пользователя по уникальному идентификатору сессии.
Это позволяет клиентам проходить поцедуру авторизации всего 1 раз, а затем уже обращаться к
приложению как авторизированное лицо. В некоторых приложениях идентификатор сессии
передаётся в ссылках, в качестве одного из параметров GET-запроса. Здесь и начинаются главные проблемы.
<br><br>
Атакующий может послать жертве гипер-ссылку содеращую в себе любой
идентификатор сессии. Это может быть сделано, например, через почтовое
сообщение, которое выглядит как обращение администрации сайта.
Когда жертва, кликнув по ней, попадёт на сайт и пройдёт авторизацию, то идентификатор сессии, выбранный
злоумышленником, станет идентификатором авторизованного пользователя-жертвы.
Атакующий может пройти по любой ссылке передав серверу этот же идентификатор,
и сможет действовать от чужого имени.
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
Урок имеет несколько стадий. Вы играете роль и атакующего и жертвы.
К концу урока вы поймёте что передача идентификаторов сессий в ссылках
является очень плохой практикой.
<!-- Stop Instructions -->

View File

@ -0,0 +1,27 @@
<div align="Center">
<p><b>Название урока:</b> Атаки связанные со скрытыми операциями. </p>
</div>
<p><b>Тема для изучения:</b> </p>
На данном уроке вы поймёте как осуществляются атаки связанные со скрытыми операциями.
<br>
<div align="Left">
<p>
<b>Как работают атаки такого рода:</b>
</p>
Некоторые приложения производят манипуляции с чувствительными пользовательскими данными (например с деньгами)
в скрытом виде если получат разрешение на это хотя бы один раз. Это таит множество опасностей.
Например, в простом веб-приложении для того чтоб от имени клиента обратиться к любому URL необходимо
получить его идентификатор сессии (или другие данные, которые обеспечат необходимую идентификацию).
В случае с AJAX всё намного проще: обращение к серверу может происходить в скрытом режиме без оповещения об этом пользователя.
Следовательно, внедрённый каким-либо образом в такую страницу вредоносный скрипт может осуществлять важные
операции совершенно незаметно для клиента. Например переводить его деньги со счёта на счёт.<br>
</div>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
* Это простейшее приложение интернет-банкинга - страница перевода денег.<br>
* Здесь отображается сумма находящаяся на балансе, поле для ввода аккаунта, которому деньги будут переведены, и поле
для суммы перевода.<br>
* Приложение использует AJAX для отправки транзакции после проведения элементарной проверки данных на клиентской стороне.<br>
* Ваша цель - попробовать осуществить от имени пользователя денежный перевод в скрытом виде.<br>
<!-- Stop Instructions -->

View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Название урока:</b> Осуществление SOAP-запросов</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-сервисы общаются между собой с помощью SOAP-запросов. Эти запросы отправляются
на веб-сервис и вызывают выполнение некоторых функций описанных в WSDL-файлах.
Рассмотрим их подробнее. У WebGoat есть свой WSDL-файл, над которым
вы можете поэкспериментировать.
<p><b>Основные цели и задачи:</b> </p>
Попробуйте соединиться с WSDL с помощью браузера или какой-нибудь утилиты для работы с
веб-сервисами. URL сервиса http://localhost/WebGoat/services/SoapRequest . WSDL
может быть вызван добавлением в конец URL фразы ?WSDL.
<!-- Stop Instructions -->

View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Название урока:</b> Проведение числовых SQL-инъекций </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
SQL-инъекции представляют из себя очень серьёзную угрозу для сайтов основанных на БД.
Методы их использования достаточно легки в освоении, а ущерб создаваемый ими огромен и
при определённых условиях может произойти к компрометации всей системы. Тем не менее,
количество интернет-сайтов с уязвимостями данного типа постоянно растёт.
<br><br>
На самом деле всегда можно избежать появления уязвимостей этого класса
если в процессе написания приложений соблюдать общие меры предосторожности.
Например фильтровать все поступающие от пользователя данные. Особенно те, которые
будут помещены в SQL-запросы.
<br>
<p><b>Основные цели:</b> </p>
Расположенная ниже форма позволяет пользователям смотреть данные о погоде.
Вам необходимо с её помощью обнаружить в тестовом приложении уязвимость.
Для подсказки чуть ниже выводится итоговый запрос, который получается на
стороне сервера.
<!-- Stop Instructions -->

View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Название урока:</b> Как использовать строковые SQL-инекции </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
SQL-инъекции представляют из себя очень серьёзную угрозу для сайтов основанных на БД.
Методы их использования достаточно легки в освоении, а ущерб создаваемый ими огромен и
при определённых условиях может произойти к компрометации всей системы. Тем не менее,
количество интернет-сайтов с уязвимостями данного типа постоянно растёт.
<br><br>
На самом деле всегда можно избежать появления уязвимостей этого класса
если в процессе написания приложений соблюдать общие меры предосторожности.
Например фильтровать все поступающие от пользователя данные. Особенно те, которые
будут помещены в SQL-запросы.
<br>
<br>
<p><b>Основные цели и задачи:</b> </p>
Расположенная ниже форма позволяет пользователям просматривать их номера кредитных карт.
Попробуйте внести SQL-выражение в поле фамилии. После отправки формы вы чуть ниже увидите итоговый
SQL-запрос, который сформируется в приложении. В качестве самой фамилии используйте 'Smith'.
<!-- Stop Instructions -->

View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Название урока:</b> Проведение хранимых XSS</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
БД. Это важно и для тех данных, которые будут сохранены где-то
внутри приложения. Посетители не должны иметь возможность публикации на сайте
таких сообщений, которые могут изменять структуру страницы при их просмотре.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Вы должны добавить такое сообщение, которое при просмотре другим пользователем будет формировать
на данной странице поддельное содержимое.

View File

@ -0,0 +1,35 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>План урока</title>
</head>
<body>
<div align="Center">
<p><b>Название урока:</b> Как эксплуатировать проблемы одновременной работы нескольких потоков.</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-приложения могут обрабатывать множество HTTP-запросов одновременно.
Часто разработчики используют конструкции не приспособленные к многопоточной работе, и
это создаёт возможность использования ошибок связанных с одновременными обращениями.
Например когда одна и та же страница открывается одновременно разными пользователями и один их них видит
на ней данные другого.
Под приспособленностью к многопоточной работе подразумевается способность полей классов и объектов
всегда находиться в верном состоянии при выполнении множества одних и тех же операций вызываемых
разными потоками. Поскольку все потоки используют одно и то же рабочее пространство вызываемых методов, и в данном
пространстве хранятся данные всех свойств отдельно взятых классов, то множественные одновременные попытки
обращений к ним могут привести к неожиданным результатам.
<br>
<!-- Stop Instructions -->
<p><b>Основные цели:</b> </p>
В приложении урока пользователь может воспользоваться уязвимостю данного типа для того чтобы просматривать
авторизационные данные другого пользователя, если одновременно с ним попытается вызвать одну
и ту же функцию.
<b>Здесь вам придётся использовать два браузера</b>.
<br>
</body>
</html>

View File

@ -0,0 +1,110 @@
<!-- Start Instructions -->
<h1>Настройка Tomcat</h1><br><br>
<h2>Введение</h2>
<p>WebGoat распространяется с конфигурацией Tomcat по умолчанию. На данной странице вы найдёте её короткое описание и
список возможных вариантов различных настроек. В случаях когда данное описание вам не помогает обращайтесь к официальной
документации Tomcat.
Кроме того, нужно сказать что всё нижеописанное относится к стандартной конфигурации сервера работающего на 80-ом порту.
Если вы используете для сервера другой порт, то вам необходимо будет изменить конфигурацию соответствующим образом.
</p>
<h2>Стандартная конфигурация</h2>
<p>Здесь имеется две стандартных конфигурации 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.
</p>
<h2>Настройка сервера</h2>
<p>
Если вы единственный кто будет использовать WebGoat, то стандартной конфигурации вам
будет вполне достаточно. Если же вы будете запускать его в лаборатории или классе, то конфигурацию
нужно будет менять. Перед этим советуем вам сделать её резервную копию.
</p>
<h3>Изменение портов</h3>
<p>
Для изменения портов откройте файл server_80.xml, котрый можно найти в tomcat/conf, и измените
не-SSL порт. Например, если вы хотите использовать порт 8079:
</p>
<pre>
&lt;!-- Define a non-SSL HTTP/1.1 Connector on port 8079 --&gt;
&lt;Connector address=&quot;127.0.0.1&quot; port=&quot;8079&quot;...
</pre>
<p>
Конечно же вы можете изменить и порт SSL-соединения. Вот пример переноса SSL на порт 8442:
</p>
<pre>
&lt;!-- Define a SSL HTTP/1.1 Connector on port 8442 --&gt;
&lt;Connector address=&quot;127.0.0.1&quot; port=&quot;8442&quot;...
</pre>
<br>
<h3>Делаем WebGoat доступным для нескольких клиентов.</h3>
<p>ЭТО ОТКРЫВАЕТ ВАШ СЕРВЕР ДЛЯ РЕАЛЬНЫХ АТАК ИЗ ВНЕ! НЕ ДЕЛАЙТЕ ЭТОГО ЕСЛИ ВЫ НА 100%
НЕ УВЕРЕНЫ В НЕОБХОДИМОСТИ ДАННОГО ШАГА. ЭТА КОНФИГУРАЦИЯ МОЖЕТ БЫТЬ ИСПОЛЬЗОВАНА ТОЛЬКО
В ДОВЕРЕННЫХ СЕТЯХ.
</p>
<p>По умолчанию WebGoat доступен только при обращении к хосту localhost. В лаборатории или классе
у вас может возникнуть необходимость организовать сервер с множеством клиентов. В данном случае
вы можете настроить WebGoat соответствующим образом.
</p>
<p>Причина того что WebGoat доступен только на localhost - параметр address тега Connector в файле server_80.xml.
Изначально его значение установлено в 127.0.0.1 . При запуске приложение начинает проверять прописанные в настройках порты
только на этом адресе и принимает соединения если они появляются. Если вы удалите данный параметр, то приложение
начнёт прослушивать соответствующие порты на всех доступных IP-адресах.
</p>
<h3>Разрешение соединений только от определённых клиентов</h3>
<p>
Выше описывался способ разрешения соединений с WebGoat для любых клиентов.
Если вы хотите разрешить доступ к приложению только с определённых адресов, воспользуйтесь
фильтром удалённых адресов (Remote Address Filter). Для этого добавьте следующюю строку
в файл web_80.xml:
</p>
<pre>
&lt;Valve className=&quot;org.apache.catalina.valves.RemoteAddrValve&quot;
allow=&quot;127.0.0.1,ip1,ip2&quot;/&gt;
</pre>
<p>В этом случае только localhost, ip1 и ip2 смогут устанавливать соединения с сервером.</p>
<h2>Стандартные пользователи WebGoat и роли для Tomcat</h2>
<p>
WebGoat`у для нормальной работы необходимо наличие следующих пользователей и ролей:
<br/>
<pre>
&gt;role rolename="webgoat_basic"/&lt;
&gt;role rolename="webgoat_admin"/&lt;
&gt;role rolename="webgoat_user"/&lt;
&gt;user username="webgoat" password="webgoat" roles="webgoat_admin"/&lt;
&gt;user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/&lt;
&gt;user username="guest" password="guest" roles="webgoat_user"/&lt;
</pre>
</p>
<h2>Добавление пользователей</h2>
<p>
Обычно для нормальной работы с WebGoat вам достаточно будет пользователя guest с паролем guest.
Но когда вы развернёте его в лоборатории или классе может возникнуть необходимость создания отдельного
пользователя для каждого клиента. Для этого вам необходимо изменить файл tomcat-users.xml, которых находится в tomcat/conf.
<b>Мы настоятельно не рекомендуем хранить реальные действующие пароли в данном файле т.к.
там они прописываются в виде простого текста!</b>
</p>
<h3>Добавление пользователя</h3>
<p>
Процедура добавления пользователя очень проста. В качестве наглядного примера вы можете использовать
строку с пользователем guest. Помните что каждый вновь добавляемый пользователь должен иметь определённую роль.
Для добавления новых аккаунтов впишите в вышеуказанный файл строки типа этих:
</p>
<pre>
&lt;user name=&quot;student1&quot; password=&quot;password1&quot; roles=&quot;webgoat_user&quot;/&gt;
&lt;user name=&quot;student2&quot; password=&quot;password2&quot; roles=&quot;webgoat_user&quot;/&gt;
...
</pre>
<!-- Stop Instructions -->

View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Название урока:</b> Проведение XST-атак (Cross Site Tracing/Trace-XSS) </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Хорошей практикой всегда считалась очистка всех входящих данных, особенно когда
их содержимое будут использовано в качестве команд ОС, скриптов или запросов к
БД. Это важно и для тех данных, которые будут сохранены где-то
внутри приложения. Посетители не должны иметь возможность публикации на сайте
таких сообщений, которые могут изменять структуру страницы при их просмотре.
<p><b>Основные цели:</b> </p>
Tomcat настроен на поддержку команды HTTP TRACE. Ваша цель с её помощью осуществить
XST-нападение.
<!-- Stop Instructions -->

View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Название урока:</b> Использование непроверяемых почтовых сообщений </p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Многие сайты позволяют не аутентифицированным пользователям отправлять почтовые
сообщения своим "друзьям". Такие сайты представляют из себя хороший инструмент
для спамеров, которые получают возможность слать рекламу с использованием
почтового сервера компании.
<!-- Stop Instructions -->
<p><b>Основные цели и задачи:</b> </p>
Пользователь должен отослать любое почтовое сообщение.

View File

@ -0,0 +1,46 @@
<!-- Start Instructions -->
<h1>Используемые инструменты</h1>
<p>
Ниже находится список инструментов, которые, по нашему мнению, могут вам пригодиться при прохождении уроков WebGoat.
Для выполнения большинства заданий вам понадобится WebScarab или Paros.</p>
<h2>WebScarab:</h2>
<p>
Как и WebGoat, WebScarab - это часть OWASP. Он представляет из себя прокси-сервер
для исследования приложений использующих протоколы HTTP и HTTPS. Так как WebScarab
является перехватывающим прокси-сервером, то мы с его помощью можем просматривать и изменять
содержимое запросов и ответов на них.
<br><br>
<img src="images/introduction/webscarab.jpg"><br><br>
Его страничка:<a href="http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project">http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project</a>
</p>
<h2>Firebug:</h2>
<p>
Firebug - это дополнение к браузеру Firefox. Мы можем использовать его для проверки, редактирования и мониторинга CSS, HTML и JavaScript.<br><br>
<img src="images/introduction/firebug.jpg"><br><br>
Его страничка:<a href="http://www.getfirebug.com" target="_blank">http://www.getfirebug.com</a>
<br><br>
<h2>IEWatch:</h2>
<p>
IEWatch - это утилита для анализа HTTP и HTML для пользователей Internet Explorer.<br><br>
<img src="images/introduction/iewatch.jpg"><br><br>
Её страничка:<a href="http://www.iewatch.com" target="_blank">http://www.iewatch.com</a>
</p>
<h2>Wireshark</h2>
<p>
Wireshark - это анализатор сетевого трафика. С его помощью вы можете отлавливать сетевой трафик и получать из него интересную информацию.<br><br>
<img src="images/introduction/wireshark.png"><br><br>
Его страничка:<a href="http://www.wireshark.org" target="_blank">http://www.wireshark.org</a>
</p>
<h2>Сканнер:</h2>
<p>
В данный момент имеется большое количество сканеров для веб-приложений. Они могут находить XSS, инъективные и другие уязвимости.
Ниже представлены ссылки на два сканера с открытым исходным кодом.
<br><br>
Nessus:<a href="http://www.nessus.org" target="_blank">http://www.nessus.org</a><br>
Paros:<a href="http://www.parosproxy.org" target="_blank">http://www.parosproxy.org</a><br>
</p>
<!-- Stop Instructions -->
<br>

View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Название урока:</b> Осуществление WSDL-сканиорвания</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-сервисы общаются между собой с помощью SOAP-запросов. Эти запросы отправляются
на веб-сервис и вызывают выполнение некоторых функций описанных в WSDL-файлах.
<p><b>Основные цели и задачи:</b> </p>
Ниже расположена форма которая работает с уже известным вам веб-сервисом
через его API. Внимательно изучите WSDL-файл и попробуйте отправить форму так,
чтоб сервис вернул вам номера кредитных карт нескольких заказчиков.
<!-- Stop Instructions -->

View File

@ -0,0 +1,19 @@
<div align="Center">
<p><b>Название урока:</b> How to Spoof an Authentication Cookie </p>
</div>
<p><b>Тема для изучения:</b> </p>
Многие сайты автоматически аутентифицируют пользователя если он имеет особые cookies.
Иногда содержимое таких cookies может быть угадано если злоумышленник вычислил алгоритм их генерации.
В других случаях cookies могут быть перехвачены, украдены через уязвимости в приложении (например через XSS)
или системе пользователя. На этом уроке вы ознакомитесь с использованием таких cookies и
попытаетесь обойти систему аутентификации основанную на них.
<br>
<p><b>Основные цели и задачи:</b> </p>
<!-- Start Instructions -->
Пользователь должен обойти механизм проверки аутентификации.
Войдите под аккаунтом webgoat/webgoat и посмотрите что получится.
Вы также можете попробовать данные aspect/aspect. Как только вы поймёте
как можно аутентифицироваться под другими именами, попробуйте войти под
логином alice.
<!-- Stop Instructions -->

View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Название урока:</b> Похищение сессии</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Разработчики приложений, создающие свои механизмы работы с сессиями, иногда
забывают о том что идентификаторы сессий должны генерироваться случайным образом
и иметь достаточную длинну. Иначе они могут быть банально подобраны злоумышленником
методом грубой силы (brute force).
<p><b>Основные цели:</b> </p>
Попробуйте подобрать идентификатор рабочей сессии принадлежащей другому пользователю.
<!-- Stop Instructions -->

View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lesson Plan Title:Welcome</b> </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson presents the basics for understanding the transfer of data between the browser and the web application.
<p><b>Standards Addressed:</b> </p>
<p><b>General Goal(s):</b> </p>
<p><b>Specific Objectives:</b> </p>
<p><b>Required Materials:</b> </p>
<p><b>Anticipatory Set (Lead-In):</b> </p>
<p><b>Step-By-Step Procedures:</b> </p>
<p><b>Plan For Independent Practice:</b> </p>
<p><b>Closure (Reflect Anticipatory Set):</b> </p>
<p><b>Assessment Based On Objectives:</b> </p>
<p><b>Extensions (For Gifted Students):</b> </p>
<p><b>Possible Connections To Other Subjects:</b> </p>

View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Название урока:</b> Работа с SAX-инъекциями в веб-сервисах</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-сервисы общаются между собой с помощью SOAP-запросов. Эти запросы отправляются
на веб-сервис и вызывают выполнение некоторых функций описанных в WSDL-файлах.
<p><b>Основные цели и задачи:</b> </p>
Некоторые веб-интерфейсы могут использовать веб-сервисы в невидимом для пользователя режиме.
Если веб-сервис никак не проверяет целостность входных данных (или проверяет недостаточно),
пользователь может подделать XML отсылаемый веб-интерфейсом и выдать его за настоящий.
<br/>
<br>
В данном упражнении попытайтесь сменить пароль для любого пользователя кроме 101.
<!-- Stop Instructions -->

View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Название урока:</b> Использование SQL-инъекций в веб-сервисах.</p>
</div>
<p><b>Тема для изучения:</b> </p>
<!-- Start Instructions -->
Веб-сервисы общаются между собой с помощью SOAP-запросов. Эти запросы отправляются
на веб-сервис и вызывают выполнение некоторых функций описанных в WSDL-файлах.
<p><b>Основные цели и задачи:</b> </p>
Изучите внимательно WSDL-файл WebGoat и попробуйте получить
номера кредитных карт других пользователей. Обратите внимание на то, что вы не
будете видеть результат работы сервера на экране. Но как только вы составите верный
запрос, сразу соответствующий пункт меню отметится зелёной галочкой.
<!-- Stop Instructions -->

View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Название урока:</b> Как выполняются атаки класса 'XML-инъекция'. </p>
</div>
<p><b>Тема для изучения:</b> </p>
На данном уроке вы научитесь осуществлять атаки класса 'XML-инъекция'
<br>
<div align="Left">
<p>
<b>Как работает данный вид атак:</b>
</p>
AJAX-приложения используют XML для передачи данных на сервер. Ушедший XML может быть легко перехвачен
и изменён злоумышленником.
</div>
<p><b>Основные цели:</b> </p>
<!-- Start Instructions -->
Вы видите список призов, которые можно получить по программе 'WebGoat-Miles Reward Miles'.
Когда вы введёте ID своего аккаунта приложение отобразит вам ваш баланс и список призов, которые
вы можете заказать. Цель - заказать призы на которые у вас не хватает очков.
ID вашего аккаунта 836239.
<!-- Stop Instructions -->

View File

@ -0,0 +1,31 @@
<div align="Center">
<p><b>Название урока:</b> Использование XPATH-инъекций. </p>
</div>
<p><b>Тема для изучения:</b> </p>
Сейчас мы рассмотрим использование XPath-инъекций
<br>
<div align="Left">
<p>
<b>Как работает данный вид атак:</b>
</p>
По аналогии с SQL-инъекциями, XPath-инъекции возникают тогда, когда пользовательские
данные без должной проверки попадают в запрос к XML-данным. Посылая приложению
специльно сформированные запросы злоумышленник может раскрыть внутреннюю структуру
XML-базы и получить доступ к той информации, к которой ему обращаться нельзя.
Например он может повысить свои привилегии если ему удастся
произвести XPath-инъекцию в отношении файла хранящего пользовательские аккаунты.
Запросы к XML осуществляются с помощью XPath - не сложного языка, позволяющего
определять местонахождения информации в XML-структуре. Как и в SQL, в нём вы можете
устанавливать критерии поиска. В случаях когда данные приложения хранятся в виде XML-базы,
пользователь с помощью одного или нескольких параметров запроса может определять что из неё будет
извлечено и отображено на сайте. Эти параметры должны тщательно проверяться, чтоб атакующий
не смог изменить структуру изначального XPath-запроса и извлечь чувствительную информацию.
</div>
<p><b>Основные цели:</b> </p>
<!-- Start Instructions -->
Форма ниже позволяет работникам смотреть их персональную информацию включая данные
о зарплате. Ваш аккаунт - Mike/test123. Цель - просмотреть данные других работников.
<!-- Stop Instructions -->