2. Паролі
Паролі в веб-системах являються першою ланкою безпеки, від якої залежить стійкість веб-додатків та веб-систем до взлому.
2.1. Надійність паролів
Враховуючи важливість паролів, особливо при роботі з різними веб-системами, котрі надають персоналізовані послуги користувачам, а також при роботі з банківською та іншою важливою інформацією, потрібно приділити максимальну увагу системі паролів.
Зокрема потрібно підібрати паролі достатньої довжини. Зараз можна рекомендувати, щоб паролі користувачів були не менше восьми символів. При цьому бажано використовувати (і ставити відповідну вимогу) символи різних регістрів, цифрові символи, символи пунктуації та спецсимволи.
Щоб унеможливити меншу кількість символів, потрібно або генерувати паролі програмним чином і надавати їх користувачам, або перевіряти кількість введених символів паролю (і виводити відповідне повідомлення користувачу). При реєстрації користувача, потрібно не допускати його до завершення процесу реєстрації доти, доки не буде введений пароль відповідної (мінімальної) довжини (у випадку, якщо паролі не генеруються програмно).
Також потрібно приділити велику увагу самій програмній системі роботи з паролями, в тому числі процесам обробки, зберігання та передачі паролів.
2.2. Обробка паролів
При обробці потрібно унеможливити збій в програмі, коли користувач ввівши один пароль, отримував доступ до іншого аккаунту, або отримував інші права (вищі ніж його поточні або навіть права адміністратору).
При зберіганні паролів, можна зберігати їх в зашифрованому вигляді. В такому випадку, якщо якимось чином виник витік даних (або виник неавторизований доступ до даних з паролями системи), тоді зловмисник не зможе використати паролі ніяк інакше, як розшифрувавши закодовані дані. Що буде потребувати значних часових та машинних ресурсів (при використанні надійних алгоритмів шифрування).
При передачі даних потрібно уникати (і якщо це не дозволяє поточна задача, то мінімізувати) передачу паролів у відкритому вигляді (через GET запит). Намагайтеся передавати паролі завжди POST запитом.
При роботі з банківською та іншою важливою інформацією, бажано користуватися захищеною передачою даних (https) з використанням криптографічних систем (використання SSL). При чому можна шифрувати як паролі до веб-систем, так і всю іншу інформацію.
2.3. Основні проблеми
Основними та широко розповсюдженими проблемами з паролями в веб-додатках і системах являються проблеми зберігання та передачі паролів.
Зберігання паролів.
Зберігання паролю в файлі програми-скрипта відкритим текстом є ненадійним засобом. Його можуть продивитися:
- Користувачі, які мають доступ зсередини веб-сервера.
- Користувачі, які отримали доступ до веб-сервера ззовні, використавши помилки у програмному забезпечені.
- У випадку, коли пароль зберігається у файлі з некоректними правами доступа, що робить можливим отримати пароль через браузер.
Можливі вирішення даної проблеми:
- При взаємодії з Базою Даних можна діставати пароль для перевірки з самої БД. У цьому випадку просто так пароль переглянути не вийде. Якщо зловмисник і проникне на жорсткий диск вашого сервера, то максимум, що він зможе зробити - це дістати пароль від Бази Даних, і діставши до неї доступ, забрати пароль звідти. Але дістатися до БД також ускладнено, при достатній політиці безпеки адміністратора БД, що буде додатковою перепоною на шляху зловмисника.
- У випадку, якщо вам усе-таки потрібно покласти пароль у сам скрипт, то виходячи з того, що скрипт являється звичайним текстовим файлів, котрий можна прочитати, ви можете використати наступний метод. Для забезпечення надійного збереження пароля у файлі, необхідно зашифрувати його функцією crypt. І при перевірці введеного паролю, шифрувати його функцією crypt та перевіряти з зашифрованим паролем.
Передача паролів.
Паролі можуть передаватися через GET та POST запити.
Вибір методу пересилання дуже важливий з погляду безпеки. Нерідко можна зіткнутися з тим, що чимало веб-додатків передають пароль методом GET, хоча паролі потрібно передавати методом POST.
Різниця між цими методами полягає втім, що при запиті методом GET передані параметри (в тому числі пароль) є відкритими, тому що вони являються частиною URL, а при запиті методом POST - параметри передаються усередині тіла запиту.
При використанні метода GET, потрібно пам’ятати, що в логах сервера можуть залишитися ваші паролі. І якщо зловмисник дістанеться до логів сервера, тоді він зможе дізнатися паролі користувачів системи і навіть адміністратора. При передачі пароля методом POST параметри не являються частиною URL і не записуються у логи веб-сервера.
Тому завжди намагайтеся передавати паролі POST запитом.
2.4. Зберігання паролів
Як вже зазначалося, для надійного зберігання паролів, зокрема у файлах, необхідно їх шифрувати. Для цієї задачі найбільш часто використовують хеш-функції. Серверні мови програмування, такі як Perl та PHP, підтримують різноманітні алгоритми шифрування, в тому числі хеш-функції (для проведення хешування), такі як DES, MD4, MD5, SHA1 та інші.
В Perl найбільш часто застосовується функція crypt(), що реалізує алгоритм шифрування DES. Тому для надійного та безпечного зберігання пароля в файлі скрипта, або у зовнішньому файлі, потрібно захешувати його функцією crypt(). Для пароля MbQGWw4s зашифрований crypt() пароль буде виглядати як Cd46XY120Htc2. При використанні crypt() потрібно враховувати, що функція використовує лише перші 8 символів паролю.
При розміщенні зашифрованого пароля в середині скрипта, алгоритм роботи для програми на Perl буде наступним:
#!/usr/bin/perl
$enc_password = "Cd46XY120Htc2";
$salt = substr($enc_password,0,2);
# отримуємо пароль від користувача в $password
# та перевіряємо його
if (crypt($password,$salt) eq $enc_password) {
# пароль вірний
}
else {
# пароль невірний
}
Якщо ви зберігаєте зашифрований пароль в середині скрипта, то отримати доступ до паролю просто так не вийде, бо потрібно буде отримати доступ до вихідних кодів скрипта, щоб прочитати пароль, а для цього потрібно мати доступ до файлової системи. Звичайно можуть бути уразливості на сайті чи у веб сервері, що дозволять прочитати вихідні коди додатку (і відповідно пароль), але при відсутності даних уразливостей (в чому потрібно переконатися), даний варіант зберігання паролів є достатньо надійним.
Якщо ж ви зберігаєте зашифрований пароль (чи декілька паролів) в окремому файлі, то потрібно переконатися, що даний файл з паролями не є доступним для читання з браузеру. Для цього вони повинні мати відповідно налаштовані права (і, при необхідності, розширення файлів), щоб вони були доступні для читання лише для локальних скриптів, але не з браузеру.
В будь-якому разі використання шифрування паролів робить їх зберігання більш безпечним, що покращує безпеку веб додатків у цілому. І навіть при витоку інформації про зашифрований пароль, на його взлом знадобиться дуже багато часу (при використанні складних паролів достатньої довжини, про що я писав в п.2.1).
