ІНФОРМАЦІЙНА СТІЙКІСТЬ
WEB-РЕСУРСІВ
1.
2.
3.
4.
ПЛАН
Загальні положення забезпечення безпеки
Web-ресурсу
Особливості стратегії захисту CMS систем
Використання сертифікатів SSL
Захист Web-русурсу від програмних ін’єкцій
• Публічні веб-сервери продовжують
залишатися об’єктами атак хакерів, які
хочуть за допомогою цих атак нанести
втрату репутації організації або добитися
яких-небудь політичних цілей. Вразливими
ОС вважаються всі версії Unix або Windows,
які використовуються як веб-сервер.
• Збиток від атаки. Можливий різний збиток –
від простого блокування роботи сервера до
заміни його вмісту порнографічним
матеріалом, політичними гаслами або
видалення груп файлів, а також розміщення на
сервері програм-троянських коней.
• Оцінка ризику. Публічні веб-сервери
зламуються майже щодня; загроза того, що
буде здійснена атака на веб-сервер – реальна.
Правила забезпечення безпеки
WWW-сервера:
•
•
•
•
•
•
•
•
розміщення веб-сервера в демілітаризованій зоні (DMZ);
видалення всіх непотрібних сервісів з веб-сервера, залишивши FTP (але тільки
якщо він потрібний насправді) і засіб безпечного підключення в режимі
віддаленого терміналу, такий як SSH;
відключення всіх засобів віддаленого адміністрування, якщо вони не
використовують шифрування всіх даних сеансів або одноразових паролів;
обмеження число людей, що мають повноваження адміністратора або
суперкористувача (root);
протоколювання всіх дії користувачів і зберігання системних журналів або в
зашифрованій формі на веб-сервері, або на іншій машині в інтpанеті;
проведення регулярних перевірок системних журналів на предмет виявлення
підозрілої активності;
видалення всіх непотрібних файлів, таких, як phf, з директорій, звідки можуть
запускатися скрипти .
видалення всіх стандартних директорій з документами, які поставляються з
веб-серверами, такими, як IIS і ExAir;
•
•
•
•
встановлення всіх необхідних виправлень програм на веб-сервері, що
стосуються безпеки, як тільки про них стає відомо;
якщо необхідно використовування графічного інтерфейсу на консолі
адміністратора веб-сервера, слід видалити команди, які автоматично
запускають його за допомогою інформації в .RC-піддиpектоpіях і замість цього
створити команду для його ручного запуску;
якщо машина повинна адмініструватися віддалено, потрібно вимагати, щоб
використовувалася програма, що встановлює захищене з'єднання з вебсервером (наприклад, SSH). Не потрібно дозволяти встановлювати з вебсервером telnet-з’єдняння або не анонімні FTP-з’єдняння (тобто ті, які
вимагають введення імені і пароля) з недовіpених машин. Непогано буде
також надати можливість встановлення таких з'єднань лише невеликому
числу захищених машин, які знаходяться в місцевому інтpанеті;
запуск веб-серверу в chroot-pежимі або режимі ізольованої директорії (у
цьому режимі ця директорія здається кореневою директорією файлової
системи і доступ до директорій файлової системи поза нею неможливий),
щоб не можна було дістати доступ до системних файлів;
•
•
•
•
використовування анонімного FTP-сервер (якщо він звичайно потрібний) в
режимі ізольованої директорії для директорії, відмінної від директорії, що є
коренем документів веб-сервера;
проведення всіх оновлень документів на публічному сервері з інтpанета.
Зберігати оригінали веб-сторінок на веб-сервері в інтpанеті та спочатку
оновлювати їх на цьому внутрішньому сервері, потім копіювати оновлені вебсторінки на публічний сервер за допомогою SSL-з’єднання. Якщо робити це
кожну годину, то можна буде уникнути того, що зіпсований вміст сервера буде
доступний в Інтернет довгий час.
періодичне сканування веб-сервер такими засобами, як ISS або nmap, для
перевірки відсутності на нім відомих вразливих місць;
організація спостереження за з’єднаннями з сервером за допомогою
програми виявлення атак (intrusion detection). Слід конфігурувати цю
програму так, щоб вона подавала сигнали тривоги при виявленні спроб
застосувати відомі атаки або підозрілих діях з веб-сервером, а також
протоколювала такі з'єднання для детального аналізу. Ця інформація зможе
згодом допомогти усунути вразливі місця і підсилити систему захисту.
Порушення безпеки
• перехоплення даних – перегляд даних
несанкціонованим користувачем;
• аналіз трафіка – перегляд інформації, що
стосується зв'язку між користувачами
(наприклад, наявність/відсутність, частота,
напрямок, послідовність, тип, обсяг обміну і
т.д.);
• зміна потоку повідомлень, видалення
повідомлень або порушення загального
порядку повідомлень у потоку;
Порушення безпеки
• відмова користувача від повідомлення,
заперечення відправником свого авторства в
пред'явленому йому одержувачем повідомленні
або заперечення одержувачем факту одержання їм
повідомлення;
• маскарад – прагнення порушника видати себе за
деякого іншого користувача з метою одержання
доступу до додаткової інформації або нав'язування
іншому користувачу помилкової інформації;
• порушення зв'язку, недопущення зв'язку або
затримка термінових повідомлень.
Типи атак на сайти
– Brute Force.
– Insufficient Authentication.
– Weak Password Recovery Validation.
– Credential/Session Prediction.
– Insufficient Session Expiration.
– Session Fixation.
Етапи атак, спрямованих на фіксацію
сесії
• 1. Встановлення сесії.
• 2. Фіксація сесії.
• 3. Підключення до сесії.
2. Особливості стратегії захисту CMS
систем
• Система керування вмістом (СКВ) або
Content Management System (CMS) – це
програмне забезпечення для організації
веб-сайтів чи інших інформаційних ресурсів
в Інтернеті чи окремих комп’ютерних
мережах.
Недоліки безкоштовних CMS
• - відсутність офіційної технічної підтримки, неможливість
формально урегулювати конфліктні ситуації;
• - технічну підтримку переважно здійснюють сторонні
розробники, проте знайти індивідуального спеціаліста, який
надасть послуги на гідному рівні важко;
• - функціональність значно нижче, ніж у платних CMS;
• - висока розширюваність, проте часто після внесення змін у
систему коректно обновити її буде неможливо;
• - рідко можна знайти безкоштовну CMS з документаціями та
інструкціями користувачів та розробників;
• - для налаштування системи користувач повинен мати достатню
технічну кваліфікацію, а саме знання html, основи
програмування та роботи з базами даних.
Приватні вектори атак на сайт
• 1. Експлуатація вразливостей скриптів, плагінів і CMS.
• 2. Атака на панель адміністратора (Брутфорс або
крадіжка пароля).
• 3. Злом через FTP (Брутфорс пароля, перехоплення
пароля, крадіжка ключів, атака MITM).
• 4. Злом через SSH (Брутфорс пароля, перехоплення
пароля, крадіжка ключів, атака MITM).
• 5. Злом через «сусідів» по хостингу.
• 6. Атака на панель адміністратора хостингу
(брутфорс пароля, експлуатація вразливостей).
• 7. Експлуатація вразливостей операційної системи і
сервісів хостингу.
Захист від злому
• Захист панелі адміністратора від
несанкціонованого доступу
• Захист від інших варіантів злому
• Захист від атак з HTTP (через веб)
3. Використання сертифікатів SSL
• Технологія SSL забезпечує кращий захист і
збереження конфіденційності інформації, на відміну
від незашифрованого веб-з’єднання.
• SSL (Secure Sockets Layer, рівень захищених сокетів)
– криптографічний протокол, який забезпечує
встановлення безпечного з'єднання між клієнтом і
сервером.
• Протокол забезпечує конфіденційність обміну
даними між клієнтом і сервером, що
використовують TCP/IP, причому для шифрування
використовується асиметричний алгоритм з
відкритим ключем.
Підпротоколи SSL в моделі TCP/IP
Властивості "безпечного каналу"
протоколу SSL
• Канал є приватним.
• Канал аутентифікований.
• Канал надійний.
Покрокова установка SSL-з'єднань
Протоколи запису
• протокол рукостискання (Handshake
Protocol);
• протокол тривоги (Alert Protocol);
• протокол зміни шифру (The Change Cipher
Spec Protocol);
• протокол даних додатку (Application Data
Protocol).
Коди Alert Protocol
Alert Code
Alert Message
0
10
20
21
22
30
40
42
43
44
close_notify
unexpected_message
bad_record_mac
decryption_failed
record_overflow
decompression_failure
handshake_failure
bad_certificate
unsupported_certificate
certificate_revoked
Коди Alert Protocol
45
46
47
48
49
50
51
60
70
71
80
90
100
255
certificate_expired
certificate_unknown
illegal_parameter
unknown_ca
access_denied
decode_error
decrypt_error
export_restriction
protocol_version
insufficient_security
internal_error
user_cancelled
no_renegotiation
unsupported_extension
• Протокол даних додатку (Application Data
Protocol)
• Помилки в протоколі SSL
• Unsupported_Certificate_Type_Error
• No_Cipher_Error
• Bad_Certificate_Error
• No_Certificate_Error
• SSL-сертифікат – це цифровий документ, який
дозволяє серверу та клієнту перевіряти справжність
один одного.
• Сертифікат Shared SSL – це безкоштовна версія,
встановлюється на виділену IP-адресу клієнта, але
при цьому повну безпеку гарантувати він не може.
• Сертифікати Trusted SSL – це сертифікати,
розроблені спеціальними Центрами Сертифікації;
на них вказуються цифрові підписи, термін
придатності, ім`я власника та інша інформація для
ідентифікації.
Схема роботи SSL
• браузер посилає веб-серверу запит на безпечну
сторінку (зазвичай "https://");
• веб-сервер відсилає свій відкритий ключ разом із
сертифікатом;
• браузер перевіряє чи дійсно цей сертифікат
являється Trusted SSL, чи дійсний він досі, і чи
пов’язаний сертифікат з даним сайтом;
• потім браузер використовує відкритий ключ
(отриманий від веб-сервера) і, використовуючи
довільне симетричне шифрування, посилає запит
серверу на канал, по якому передаються дані в
зашифрованому вигляді;
Схема роботи SSL
• веб-сервер дешифрує ключ симетричної
шифровки, використовуючи секретний
ключ;
• веб-сервер відправляє html-документ, на
який був запит, і "звичайні http-дані" лише
після шифрування їх симетричним ключем;
• використовуючи свій симетричний ключ,
веб-браузер дешифрує отримані дані та
html-документ і відображає інформацію.
4. Захист Web-русурсу від
програмних ін’єкцій
Плейсхолдери – підстановка даних
Будь-які дані повинні потрапляти в запит не
безпосередньо, а через якогось
представника, додайте вирази.
Запит пишеться в такому вигляді,
SELECT * FROM table WHERE id>? LIMIT?
а дані додаються й обробляються окремо.
Ідентифікатори і ключові слова – білі списки
Переважна більшість статей, присвячених
ін'єкціям, абсолютно упускають цей момент з
уваги. Але реальність така, що в ній ми
стикаємося з необхідністю підставляти в запит не
тільки дані, але й інші елементи - ідентифікатори
(імена полів і таблиць) і навіть елементи
синтаксису, ключові слова. Нехай навіть такі
незначні, як DESC або AND, але вимоги до
безпеки таких підстановок все одно повинні бути
не менш суворими.
Робота з плейсхолдерами
Для початку потрібно розуміти, що існує два варіанти реалізації
плейсхолдеров:
серверний;
клієнтський.
У першому випадку запит йде на сервер з плейсхолдерами, а дані
відправляються окремо від нього (native prepared statements –
«рідні» підготовлені вирази) Тобто, обробка плейсхолдеров
здійснюється самою СКБД, на сервері. Для стислості будемо
використовувати найменування «серверні плейсхолдери».
У другому випадку дані форматуються і підставляються в рядок
запиту на місце плейсхолдерів прямо на клієнті, формуючи
класичний SQL запит, який потім іде в базу звичайним порядком.
Серверні плейсхолдери
По факту, SQL запит являє собою програму.
Повноцінну програму - з операторами, змінними та
рядковими літералами. Проблема ж полягає в тому,
що ми цю програму збираємо динамічно, на ходу. На
відміну від наших PHP скриптів, які написані раз і
назавжди, і не змінюються на основі даних, що
надходять, SQL запит щораз динамічно формується
заново. І, як наслідок, невірно відформатовані дані
можуть зіпсувати запит, або навіть поміняти його,
підставивши непередбачені нами оператори. Власне,
саме в цьому і полягає суть ін'єкцій.
Основні недоліки наявних бібліотек
• багатослівність;
• відсутність деяких корисних плейсхолдерів;
• неможливість отримати класичний SQL
запит для цілей налагодження;
• можливі проблеми з продуктивністю.
З яких елементів взагалі може
складатися запит
• INSERT INTO `db`.`table` as` t1` VALUES ('string',
1,1.5, NOW ());
• У запиті можна виділити три основні групи
елементів:
• власне елементи мови SQL – оператори,
вбудовані функції, змінні та ін.;
• ідентифікатори (імена баз даних, таблиць і
полів);
• літерали (дані, підставлені безпосередньо в
запит) кількох різних типів.
Форматування ідентифікаторів
• - ідентифікатор повинен бути укладений у
зворотні одинарні лапки (backticks);
• - якщо така лапка зустрічається в імені, то
вона повинна бути екранована
подвоєнням.
Форматування рядкових літералів
• 1) рядок має бути укладена в лапки (одинарні
або подвійні, але оскільки подвійні можуть
бути використані для ідентифікаторів, краще
завжди використовувати одинарні);
• 2) в рядку повинні бути екрановані
спецсимволи за списком. Для цього API надає
спеціальну функцію. Для коректної роботи цієї
функції має бути правильно задана кодування
з'єднання.
Форматування чисел
• 1) режим STRICT MODE в mysql, який,
будучи включеним, в деяких випадках
видаватиме помилки при спробі видати
рядок за число;
• 2) оператор LIMIT, в якому використання
рядків не передбачено зовсім;
• 3) зауваження фахівців по mysql про те, що
тип літерала дуже важливий, і грає роль
при плануванні та виконанні запиту.
«Ледачі плейсхолдери»
• В якості базового методу створення
плейсхолдеру можна обрати sprintf.
Загалом, sprintf дозволить не турбуватися
про будь-який тип даних окрім рядків.