Безпека PHP скриптів
У принципі, я не великий фахівець із безпеки. Та й тема настільки велика і багатогранна, що однією заміткою її охопити неможливо. Тому я спочатку писати не збирався. Але згодом з'ясувалося, що навіть очевидні речі невідомі багатьом програмістам. Тому я вирішив зібрати тут кілька рекомендацій базового рівня.
Основний принцип написання безпечних програм – це контроль даних, які надходять від користувача. Є кілька основних типів атак, яким може піддатися сайт, і ми їх зараз розглянемо.
Для боротьби із такими підстановками є кілька методів. Можна перевіряти ім'я файлу регулярками, але мені найближча функція basename() , яка відрізає від імені файлу все зайве. Якщо треба передавати файл разом із шляхом до нього, наприклад, themes/green/balloons.php, то перевірка буде складнішою. Тому я б рекомендував, таки, передавати тільки ім'я файлу. Або не передавати нічого.
SQL InjectionДля запобігання ін'єкціям потрібно дотримуватися двох простих правил:
1. Усі дані повинні потрапляти у запит лише через плейсхолдери. 2. Будь-які інші елементи, якщо їх треба додати в запит динамічно, повинні перевірятися за білими списками.
Для підготовлених запитів слід використовувати Як працювати з PDO? Повне керівництво.. перевірку за білими списками також розглянуто в цій статті. Хочеться лише додати, що захист від ін'єкцій не головне, а побічний продукт. Перше і головне завдання полягає у дотриманні правильного синтаксису, щоб якась кома в даних не порушила нам весь запит. А як наслідок, ми матимемо і захист від ін'єкцій.
EvalДивно, але багато програмістів не усвідомлюють того факту, що застосовувати eval до даних користувача - це все одно, щоособисто вручати злодіїві ключ від сейфа. Цією функцією і так слід користуватися дуже обережно, а на обробку їй введених користувачем даних і зовсім повинна бути жорстка заборона. При цьому слід розуміти, що дані користувача залишаються такими і після того, як користувач безпосередньо відправив їх у скрипт. Отримані з бази даних при наступних виконаннях скрипта, вони не стають менш небезпечними.
Mail InjectionНабула поширення останнім часом атака так само вже розглянута на цьому сайті, Mail injection. Робота з e-mail засобами PHP. Коротко можна сказати, що не можна допускати наявність перекладів рядка в даних, які потраплять до заголовків листа.
XSSТип атаки, що так само набув поширення порівняно недавно. На відміну від усіх попередніх, які атакують безпосередньо код скрипта, XSS атакує його функціональність: змушує виконувати користувача дії, потрібні хакеру, або краде його користувача, дані. Методи дуже різноманітні і численні, проте найбільш поширений і небезпечний - це впровадження JavaScript інструкцій у нешкідливі теги - , і так далі. Найбільш дієвим методом боротьби з цим є повна заборона на введення користувачем будь-якого HTML коду. Методів боротьби з цим досить багато, але слід пам'ятати, що функція strip_tags() не видаляє небезпечні вставки з дозволених тегів. тому особисто я волію користуватися функцією htmlspecialchars() , при виведенні будь-яких даних користувача. Але головна проблема при захисті від XSS - не сам метод, а послідовність його застосування. практично всі відомі атаки були зроблені в тих частинах сайту, де ніхто і подумати не міг про обробку даних користувача. А даремно. Обробляти їх треба скрізь ізавжди.
Також до цього розділу можна віднести атаки на сесії. Пов'язані з крадіжкою чи підстановкою ідентифікатора. докладніше можна почитати у розділі Сесії. Детальний опис роботи та пояснення механізму.
HTTP InjectionXSS вразливість, схожа на mail injection, тільки об'єктом атаки є не заголовки листа, а HTTP-заголовки. Атака екзотична, але знати про неї треба. Хакеру нічого не варто дописати до урла код з яваскриптом, який благополучно через змінну PHP_SELF або REQUEST_URI програміст сам вставить у свою сторінку.
Заливка файлів на серверОскільки сервер розрізняє файли з їхнього розширення, то розширення перевіряти обов'язково, поряд з іншими перевірками, такими, як Getimagesize та ін.