Вибачте, але накипіло.
Багато шишок вже набито на тему безпеки сайтів. Молоді фахівці, які закінчили ВНЗ, хоч і вміють програмувати, але в питанні безпеки сайту наступають на одні й ті ж граблі.
Цей конспект-пам'ятка про те, як домогтися відносно високої безпеки додатків у вебе, а також застерегти новачків від банальних помилок. Список складався без урахування мови програмування, тому підходить для всіх. А тепер дозвольте, я трохи побуду КО.
Отже, яким має бути безпечний сайт?
1. Про сервер
- FTP - не безпечний протокол, передає інформацію не в зашифрованому вигляді, тому варто вибрати або FTPS, або SFTP. Тепер за SSH, авторизація за ключами, що використовуються denyhost або його аналог, можна змінити дефолтний порт.
Все, що брутять, потрібно закривати. Якщо у вас є свій сервер і ви хоч раз дивилися в логи, ви напевно помічали численні спроби авторизації по SSH і по FTP, що йдуть з китайських IP.
- Поза межами повинні дивитися тільки дійсно потрібні порти, решту закриваємо фаєрволом.
- Використовуємо завжди актуальні версії софту, вчасно оновлюємося.
Недавня історія з OpenSSL тому підтвердження
- Обов'язково налаштувати логи і моніторити будь-яку підозрілу активність.
- Ніяких лівих папок і файлів а-ля .svn, .git, .idea, dump.tar.gz в корені проекту не повинно бути.
Були випадки, коли на сайтах клієнта залишалися архіви з базою і файлом у відкритому доступі. Те ж саме і з бекапами.
- Встановлюємо мінімально допустимі права на файли, ніяких 777.
- Динаміку, якщо можливо, краще виносити за межі кореня.
- Статика (js, css, image) повинна лежати окремо, в ідеалі порожній на іншому сервері.
- Якщо працюємо з важливими даними, використовуємо https/ssl з коротким expiration.
- Повідомлення про помилки на екрані не виводимо лише підказки користувачеві.
- Бекапи потрібно робити обов'язково і зберігати на іншому сервері.
2. Про вхідні дані
- У контролерах:
- Завжди фільтруємо вхідні параметри
- Використовуємо мінімально допустиме значення. Наприклад, якщо отримуємо число, то і приводимо до числа. Валідувати можна на клієнті і обов'язково - на сервері.
- Не забуваємо перевіряти змінні на граничні значення.
- Якщо дані зі списку, то обов'язково зіставляємо за безліччю допустимих значень.
- Для файлів за можливості перевіряємо MIME-тип, не довіряємо розширенням, це легко змінити.
- Не даємо безмежно додавати будь-які дані (наприклад, коментарі).
- Не дозволяємо завантажувати довгі рядки і важкі файли.
- У моделі:
- Для SQL-запитів використовуємо prepared statements.
- Оптимізуємо запити до бази - ніяких select в циклі.
- Не забуваємо про індекси.
- Складний пошук? Використовуйте пошукові рушії (ElasticSearch, Sphinx тощо).
- У поданні:
- Наводимо в потрібні сутності дані. Перевіряємо на xss, ніяких html тегів або js скриптів від клієнта.
- У відправленні форми або змін станів використовуємо унікальні для кожного користувача токени (csrf). Не хочете токенів, тоді перевіряйте HTTP_REFERER.
- Якщо використовуєте AJAX, не забувайте перевіряти дані і на вході, і на виході. У 99% випадків eval в JS - зло.
3. Про клієнта
Як казав Доктор Хаус, пацієнт завжди бреше.
Більшості клієнтів наплювати на свою безпеку.
- Валідація на клієнті - тільки для його зручності, обов'язково перевіряємо на сервері.
- POST так само легко підробляється, як і GET.
- Якщо є форма у відкритому доступі без капчі, в неї обов'язково почнуть писати спамери.
- Ускладніть авторизацію, кілька невдалих спроб входу - нехай вводять капчу.
- Хочете ще ускладнити? Прикручуємо двофакторну автентифікацію.
- Для підтверджень використовуємо одноразовий довгий токен, зав'язаний на конкретного користувача.
- Змушуємо клієнта робити складні паролі.
4. Про шифрування
- Нічого не зберігаємо у відкритому вигляді.
- Паролі - у вигляді хешів з сіллю, бажано перевіряти на криптостійкість і колізії.
- від ValdikSS Не використовуйте ні MD5, ні SHA1. Найкраще для паролів використовувати спеціалізовані хеш-функції, типу PBKDF2 або scrypt.
- Ніяких даних на клієнті, навіть в зашифрованому вигляді, тільки id-сесії в куках.
Список вийшов досить сумбурний. Приблизно так має виглядати невеликий конспект студента з безпеки веб-сайту. Напевно щось пропустив, щось можна буде додати. Пишіть у коментарі, що ще можна додати і ми складемо загальний чек-лист дійсно безпечного сайту.
