Привіт продовжую розглядати тему яка стосується безпеки РНР. На черзі сесії і куки. Cесії і куки (cookies) — це також два інших аспекти, які необхідно враховувати, коли ви створюєте РНР проект.
Вони не можуть нанести шкоду додаткам, і не такі небезпечні, але вони можуть скомпроментувати облікові записи доступу, типу логін – пароль.
З допомогою чого РНР процесор розрізняє користувачів? З допомогою індентифікатора, який являє собою 128 бітне число.
Якщо користувач вперше зайшов на сайт і РНР процесор це відзначив, то даному користувачу присвоюється випадкове унікальне число. Потім коли той самий відвідувач прийде на той самий сайт, то наступного разу він буде ассоціований з тим же числом (індетифікатором), в результаті чого програмі буде предявлена персональна область памяті.
Таким чином, якщо присутня можливість передати індентифікатор від одної сторінки (РНР–скрипта) до іншої, то ми зможемо розрізняти всіх користувачів.
Сесії і куки призначені для збереження відомостей про користувачів, при переході між сторінками. При використанні сесій дані зберігаються в тимчасових файлах на сервері. Файли з куки зберігаються на компютері користувача, і по запиту відсилаються браузером серверу.
Куки (coocies) — це текстові рядки, які зберігаються на стороні клієнта, і містять пари “імя–значення”, з якими повязаний URL, по якому браузер визначає чи потрібно відправляти куки на сервер.
Використання куки являється одним із самих популярних способів передачі індентифікатора ( даний спосіб працює по замовчуванню). Якщо змінну помістити один раз в куки, тоді її будуть отримувати всі скрипти.
Якщо у користувача куки включені, РНР сам помістить туда індентифікатор, і потім сам його звідти дістане. В такому випадку, в куки створюється змінна з іменем PHPSESSID (ІМЯ ЗМІННОЇ МОЖНА ПОМІНЯТИ), і значення індентифікатора.
Не тяжко здогадатись що в куки може зберігатись секретна інформація (номера банківських карток, паролі і т.д.), яка являється “лакомним кусочком” для зловмисників. В звязку з чим розробник повинен думати про те щоб інформація, яка зберігається в куки не була доступна постороннім.
Декілька методів захисту інформації яка зберігається в куки.
⇒ відправка куки по захищеному запиту
Необхідно для куки з конфінденційною інформацією, дозволити відповідати тільки на захищені запити http. Таким чином, перехоплення даних якими обмінюється клієнт і сервер, буде зробити тяжче.
Щоб реалізувати захищине зєднання, функції setcookies потрібно задасти шостий параметр, зі значенням рівним 1:
setcookies(“imia”,$value,time() + 7700, “/www/”,”site.ua”,1);
⇒ обмеження видимості області куки.
Спочатку доступ до кукі проходить із любого підкаталога, кореневого каталога, що може створити уязвимість в системі захисту. Для формування захисту, ми можемо обмежити доступ до кукі для всіх сторінок, крім сторінок які розташовані в вказаному каталозі
для прикладу /www.
setcookie(“imya”,$value,”/www”);
ми також можемо обмежити область видимості cookies до конкретної сторінки
setcookie(“imya”,$value,”/www/page1.php”);
⇒ обмеження доступу для доменів.
Список доменів, які мають доступ до куки повинен бути обмежений, що забезпечити нам додаткову безпеку. Для того щоб організувати доступ з кукі для одного домена із списку, необхідно задати четвертий параметр.
setcookie(“imya”,$value,”/www/page1.php”,”.mysite.ua”);
⇒ шифрування
<?PHP // створюємо вектор початкового стану для шифрування. $vector=mycript_criete_iv(mycript_criete_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB),MCRYPT_RAND)); $key = “qwe233jk312jx813893xk312″‘;// ключ для розшифровки $cook_name = “first”; $cipher = mcrypt_encrypt (MCRYPT_CAST_256, $key, $cook_name,MCRYPT_MODE_CFB,$vector); setcookie(“username”,$cipher, “/decrypt_first.php”); ?>
<?PHP // вектор початкового стану залишається таким же. $vector= mycript_criete_iv(mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB),MCRYPT_RAND); $key = “qwe233jk312jx813893xk312″‘; $decrypt_name = mcrypt_decrypt(MCRYPT_CAST_256, $key, $username,MCRYPT_MODE_CFB,$vector); echo(“$decrypt_name, ми раді бачити вас на нашій сторінці!”); ?>
Рекомендують одночасно використовувати всі вказані способи
RFI — це ще одна, досить проблемна уязвимість в безпеці, яку необхідно мати на увазі в випадку, якщо ви працюєте з РНР. RFI (Remote File Inclusion англ “включення видаленого файлу”) загрожує РНР, коли в додатку РНР є внутрішні файли.
Присутність загрози RFI можливе внаслідок присутності в РНР чотирьох функцій: include(), include_once(), recuire_once().
Приклад
<?PHP
$page = isset($_GET[‘page’]:’home’;
require $page . ‘.php’;
?>
В даному прикладі показано те що називається “фронт–контролер”, а іменно функція РНР яка звязує додаток і внутрішній файл.
Приклад
Допустим що у нас по адресу http://syte.ua/site присутня уязвимість, і що наш скрипт локалізований за адресою http://website.ua/index.php.
Зловмисник зробить такий запит
http://website.ua/index.php?page=http://syte.ua/site
В такому випадку файл буде запущений на виконання, і створить новий файл на локальному диску РНР–сервера. В принципі це являється серйозним порушенням безпеки, і дозволяє користувачам запустити любий зовнішній файл на нашому РНР сервері, а також завантажити такий файл на сервер.
Як ми можемо закрити такого виду уязвимість
Необхідно тільки поміняти декілька рядків в файлі конфігурації php.ini
allow_url_fopen — ця функція дозволяє не включати зовнішні файли в скрипт РНР
allow_url_include — функція провіряє, чи можуть функції include(), require() include_once(), and recuire_once() забезпечити доступ до “віддалених файлів”. По замовчуванню вона виключена.
Ці дві функції дозволяють коректно налаштувати безпеку зовнішніх файлів в проекті РНР. Необхідно уважно відноситись до любих даних, або інформації яка приходить з зовні, користувачам, паролям, зовнішнім файлам і т.д.
Це являється основним джерелом яке може нашкодити РНР
CSRF (Cross–site Request Forgery)
Також рекомендую дізнатись про CSRF (Cross–site Request Forgery – підробка міжсайтових запитів). Ця загроза працює через включення шкідливого коду, або посилання на сторінку яка звертається до веб–додатку, на якому пропонується користувачу аутоінтифікація. Якщо сесія для веб–додатка не вичерпалась, зловмисник зможе виконати несанкціновані команди.
Самим доступним способом захисту від CSRF (Cross–site Request Forgery) атак, може бути така процедура, коли веб–сайти повинні вимагати підтверження більшості дій користувача, і перевіряти поле HTTP_REFERER якщо воно вказано в запиті.
Ще один досить розпоширений спосіб захисту — процедура згідно якій, з кожною сесією користувача асоціується додатковий секретний ключ, призначений для виконання POST ЗАПИТІВ.
Користувач при виконанні будь–яких дій всередині кожного POST– запиту, висилає цей ключ, а сервер його перевіряє. Застосування даного методу дозволяє не здійснювати парсинг поля HTTP_REFERER, а значить немає необхідності враховувати більшість нюансів, можливих варіантів присутності або відсутності різних елементів даного поля.
Небезпечні функції
disable_function = dl | apache_child_terminate | prog_close |
exec | posix_kill | pfsockopen |
shell_exec | posix_mkfifo | leak |
system | posix_setpgid | ini_set |
passthru | posix_setsid | virtual |
popen | posix_setuid | set_time_limit |
pcloze | escapeshellarg | escapeshellcmd |
proc_terminate | suexec | proc_open |
В РНР є декілька функцій, які можуть бути відзначені як “небезпечні”. Вони можуть бути по настоящому небезпечні, якщо будуть керуватись хакером, так як це дасть можливість контролювати сервер і бази даних на ньому.
Так як ми повинні захистити ці функції любою ціною, РНР закладує в конфігураційний файл опцію disable_function. З її допомогою можно визначити небезпечні функції і призупинити їх при запуску сервера.
Необхідно мати на увазі, що основному РНР — серверу не потрібна велика кількість функцій, тому буде не погано призупиняти як можна більшу кількість функцій, які існують в РНР.
Функції які рекомендують зупиняти при запуску сервера.
Підсумок
Про безпеку РНР матеріалів в інтернтмережі присутньо дуже багато, як і створити публікацій на дану тематику, також можна дуже багато, навіть присвятити безпеці РНР цілий блог.
В даній категорї “Безпека в PHP” присутня інформація про самі розпоширені порушення безпеки, і про те що необхідно зробити щоб забезпечити стабільну роботу вашого РНР проекту.
В любому випадку головне запамятати що
1— не потрібно довіряти любій інформації, яка може попасти на ваш РНР додаток
2 – не потрібно користувачам давати доступ до всіх додатків
3 — необхідно фільтрувати дані користувачів і дані сервера
Інші публікації на Zura – Blog які стосуються “cookie”, і в цих публікаціях також знайдеться корисна інформація яка стосується “cookie”.
- Як працюють cookie в мові програмування php
- Що таке cookie, робота з cookie в мові програмування php
- PHP і Cookies історія куки використання tracking cookies
Відмінно хороша стаття, щоб отримати інформацію для моєї презентації на тему яку я збираюся представити в університеті.
Дякую за хороші слова, успіхів представити статтю в університеті
Привіт! Чи знаєте ви, чи роблять будь які плагіни для захисту
проти хакерів?
Звичайно що плагіни для захисту існують, найближчим часом опублікую пост про деякі з них, безпекою також займаються працівники северу які надають хостинг для вашого сайту, плагіни для обмеження кількості введення паролю існують, але користуватись ним потрібно дуже обережно, краще створити пароль найвищої складності, який складається з комбінації великих і малих літер, цифр, і знаків, пароль краще зберігати в себе в блокноті написаний ручкою, а не на компютері.