Лабораторна робота №2 – Захист Web

Мета роботи. Зробити огляд технологій атак рівня Web та можливостей захисту від них, вивчивши принципи їх реалізації.

Теоретичні відомості

Мережа Інтернет допускає двосторонній обмін інформацією. На відміну від традиційних засобів поширення інформації, включаючи телетекст, голосову пошту й автоматичне відправлення факсів, Web виявляється вразливою до можливості проникнення у веб-вузли і зміни їхнього вмісту через Інтернет.

Web усе частіше використовується для доступу до корпоративної інформації та інформації про вироблений компанією продукт, а також для здійснення різноманітних транзакцій. Тому порушення роботи веб-сервера може відбитися не тільки на репутації компанії, але й вилитися в значний матеріальний збиток. Використовувати веб-браузери зовсім просто, набудовувати і підтримувати веб-сервери відносно неважко, для створення веб-сторінок не потрібно особливої майстерності, але складність відповідного програмного забезпечення винятково висока. Веб-сервер можна використовувати як плацдарм для проникнення в будь-яку частину всього комп'ютерного комплексу компанії або організації. Типовими споживачами послуг Web є випадкові користувачі, які, зазвичай, не мають спеціальної підготовки (в області питань захисту).

Загрози безпеки Web:

1. Цілісність: Зміна даних користувача,впровадження "троянських програм", зміна інформації в пам'яті, зміна потоку повідомлень на шляху їхньої передачі

2. Конфіденційність : перехоплення даних у мережі, крадіжка інформації збереженої сервером або клієнтом, одержання інформації про конфігурацію мережі.

3. Доступність: припинення сеансу доступу користувача, навмисне переповнення дискового простору або оперативної пам’яті.

4. Автентифікація: імітація легального користувача порушником, фальсифікація даних.

Способи захисту потоку даних у Web

Один з методів захисту даних у Web полягає у використанні протоко-лу IPSec. Перевага використання IPSec у тому, що цей про-токол прозорий для кінцевого користувача і програмних додатків та забезпечує універсальне рішення. Крім того, протокол IPSec включає засоби фільтрації, які дозволяють використовувати її тільки для тієї частини потоку даних, для якої це дійсно необхідно.

Іншим (певною мірою універсальним) рішенням є розташування засобів захисту відразу над протоколом TCP .Прикладом сучасної реалізації такого підходу є стандарт SSL (Secure Socket Layer) та стандарт TLS (Transport Layer Security).

Використання cookie.

Cookie є рішенням однієї з проблем HTTP специфікації. Cookie – це певне значення в текстово-цифровому вигляді, яке сервер передає браузеру. Браузер буде зберігати цю інформацію й передавати її серверу з кожним запитом як частину заголовка HTTP. Одні значення cookie можуть зберігатися тільки протягом однієї сесії й знищуються після закриття браузера. Інші, встановлені на деякий період часу, записуються у файл. От як виглядає схема роботи хосту та клієнта через Інтернет.

Клієнт має такі обмеження для cookies:

• усього може зберігатися до 300 значень cookies;

• кожен cookie не може перевищувати 4 Кбайт;

• з одного сервера або домену може зберігатися до 20 значень cookies.

У випадку, якщо cookie приймає нове значення при наявному вже в браузері cookie зі збіжними даними, старе значення затирається новим. В інших випадках нові cookies додаються. Використання cookie – ефективне рішення збереження інформації користувача. Багато хто вважає їх небезпечними, нібито вони можуть заразити комп'ютер вірусом або украсти їхній пароль підключення до Інтернет. Як не дивно це твердження є помилковим. Але вважати cookie безпечними теж не можна. Для прикладу можна навести кілька прикладів їхнього використання та їх "небезпеки".

1. При використанні пошти з веб-інтерфейсом. Щоб не вводити па-роль при кожному вході на поштову скриньку, можна поставити галочку біля надпису "Зберегти пароль". Внаслідок чого інформація з логіном і паролем зберігається в cookie і при кожному вході на пошту пароль і логін встановлюється автоматично.

2. Схожий приклад можна привести й з Інтернет-магазинами. Заповнивши форму з даними про вашу кредитну картку вони зберігаються й при такій покупці вам не прийде заповнювати всі заново.

Це зручно з погляду користувача, але про безпеку даної технології не може бути й мови. Хоча деякі методи захисту все-таки використовуються.

• Інформація з cookie одного домену другого рівня не може бути прочитана іншими доменами.

• Якщо документ кешується, то інформація про cookie не кешується.

• Інформація cookie може передаватися за допомогою протоколу SSL.

Підмінити cookie набагато простіше, ніж їх прочитати. Хоча якщо мова йде про віддалений комп'ютер, то завдання стають рівносильними. Справа в тому, що підміна – це просте відправлення cookie на сервер, а читання дозволене тільки серверу. Для реалізації читання використається так звана технологія Cross Site Scripting(СSS або XSS, названий так, щоб уникнути плутанини з CSS, Cascade Style Sheets).

Cookie є частиною HTTP-заголовка. Повний опис поля Set-Cookie HTTP заголовка:

Set-Cookie:NAME=value;EXPIRES=date;DOMAIN=domain_name; PATH=path; SECURE

Мінімальний опис поля Set-Cookie HTTP-заголовка:

Set-Cookie: NAME=VALUE;

NAME=VALUE – NAME – змінна (ім'я cookie), VALUE – значення.

expires=DATE – час зберігання cookie (формат запису "expires=Monday, DD-Mon-YYYY HH:MM:SS GMT").

Приклад: expires=Friday,31-Dec-99 23:59:59 GMT;

Якщо цей атрибут не вказаний, то cookie зберігається протягом одного сеансу, до закриття браузера.

domain=DOMAIN_NAME – домен, для якого значення cookie дійсне.

Наприклад, "domain=ipm.kstu.ru".

Якщо цей атрибут опущений, то за замовчуванням використовується доменне ім'я сервера, на якому було задано значення cookie.

path=PATH – цей атрибут встановлює шлях до документів, для яких дійсне значення cookie. Наприклад, вказівка "path=/students/pupkin/" приведе до того, що значення cookie буде дійсне для всіх документів Васі Пупкіна в директорії /students/pupkin/. Для того, щоб cookie відсилалися при запиті будь-якого документа сервера, необхідно вказати кореневий каталог сервера ("path=/").

Якщо цей атрибут не вказаний, то значення cookie поширюється тільки на документи в тій же директорії, що і документ, в якому було встановлено значення cookie.

secure – якщо стоїть цей маркер, то інформація cookie пересилається тільки через HTTPS (HTTP з використанням SSL – Secure Socket Level), в шифрованому вигляді. Якщо цей маркер не вказаний, то інформація пересилається звичайним способом.

Встановлення cookie за допомогою HTML.

Простий спосіб виставити cookie – використовувати відповідний META-тег в заголовку <HEAD> </HEAD> будь-якого HTML документа. Це виглядає таким чином:

<META HTTP-EQUIV="Set-Cookie" CONTENT="NAME=value;

EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE">

За допомогою HTML можна встановити декілька cookie разом:

<META HTTP-EQUIV="Set-Cookie" CONTENT="NAME1=value1; EXPIRES=date1; DOMAIN=domain_name1; PATH=path1; SECURE"> <META HTTP-EQUIV="Set-Cookie" CONTENT="NAME2=value2; EXPIRES=date2; DOMAIN=domain_name2; PATH=path2; SECURE">

Коли запитується документ з http-сервера, браузер перевіряє свої cookie на предмет відповідності домену сервера (DOMAIN), шляху до документа (PATH), якщо час зберігання закінчився, то він віддаляється. У випадку, якщо знайдені значення cookie, що задовольняють всі умови, браузер посилає їх серверу у вигляді пари ім'я/значення:

Cookie: NAME1=STRING1; NAME2=STRING2 ...

У цьому випадку cookie набуває нового значення при наявному вже в браузері cookie із збіжними параметрами NAME, domain та path, то старе значення замінюється новим. У решті випадків нові значення cookie додаються до старих.

Використання expires не гарантує збереження cookie протягом заданого періоду часу, оскільки клієнт (браузер) може видалити запис через нестачу виділеного місця або будь-які інші причини.

Клієнт (браузер) може мати обмеження для cookies, наприклад:

- всього може зберігатися до 300 значень cookies;

- кожен cookie не може перевищувати 4 Кбайт;

- з одного сервера або домену може зберігатися до 20 значень cookie.

Якщо обмеження 300 або 20 перевищується, то віддаляється перший за часом запис. При перевищенні ліміту об'єму в 4 Кбайт коректність значення cookie страждає – відрізується частина запису (з початку цього запису) рівна перевищенню об'єму.

За наявності SSI на сервері, директивою <!--#echo var="..."--> можна враховувати будь-які змінні оточення, у тому числі і раніше задані значення cookie (змінна HTTP_COOKIE).

Приклади:

<!--#echo var="HTTP_COOKIE"-->

Вставлення всіх отриманих cookies в документ.

<!--#if expr="$HTTP_COOKIE=/user\=old/" –->

Перевірка чи міститься в cookies "user=old".

<META HTTP-EQUIV="Set-Cookie"CONTENT="<!--#echo var="QUERY_STRING"-->;">

вставляємо рядок запиту, надісланий методом GET для установлення cookie. Хід роботи

1. Навчитись використовувати cookie.

2. Використовувати cookie при роботі з сервером.

3. Сервер, отримавши це cookie, повинен видавати привітання, або повідомляти, що не знає такого клієнта.

4. Перевірте роботоздатність на сервері.

Зміст звіту

Ґрунтуючись на теоретичних відомостях та методичних вказівках до виконання експериментальної частини розв'язати з повним описом завдання. Скласти звіт по роботі.