Захист сайту від злому

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

Наприклад, візьмемо популярний рушій: Joomla. Є замовлення, є завдання з використанням цього рушія. Верстальник зверстав дизайн, програміст застосував верстку до шаблону сайту, і ось, починаючи з цього етапу, потрібно бути надзвичайно обережним, оскільки цими діями все не закінчується. Замовнику обов’язково знадобиться якась додаткова можливість, якої немає в поточному шаблоні, і програмісту, виходячи з цього, доведеться написати свій модуль. Втім, можна і не писати, а знайти вже готовий і спробувати прикрутити його до сайту.

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

Насправді, варіантів може бути два.

Перший: програміст просто не врахував усіх умов роботи модуля.

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

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

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

Ну, з модулями розібралися. Усе має бути максимально зрозуміло. Далі я опишу основні прийоми, які можна і потрібно застосовувати у своєму коді, незалежно від того, чи буде цей код лише компонентом, чи набором файлів рушія.

Під час написання скрипту необхідно враховувати будь-які умови. На кожному етапі оновлення потрібно перевіряти ваш скрипт на вразливість. Особливо потрібно звернути увагу на скрипти, які обробляють зовнішні дані, зазвичай це дані, надіслані методом POST або GET. Пам’ятайте, що в змінних можуть міститися будь-які дані! Наприклад, у вас є сторінка, яка обробляє дані GET і звертається до бази даних.

Якщо в змінну вписати символ ', то станеться помилка, оскільки цей символ розмежовує змінні в запиті SQL. У результаті в браузері з’явиться повідомлення про помилку, номер рядка та ім’я файлу, де сталася помилка. Далі зловмисник намагатиметься скласти запит, у результаті якого зможе вивести потрібну інформацію. Що зробити, щоб позбутися такої вразливості? Найпростішим варіантом буде ввімкнення функції «magic quotes» на сервері. Або, якщо це неможливо — використовувати функцію
mysql_real_escape_string перед обробкою даних запиту.

Наступна – найпоширеніша помилка, яку допускають програмісти — недостатня кількість перевірок умов. Наприклад, візьмемо такий код:

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

INSERT INTO users (name, email, type, password) values ('$_POST['name']', '$_POST['email']', '$_POST['type']', md5($_POST['password']))

Зауважу, що в цій таблиці зазвичай зберігаються всі користувачі сайту. Вони відрізняються за типом. Якщо звичайний користувач матиме тип 8, то адміністратор, наприклад, буде 1. Отже, якщо під час реєстрації ми змінимо вибір типу облікового запису, то зможемо зареєструватися як адміністратор, тому правильніше було б зробити такий запит:

$result = mysql_query("INSERT INTO users (name, email, type, password) values ('$_POST['name']', '$_POST['email']', '8', md5($_POST['password']))");

Пам’ятайте, що якщо в коді сторінки ви присвоїте значення , це не означає, що ніхто не натисне на кнопку. Навіть досвідчені користувачі зможуть викликати у своєму браузері Firebug і встановити своє значення. Те ж саме стосується і GET-запитів. Якщо на сайті не видно посилання ololo.com/admin/?login=success, це не означає, що користувач не зможе за ним перейти.

Для зберігання паролів краще використовувати не просто MD5($password), а MD5(MD5($password)). Не робіть безкінечні сесії, встановлюйте обмеження за часом життя сесій. Шлях до адмінки обирайте на свій розсуд, не залишайте його стандартним типу /admin або /administrator. Рано чи пізно людина, яка знає шлях до адмінки та хеш пароля, зможе відкрити собі доступ. Не зайвим буде написання функції перевірки на DoS-атаки.

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

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