1. Перевірка вхідних даних
2. Захист від XSS атак
3. Захист від CSRF атак
4. Захист від SQL-ін'єкцій
5. Захист файлової системи
6. Захист сесійних даних
7. Обробка помилок і виключень
8. Захист підключаються файлів

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

Перевірка вхідних даних

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

Завжди перевіряйте дані на стороні сервера, навіть якщо подібні перевірки виконуються в клієнтському JavaScript-коді. Де гарантія того, що зловмисник буде користуватися браузером з включеним JavaScript, та й взагалі браузером? Перевірка на стороні клієнта - це, безсумнівно, правильно і необхідно, але сліпо довіряти даним, які прийшли «з вулиці», ніколи не варто.

Захист від XSS атак

Cross-site scripting (XSS) атака заснована на впровадженні клієнтського коду в уразливі сторінки додатка. У самій же уразливості ноги ростуть як правило з того ж місця: відсутність перевірки призначених для користувача даних.

Наприклад, на сайті є форма, що дозволяє користувачам відправляти коментарі, які потім виводяться на сторінці. Якщо який-небудь користувач введе в формі JavaScript-код, який не буде відфільтрований і виведений «як є», то цей код буде інтерпретований браузером. А тут вже простір для діяльності воістину гігантських масштабів: починаючи від простого редиректу відвідувачів на потрібні URL, закінчуючи організацією цілих DoS-атак такими редирект.

Висновок: завжди фільтруйте користувача введення функціями, подібними strip_tags (), а перед віддачею контенту клієнту, пропускайте через htmlentities () або аналогічні.

Захист від CSRF атак

В разі Cross Site Request Forgery (CSRF) атаки зловмисники використовують уразливості в коді і довіру сайту до користувача для того, щоб виконувати будь-які дії без відома самого користувача. Такі атаки найчастіше успішно працюють з додатками, у яких неправильно спроектована бізнес-логіка обробки GET-запитів.

Згідно снандарту HTTP, GET-запити є Ідемпотентний, тобто, що не змінюють вміст. Іншими словами, програма не має змінювати будь-які були дані на стороні сервера у відповідь на GET-запит. Всупереч цьому правилу, багато розробників проектують додатки з точністю до навпаки. Наприклад, є фрагмент серверної логіки:

<? Php if (isset ($ _ REQUEST [ "name"], $ _REQUEST [ "amount"])) {// обробляємо запит і списуємо суму amount // з поточного користувача на користь name}

Тепер уявімо, що Боб, виконує атаку банківського сайту, де розташований рахунок Еліс, відправляє їй email або іншим чином підсовує наступне посилання:

<a href="http://bank.com/process.php?name=Bob&amount=1000"> няшная няшка </a>

Якщо Еліс в даний момент має незавершену сесію на bank.com, і перейде за цим посиланням, то логіка, наведена вище, спрацює, оскільки додаток вважає, що GET-запит виконується від імені Еліс.

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

<Img src = "http://bank.com/process.php?name=Bob&amount=1000" width = "1" height = "1" />

Природно, ніякої картинки браузер не виведе, однак GET-запит до bank.com буде виконаний, а більше і не потрібно.

Виходячи зі сказаного, можна зробити наступний очевидний висновок: ваше застосування повинне бути спроектовано таким чином, щоб тільки POST-запити могли змінювати дані, а той час як GET повинні використовуватися виключно для отримання даних. Ще одним очевидним моментом є те, що замість глобальної змінної $ _REQUEST необхідно використовувати $ _POST і $ _GET.

Також дуже хорошою практикою вважається додавання т. Н. CSRF-токена до всіх форм, що відправляються клієнтам. Всякий раз, коли додаток відправляє форму клієнту, в прихованому полі додається унікальний токен, пов'язаний з надісланими формою і обліковим записом користувача. При отриманні даних в POST-запит від клієнта, токен аналізується і тільки, якщо він коректний, виконується подальша обробка даних.

Захист від SQL-ін'єкцій

Коли виконуєте запити до БД, завжди користуйтеся PDO або похідними класами, а також параметризрвані запитами. наприклад:

<? Php $ sql = "SELECT * FROM users WHERE name =: name AND age =: age"; $ Stmt = $ db-> prepare ($ sql); $ Stmt-> execute (array ( ": name" => $ name, ": age" => $ age));

У наведеному прикладі перш ніж виконати запит, відбувається чистка (escaping) параметрів: name і: age від можливих вставок SQL-інструкцій. Таким чином виключається можливість виконання сторонніх SQL-команд, які можуть бути зовні у вигляді GET або POST параметрів.

Захист файлової системи

Завжди звертайте увагу на кодування операцій з файлової системою. Погляньте на наступний приклад:

<? Php if (isset ($ _ GET [ 'filename']) {$ filename = $ _GET [ 'filename']; header ( 'Content-Type: application / x-octet-stream'); header ( 'Content-Transfer -Encoding: binary '); header (' Content-Disposition: attachment; filename = " '. $ filename.'"; "); echo file_get_contents ($ filename);}

Використовуючи подібний підхід ви просто-напросто надаєте доступ до частини файлової системи сервера, а в особливо важких випадках конфігурації PHP - і до всієї ФС.

Захист сесійних даних

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

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

Обробка помилок і виключень

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

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

Щоб втрутитися в стандартний обробник помилок в PHP, можна користуватися вбудованою функцією set_error_handler (), хоча і з обмеженнями: вона не може перехоплювати помилки типів E_CORE_ERROR, E_STRICT і E_COMPILER_ERROR в тому ж файлі, де оголошений перехоплювач. Крім того, сам перехоплювач не може отримати доступу до помилок, які виникають всередині нього самого.

Відмінною практикою обробки виняткових ситуацій є використання механізму виключень: створення ієрархій винятків на базі класу Exception і коректної їх обробки в блоках try..catch.

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

PHP-сценарії часто включають в себе інші сценарії, використовуючи інструкції include і require. У деяких розробників є звичка закінчувати імена включення файл суфіксом '.inc' або чимось подібним, що відрізняється від '.php'. Небезпека тут полягає в тому, що веб-сервер може бути налаштований таким чином, що не розглядатиме .inc-файли в якості PHP-сценаріїв, а замість цього віддавати їх як text / plain. Таким от нехитрим чином хто завгодно зможе отримати доступ до вихідного коду вашої програми а то і файлів конфігурації з логінами / паролями підключення до БД або ще щось гірше. Чим це загрожує в разі чого, думаю, пояснювати не варто.

Завжди використовуйте стандартні розширення в іменах файлів сценаріїв, а також тримайте весь код вашої програми за межами Document Root.

джерело