1. можливі напади
2. Компрометація сайту і атаки XSS
3. SQL-ін'єкції
4. підключаються файли
5. Зберігання паролів в базі даних
6. Безпека сеансу
7. Перехоплення сеансу і фіксація сеансу
8. Проблеми розміщення декількох сайтів на одному сервері
9. Запобігання несанкціонованого доступу до бази даних
10. Довіра до даних користувача
11. Інформація до роздумів - захист веб-сайту

base19

7

У всьому світі в аеропортах можна знайти гасло "Security is not a joking matter" (Безпека - перш за все). Такий же гасло кожен системний адміністратор повинен був би закріпити поруч зі своїм сервером PHP. А кожен, хто підключається до сервера, що знаходиться в Інтернеті, повинен вживати належних заходів захисту або ризикувати втратою даних і навіть грошей через те, що зловмисні зломщики програмного забезпечення зможуть завдати шкоди, користуючись клавіатурою свого комп'ютера.

Другим емпіричним правилом створення захищеного сайту є наступне: "Мінімізуйте збиток". Що буде, якщо написана вами програма, яка, на вашу думку, є цілком надійною, фактично виявиться вразливою? Навіть просто для того, щоб залишатися в повній безпеці, обмежуйте збитки, який міг би завдати порушник, скориставшись цією вразливістю.

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

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

можливі напади

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

Зазвичай хакерами називають тих, кого було б правильніше назвати хакерами програмного захисту. У комп'ютерному співтоваристві хакерами захисту називають фахівців, які, користуючись вдалим збігом обставин або своїми навичками, долають захист комп'ютерних систем і завдають шкоди. А хакери - це програмісти, які вміють віртуозно складати програми і здатні не тільки розбиратися в складному коді, але і самостійно писати ефективний (і часто недоступний для розуміння сторонніх) код на багатьох мовах. Для програміста придбання звання хакера є честю, а звання зломщика програмного забезпечення, мабуть, означає, що його власник повинен стежити за нотатками в рубриці "Розшукується".

Не розуміючи того, наскільки принизливим є звання зломщика програмного забезпечення, багато початківці програмісти вступають на цей шлях, вдаючись до використання інструментальних засобів і сценаріїв, які вони знаходять в веб. Таких початківців зломщиків називають script-kiddie або на нашу кулхацкер. Ці люди часто самі майже не розуміють, що вони роблять. Зазвичай саме така категорія порушників стоїть за примітивними атаками, такими як компрометація сайту, XSS і SQL-ін'єкції.

Компрометація сайту і атаки XSS

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

Сторінка з простою формою додавання коментарів <? Php // Передбачається наявність MySQL-бази даних testing з root-доступом, // з таблицею comments, що має поля id і text $ link = mysqli_connect ( 'localhost', 'root', '', 'testing') or die ( 'Ні підключення'); // Додавання коментаря в базу даних $ comment = (isset ($ _ POST [ 'comment']))? $ _POST [ 'comment']: ''; if (! empty ($ comment)) {$ query = "INSERT INTO comments (text) VALUES ( '". $ comment. "')"; mysqli_query ($ link, $ query) or error_log ( "Значення '$ comment' не встаючи в бд"); } // Витяг коментарів з бази даних $ comments = ''; $ Query = "SELECT text FROM comments"; if ($ result = mysqli_query ($ link, $ query)) {while ($ row = mysqli_fetch_array ($ result)) {$ comments. = '<li>'. $ row [ 'text']. '&lt;/ li> '; }}?> <! DOCTYPE HTML> <html> <head> <meta charset = "utf-8"> <title> Основи PHP </ title> </ head> <body> <ul> <? Php echo $ comments ; ?> </ Ul> <form method = "post"> <textarea placeholder = "Введіть коментар" cols = "30" rows = "10" name = "comment"> </ textarea> <br> <input type = " submit "value =" Додати коментар "> </ form> </ body> </ html>

Ця програма реалізує систему коментарів в дуже примітивній формі (якщо ви вивчаєте моє керівництво по PHP з початку, то можливо ви ще не знайомі з операціями роботи з базами даних; якщо це так, то рекомендую вам повернутися до цієї статті після ознайомлення з відповідним матеріалом по MySQL ).

Читаючи цей код, досвідчений програміст починає відчувати себе не зовсім впевнено (пам'ятаєте - "Чи не довіряйте мережі"). Така програма приймає дані форми, які, відповідно до очікувань, повинні містити текст коментаря. Цей текст присвоюється змінної $ comment і зберігається в базі даних для відображення перед наступними відвідувачами. Якщо введені дані будуть такими, які ми очікуємо, то проблеми не виникнуть.

А тепер поставте себе на мить на місце кулхацкер і уявіть, що станеться, якщо у вхідних даних будуть міститися дескриптори HTML. Ця проста програма механічно вставить такі дескриптори в сформовану сторінку, і ця перекручена сторінка буде розгортатися в браузерах інших відвідувачів замість звичайної. Одним з дескрипторів, які можуть виявитися особливо небезпечними з точки зору захисту даних, є дескриптор <script>. Зломщик програмного захисту може вставити такий коментар:

Впровадження шкідливого JavaScript-коду

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

Рішення подібної проблеми полягає в тому, що вхідні дані слід попередньо обробляти з метою забезпечення безпеки. В даному випадку необхідно перетворити в якусь безпечну форму будь-які символи, які мають особливий сенс для браузера. На щастя, в мові PHP передбачений спосіб виконання саме такого перетворення. Функція htmlentities () перетворює символи <,>, "і & в представлення цих символів у вигляді так званих символьних сутностей HTML (такі як & lt;). У даному випадку необхідно змінити першу частину програми, для того щоб в ній використовувалася нова функція:

Код PHP ... $ comment = (isset ($ _ POST [ 'comment']))? htmlentities ($ _ POST [ 'comment']): ''; ...

Таким чином ми зможемо ліквідувати на своєму сайті дуже істотну пролом у захисті. Після додавання шкідливого коментаря він просто відобразиться на екрані, а не буде впроваджений в вихідну розмітку:

Екранування HTML-символів

SQL-ін'єкції

SQL ін'єкція один з поширених способів злому сайтів і програм, які працюють з базами даних, заснований на впровадженні в запит довільного SQL-коду. Щоб запобігти впровадження escape-символів в рядок, яка буде представлена MySQL, можна скористатися функцією mysqli_real_escape_string (). Для того щоб позбутися від небажаних слеш-символів, використовується функція stripslashes (). Нижче наведено видозмінений код з попереднього прикладу, що забезпечує захист від SQL-ін'єкцій:

Код PHP function cleanSQL ($ var, $ link) {$ var = mysqli_real_escape_string ($ link, $ var); $ Var = stripslashes ($ var); $ Var = htmlentities ($ var); $ Var = strip_tags ($ var); return $ var; } $ Comment = (isset ($ _ POST [ 'comment']))? cleanSQL ($ _ POST [ 'comment'], $ link): '';

підключаються файли

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

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

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

Щоб уникнути цих проблем, завжди використовуйте для підключаються файлів розширення імені .php і ніколи не давайте їм інші розширення, наприклад .inc, які не обробляються інтерпретатором PHP при безпосередньому зверненні до цих файлів.

Зберігання паролів в базі даних

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

Шифрування паролів не позбавлене недоліків, серед яких деяке збільшення складності і необхідність міняти пароль, якщо він забутий. Обійти цю проблему дозволяють, наприклад, підказки (hint) до паролів, що зберігаються в базі даних. Підказка - це якийсь текст, який Ви самі ввели на етапі створення облікового запису і допомагає згадати забутий пароль.

Для шифрування можуть бути використані функції md5 () або sha1 (), які повертають хеш-код рядка. При цьому використання цих функції в чистому вигляді теж є небезпечним, тому що Зараз стало досить просто з'ясувати результат виконання цих алгоритмів хешування методом "грубої сили" (підбором) для визначення оригінальних даних, що вводяться. Нижче представлено кілька способів, що дозволяють значно ускладнити зловмисникам завдання синтезу оригінальних паролів з хеш-коду:

• Вказівка ​​мінімально допустимої довжини пароля в формі. Заповнюючи форми реєстрації на різних сайтах ви напевно зустрічали підказки, типу "Пароль повинен бути не менше 6 символів". Це зроблено не просто так, в інтернеті є купа онлайн-сервісів, які представляють хеш-коди коротких паролів, які легко отримати, тому довший пароль є безпечніше. Наприклад, якщо в паролі можна вводити символи [az] і символи дефісу / підкреслення, то 5-значний пароль представлений 285 = 1.7e7 можливими комбінаціями, а 6-значний пароль 286 = 4.8e8.

• Додавання префіксів і суфіксів для паролів. наприклад:

  Код PHP // Простий пароль, якщо зберегти його хеш в базі даних, // то зловмисник може легко його ідентифікувати $ password = '123456'; $ InsertToDb = md5 ($ password); // Початкове значення хеша 'myprefix_123456_mysuffix' куди складніше обчислити $ suffix = '_mysuffix'; $ Prefix = 'myprefix_'; $ InsertToDb = md5 ($ prefix. $ Password. $ Suffix);

• Використання відмінних від md5 і sha1 алгоритмів шифрування через функції crypt () або hash ():

  Код PHP $ insertToDb = hash ( 'ripemd160', $ prefix. $ Password. $ Suffix);

Безпека сеансу

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

Перехоплення сеансу і фіксація сеансу

Перехоплення сеансу (session hijacking) - це отримання доступу до cookie чи кодом сеансу клієнта, а потім спроба використовувати ці дані. Фіксація сеансу (session fixation) - це спроба встановити власний ідентифікатор сеансу. Перехоплення і фіксацію сеансу легко відбити. Для забезпечення безпеки ми будемо відстежувати IP-адреса клієнта і тип використовуваного ним браузера за допомогою суперглобальних змінних.

У прикладі нижче інформація шифрується за допомогою функції md5, щоб закрити ці проломи в системі безпеки:

Перевірка на перехоплення сеансу session_start (); $ User_check = md5 ($ _ SERVER [ 'HTTP_USER_AGENT']. $ _SERVER [ 'REMOTE_ADDR']); if (empty ($ _ SESSION [ 'user_data'])) {session_regenerate_id (); echo ( "Відкрито новий сеанс, ідентифікатор користувача збережений."); $ _SESSION [ 'user_data'] = $ user_check; } If (strcmp ($ _ SESSION [ 'user_data'], $ user_check)! == 0) {session_regenerate_id (); echo ( "Попередження, дублюючий сеанс!"); $ _SESSION = array (); $ _SESSION [ 'user_data'] = $ user_check; } Else {echo ( "З'єднання перевірено!"); }

Коли браузер вперше запитує сторінку з прикладу, відкривається новий сеанс:

початок сеансу

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

Той же користувач оновлює сторінку, порушень в роботі немає

Результат на малюнку нижче було отримано в результаті копіювання файлу cookie з браузера Firefox в Opera на тій же клієнтської машині і спроби надіслати запит з колишнім ідентифікатором сеансу:

Спроба фіксації сеансу

Так як сценарій перевіряє тип браузера, а ми змінили Firefox на Opera, сеанс був створений заново для запобігання незаконного доступу до секретної інформації.

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

Проблеми розміщення декількох сайтів на одному сервері

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

Щоб надійніше убезпечити дані сеансу, можна змінити шлях до каталогу, де повинні зберігатися дані сеансу (значення параметра настройки session.save_path), за допомогою функції ini_set, як показано в прикладі нижче. Ви повинні забезпечити збереження цих даних за межами кореневого каталогу з веб-документами:

Код PHP ini_set ( 'session.save_path', '/ home / user / sessions /'); session_start ();

Сценарій з прикладу зберігає дані сеансу в каталозі / home / user / sessions /. Важливо, щоб каталог мав коректні права доступу (permissions), в іншому випадку інтерпретатор PHP не зможе записати дані сеансу. Зазвичай це означає, що каталог повинен бути доступний для запису групі www-data, але недоступний звичайним користувачам для читання і запису.

Запобігання несанкціонованого доступу до бази даних

Є кілька способів знизити ймовірність отримання зловмисником доступу до бази даних. По-перше, при виникненні проблем підключення до бази даних MySQL за замовчуванням видає повідомлення про помилку, яке містить інформацію про місцезнаходження бази даних, тобто IP-адреса сервера. Висновок цієї інформації слід придушити.

Щоб PHP-сценарій запобіг висновок стандартного повідомлення про помилку, перед викликами функцій звернення до бази даних слід помістити оператор управління виводу повідомлень про помилки - символ (@). У прикладі нижче виводиться більш потайливі повідомлення про помилку, за яким слід виклик функції die і завершення роботи сценарію:

Придушення виведення стандартного повідомлення про помилку $ link = @mysqli_connect ( 'localhost1', 'root', '', 'testing') or die ( 'Ні підключення');

Якби перед викликом функції не було оператора (@), з'явилося б повідомлення про помилку:

У повідомленні зазначено помилка

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

Довіра до даних користувача

Ви вже знаєте, що не варто сліпо довіряти даним, отриманим від користувача. Але які дані в дійсності є одними, а які - системними, яким можна довіряти? Перерахуємо різні види призначених для користувача даних і їх призначення:

GET

Дані, отримані методом GET, - призначені для користувача дані, які зазвичай надходять разом з формою і у вигляді параметрів URL.

POST

Дані, отримані методом POST, - призначені для користувача дані, які зазвичай надходять разом з формою.

Cookies

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

дані сеансу

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

Суперглобальний масив $ _SERVER []

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

Інформація до роздумів - захист веб-сайту

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

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

1. Computer Emergency Response Team (CERT) . Сайт CERT - один з найбільш широко відомих архівів офіційних описів інцидентів, пов'язаних з порушенням захисту. На цьому сайті публікуються рекомендації щодо усунення проблем захисту будь-якого типу, які включають дуже чіткий опис проблем, систем, схильних до впливу зазначених порушень, і можливих рішень.

2. Security-focus.com . Тут наведено великий обсяг інформації про всі аспекти комп'ютерної захисту, починаючи з правових і організаційних та закінчуючи технічними аспектами. Крім того, на цьому сайті базується відомий список розсилки з питань захисту, BugTraq (який можна знайти в розділі меню Forums).

3. Insecure.Org . Вельми добре зарекомендував себе як важливий інформаційний ресурс, власники якого не бояться надавати для загального доступу інструментальні засоби злому програмного захисту і обговорювати найдрібніші деталі багатьох способів компрометації засобів захисту даних (ці способи тепер прийнято називати "експлойта"). Цей сайт може надати виключно велику допомогу, якщо потрібно буде перевірити міцність захисту вашого власного сайту.

Оцініті статтю: