Новости

Реферат - Іллєнко Федір В'ячеславович Безпека web-сайтів

  1. зміст Вступ
  2. 1. Актуальність
  3. 2. Постановка завдання
  4. 3. Огляд досліджень та розробок
  5. 4. Запобігання Cross-Site сценаріїв атак
  6. 4.1 Перевірка достовірності даних
  7. 4.2 Санітарна обробка даних (нормалізація)
  8. 4.3 Екранування даних
  9. 4.4 Використання функції secureInnerData
  10. висновки

зміст

Вступ

Розробка нових ВЕБ-додатків часто фокусується на досвіді замовника і найбільш часто вона зводиться до забезпечення необхідної функціональності і якісного інтерфейсу для користувачів. Досить часто увага приділяється і системі серверної інтеграції додатків. Питаннями забезпечення безпеки в той же час часто нехтують або відкладають їх рішення на останню стадію - стадію тестування програми.

Багаторічний досвід різних компаній показує, що забезпечення безпеки ВЕБ-додатків має починатися ще на ранніх стадіях процесу проектування і розробки додатків [1].

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

Необхідно відзначити, що вартість і час, витрачений на реалізацію заходів безпеки на стадії розробки додатків набагато менше, ніж вдосконалення їх на етапі запуску в експлуатацію або виправлення вже «готових» додатків.

При розробці ВЕБ-додатків необхідно виконати наступні завдання:

  • Уникнути уразливості в додатках ще на ранніх стадіях розробки;
  • Зробити так, щоб розробники додатків створювали якісні та безпечні конструкції;
  • Якщо є додатки, розроблені не всередині компанії, необхідно вимагати від постачальників додатків експертний висновок з метою забезпечення безпеки.

1. Актуальність

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

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

2. Постановка завдання

Основними завданнями даної роботи є вивчення засобів безпеки веб-додатків, а так само більш докладний розгляд такий тип вразливості як XSS уразливості і постаратися знайти способи визначення даного виду атак. Що стосується класичних видів вразливостей так це:

  1. SQL injection
  2. PHP include
  3. XSS

Більш докладно вони розглянуті в розділі 3.

В рамках магістерської роботи планується отримання актуальних наукових результатів за наступними напрямками:

  1. Покращення алгоритмів тестування web-додатків.
  2. Написання власного xss сканера.
  3. Тестування сайту першокурсників факультету КНТ за допомогою xss сканера на предмет наявності вразливостей.

3. Огляд досліджень та розробок

Серед тестованих ресурсів зустрічаються веб-додатки, написані на різних мовах програмування; при цьому для кожної мови характерний свій набір найбільш значущих вразливостей (за даними дослідження групи Positive Technologies [2] . Більшість розробників воліють PHP: на ньому написано 63% всіх протестованих сайтів. Значні частки ASP.NET (19%) і Java (14%). Решта мов програмування зустрічаються набагато рідше. Розподіл сайтів - учасників тестування по лежачому в їх основі мови програмування візуально представлено на рис. 1.

1

Мал. 1. Статистика використання мов програмування при створенні динамічних Web-сторінок

Особисто у мене робота з сайтами почалася ще на третьому курсі. Разом з науковим керівником ми розробляли портал для першокурсників факультету КНТ. У планах це була свого роду бібліотека методичних забезпечень по всі спеціальностями та напрямками факультету. На момент написання магістерської роботи цей ресурс ще не закінчено. Його планується запустити і розмістити на хостингу офіційного сайту факультету. Так як даний проект вважається досить перспективним і корисним для студентів, очікується величезна кількість відвідувань і в зв'язку з цим ймовірність нападу ймовірність втрати інформації збільшується. Тому перш ніж викладати його на загальний доступ доцільно потурбуватися про безпеку самого ресурсу, щоб переглянути його на наявність вразливостей. Для цього постало завдання вивчити типи вразливостей і написати власний сканер для тестування сайту.

На зорі розвитку Інтернету практично кожен додаток містило велику кількість таких вразливостей. Але з кожним днем ​​ставало все складніше зустріти уразливості такого типу. І зломщики ставали все більш витонченими, що призводило до розробок нових типів і векторів атаки - один з цих типів атаки був виділений в окремий клас і отримав назву CSRF.

CSRF (англ. Сross Site Request Forgery - «Підробка міжсайтових запитів», також відомий як XSRF) - вид атак на відвідувачів веб-сайтів, який використовує недоліки протоколу HTTP. Якщо жертва заходить на сайт, створений зловмисником, від її особи таємно відправляється запит на інший сервер (наприклад, на сервер платіжної системи), який здійснює якусь шкідливу операцію (наприклад, переказ грошей на рахунок зловмисника). Для здійснення даної атаки, жертва повинна бути авторизована на тому сервері, куди відправляється запит, і цей запит не повинен вимагати будь-якого підтвердження з боку користувача, який не може бути проігнорований або підроблений атакуючим скриптом.

Це атака, при якій зловмисник намагається змусити браузер жертви створити запит до цільового сервера, потай від самої жертви. Схематично це предствалені на малюнку 2 [3] .

Схематично це предствалені на малюнку 2   [3]

Мал. 2 Схема отримання інформації від користувача
(Анімація: 45 кадрів, 5 циклів повторень, 96 кілобайт)

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

Небезпека CSRF в тому, що дана поведінка браузерів і всього HTTP протоколу є нормальним. Наприклад, адже нормально те, що сайт може на своїх сторінках містити картинки з іншого сайту. А браузеру невідомо заздалегідь що саме намагаються змусити його завантажити, дійсно картинку, або під виглядом даної завантаження буде виконано якийсь дію на цільовому сайті.

XSS (англ. Сross Site Sсriрting - «міжсайтовий скриптинг») - тип атаки на вразливі інтерактивні інформаційні системи в інтернеті, впровадження виконуваних на клієнтському комп'ютері шкідливих скриптів в видається системою сторінку. Специфіка подібних атак полягає в тому, що для атаки на сервер в якості засобу атаки використовується авторизований на цьому сервері клієнт. На жаль, міжсайтовий скріптові атаки відбуваються, в основному, тому, що розробники не в змозі забезпечити безпечний код [4] .

4. Запобігання Cross-Site сценаріїв атак

На щастя, провести XSS-атаку можна так само легко як і захиститися від неї. Перш за все, потрібно думати про те, що ви пишете. Перше правило, яке потрібно знати в будь-який веб-середовищі (будь то розробка, постановка задач, або виробництво) ніколи не довіряти даним, що надходять від користувача або від будь-яких інших сторонніх джерел. Кожен біт даних повинні бути перевірений на вході. Це золоте правило попередження XSS [9] .

З метою реалізації радикальних заходів безпеки, які запобігають XSS-атаки, ми повинні пам'ятати про перевірку даних, санітарної обробки даних, і екранування.

4.1 Перевірка достовірності даних

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

Якщо ви хочете перевірити номер телефону, наприклад, відкиньте будь-які рядки, що містять букви, тому що номер телефону повинен складатися тільки з цифр. Ви повинні також брати до уваги довжину рядка. Якщо ви хочете бути більш ліберальним, ви можете дозволити обмежений набір спеціальних символів, таких як плюс, дужки і тире, які часто використовуються при форматуванні телефонів.

(? Php // перевірка номера телефону України if (preg_match ( '/ ^ ((1 -)? \ D {3} -) \ d {3} - \ d {4} $ /', $ phone)) {echo $ phone. "це правильний формат.";}

При розробки сайту першокурсника ці моменти були враховані. Для захисту сайту від зловмисників виникає необхідність перевіряти введення даних відвідувачів. На екрані роботи з формою, при введенні інформації, виконується безліч перевірок. Перевірки поділяються на:

  • Заборони (помилки);
  • Програма видає видається повідомлення про необхідність обов'язкового внесення виправлення в даних;
  • Програма не дозволяє зберегти зміни до усунення причини виникнення проблеми;
  • попередження;
  • Програма видає повідомлення про можливий невідповідність (і, якщо це можливо, підсвічує поля даних, які потрапили під перевірку);
  • Програма дозволяє користувачеві продовжити роботу в програмі;

4.2 Санітарна обробка даних (нормалізація)

Санітарна обробка даних зосереджена на маніпулюванні даними, щоб переконатися, що вони безпечні. Відбувається видалення небажаних бітів даних і їх приведення до правильної формі. Наприклад, якщо на вході ви очікуєте просту текстову рядок, ви можете видалити будь-яку HTML розмітку з нього.

(? Php // видалення HTML з коментарів $ comment = strip_tags ($ _ POST [ "comment"]);

Іноді, перевірки даних і санітарна обробка / нормалізація можуть йти рука об руку.

(? Php // нормалізація і перевірка телефону США $ phone = preg_replace ( '/ [^ \ d] /', "", $ phone); $ len = strlen ($ phone); if ($ len == 7 || $ len == 10 || $ len == 11) {echo $ phone. "це правильний формат.";}

4.3 Екранування даних

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

(? Php echo "Ви шукали:". Htmlspecialchars ($ _ GET [ "query"]);

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

4.4 Використання функції secureInnerData

Використання стандартної функції secureInnerData, дозволяє захистити від атак типу SQL injection та XSS. Найчастіше їх проводять використовуючи GET або POST запити які не фільтруються на стороні сервера. Використовуючи цю функцію в якості фільтра входять даних, ви зможете частково убезпечити себе [8] .

Вихідний код функції secureInnerData

Алгоритм гранично простий:

  1. видаляємо прогалини з кінця рядка
  2. видаляємо прогалини з початку рядка
  3. перетворює спеціальні символи в HTML суті
  4. повертаємо очищені дані

Припустимо нам треба відфільтрувати параметр data який передається на сервер за допомогою GET запиту. Виглядати фільтрація буде так:

$ Data = secureInnerData ($ _ GET [ 'data']);

Про реалізацію

rtrim (), ltrim () видаляють з кінця і початку рядка відповідно:

"" (ASCII 32 (0x20)), символ пробілу.

"\ T" (ASCII 9 (0x09)), символ табуляції

"\ N" (ASCII 10 (0x0A)), символ перекладу рядка.

"\ R" (ASCII 13 (0x0D)), символ повернення каретки.

"\ 0" (ASCII 0 (0x00)), NUL-байт.

"\ X0B" (ASCII 11 (0x0B)), вертикальна табуляція.

htmlspecialchars () перетворює спеціальні символи в HTML суті:

'&' (Амперсанд) перетворюється в '&'

' "' (Лапки) перетворюється в '"' when ENT_NOQUOTES is not set.

'' '(Одинарні лапки) перетворюється в' '' тільки в режимі ENT_QUOTES.

'

'>' (Знак "більше ніж") перетворюється в '>'

Таким чином, можна убезпечити себе і свої дані від даного типу атак.

висновки

В роботі була проведена класифікація найпоширеніших WEB-вразливостей. Результати показали, що серед виявлених вразливостей на найбільшій кількості сайтів лідером є - Cross-Site Request Forgery (CSRF).

У роботі був проведений аналіз засобів безпеки web-додатків. В якості методу для подальшого розвитку досліджень в магістерській роботі вирішено працювати з методами, які аналізують вихідні коди web-додатки і конфігураційні налаштування.

Для того щоб знати, як убезпечити власний ресурс необхідно мислити як би з боку атакуючого і при цьому знати основні вимоги для успішного проведення атаки:

  1. Можливість змусити жертву перейти на сторінку з додатковим кодом. Або можливість модифікації зловмисником часто відвідуваних жертвою сторінок (як то кажуть, якщо гора не йде до Магомета, то ...).
  2. Відсутність захисту від CSRF на цільовому сайті.
  3. Користувач в момент атаки повинен бути авторизований для дії, яке ми хочемо виконати від його імені.

І на основі цих вимог необхідно спробувати побудувати захист.

При написанні даного реферату магістерська робота ще не завершена.Остаточне завершення: грудень 2013 року.Повний текст роботи та матеріали по темі можуть бути отримані у автора або його керівника після зазначеної дати.

Список джерел

Php // перевірка номера телефону України if (preg_match ( '/ ^ ((1 -)?

Уважаемые партнеры, если Вас заинтересовала наша продукция, мы готовы с Вами сотрудничать. Вам необходимо заполнить эту форму и отправить нам. Наши менеджеры в оперативном режиме обработают Вашу заявку, свяжутся с Вами и ответят на все интересующее Вас вопросы.

Или позвоните нам по телефонам: (048) 823-25-64

Организация (обязательно) *

Адрес доставки

Объем

Как с вами связаться:

Имя

Телефон (обязательно) *

Мобильный телефон

Ваш E-Mail

Дополнительная информация: