Достаточна ли защита сайта php?

Я недавно начал изучать php и, несмотря на то, что в интернете полно информации, вопрос по реализации надёжной системы авторизации пользователей для меня остаётся открытым. Далее я постараюсь показать как я вижу ситуацию и приведу свои (или не свои) рассуждения на счёт того, что смог найти.

Вот, допустим, я захотел сделать сайт, на котором размещена "стандартная" форма авторизации с использованием php, которая выглядит примерно так:
Главная страница — Страница с формой авторизации — php авторизации — файл с защитой от sql-инъекций — файл подключения к БД MySQL — в случае если всё ок, то в куки записывается логин + сгенерированный и сохраненный код доступа.
  • Стандартно в настройках доступ к БД - только из localhost
  • Используется SSL

Какие меры защиты я нашёл и хочу использовать
  • Логин и пароль хэшируются. Это кажется безопасным способом хранения данных, особенно если утечёт чисто база. Но это не защищает от MiitM, так как хэширование происходит на стороне сервера. Реализовывать хэширование на стороне клиента смысла мало, потому что тогда хэш становится паролем и "читающему" данные между клиентом и сервером по большому счёту всё равно хэш это или пароль в чистом виде. (ну или можно использовать хэширование на обеих сторонах).
  • php с защитой от sql-инъекций (хотя это можно прописать и в .htaccess)
  • Всё, начиная с php авторизации, защищено от прямого доступа через .htaccess. На самом деле это очень полезный файл, в который можно прописать многое

Конечно, если база данных не содержит ничего, кроме id, хэшированных логина и пароля, и у сайта не предусмотрено администрирование , то в таком случае безопасностью можно вообще пренебречь описанного выше достаточно.
Но, во-первых, мне до сих пор не попался на глаза сайт, где авторизация была бы реализована на чистом php (почему их нет, если всё так "легко"?, или я просто не внимательный?). Во-вторых, очень хочется прокачать свои знания и навыки в этой теме (поэтому буду благодарен, если напишете в комментариях в какую сторону по части безопасности копать), и в третьих, требования к безопасности постоянно усложняются, поэтому, если задумаюсь сделать серьёзный проект, такие знания очень пригодятся.

Собственно вопрос в том, насколько оправданно применять всё это в таком виде, какие важные моменты я упустил и что ещё мне следует поискать по этой теме?
  • Вопрос задан
  • 868 просмотров
Решения вопроса 1
@d-sem
Безопасность вещь комплексная и многое зависит от конкретной реализации. То что в одном месте закрывается (и то не факт, так как не известна реализация) один вектор мало влияет на общую безопасность.

Например, у Вас может быть супер защищенный сайт, но рядом у вас в соседней папке у вас лежит приложение, которое принимает команду из пользовательского ввода и подкладывает ее в exec(). Или веб-сервер настроен так, что по отдельным запросам на другие виртуальные хосты отдает содержимое конфиг файлов. Или ньюансы срезания углов при разработке (добавим более тщательную фильтрацию полей позже. ага). Или внезапно выяснилось что в версии вашего ЯП, конкретной библиотеке или субд есть фундаментальная уязвимость.

Хотите комплексно подойти к вопросу? Копайте в сторону изучения материалов от OWASP. Например, https://owasp.org/www-project-web-security-testing... Там достаточно много материалов для чеклистов. Или смотрите готовые чеклисты что проверять. Например, https://github.com/0xRadi/OWASP-Web-Checklist (я не говорю что это прям лучший чеклист, но посмотрите на число пунктов для быстрой оценки).

Хотите подойти еще комплексней? Начните с книги для новичков по поиску узявимостей - Ловушка для багов. Полевое руководство по веб-хакингу | Яворски Питер https://www.piter.com/product_by_id/196618476

А далее например обратите внимание на более сложную книгу как строить защиту в приложениях
Безопасно by design | Берг Джонсон Д., Деоган Д., Савано Д. https://www.piter.com/product/bezopasno-by-design
Там уже более основательно доводится доводится мысль как выстраивать защиту на основании архитектуры.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
Adamos
@Adamos
Главная страница — Страница с формой авторизации — php авторизации
Всё, начиная с php авторизации, защищено от прямого доступа через .htaccess.

Гуглим "php роутинг|маршрутизация".
И привязываться к конкретному Апачу сейчас - не стоит.
файл с защитой от sql-инъекций — файл подключения к БД MySQL

Если хочется чистого РНР - PDO и подготовленные запросы покрывают и то, и другое.
А вообще стоит поинтересоваться PSR и фреймворками - в них, внезапно, собираются не костыли и говнокод, а те самые best practices, которые вы не знаете, где почитать. Phptherightway вам вообще попадался?

Логин и пароль хэшируются

Логин-то на хрена? Чтобы при следующей регистрации не знать, использован такой или нет?
Ответ написан
FanatPHP
@FanatPHP
Чебуратор тега РНР
Что такое "файл с защитой от sql-инъекций"? Это звучит как "я никогда не заражусь спидом, потому что когда я занимаюсь сексом, то в соседней комнате у меня специальная тумбочка с кучей презервативов". Презерватив надо использовать в процессе, а не держать в отдельной тумбочке. Только тогда он поможет.

"хотя это можно прописать и в .htaccess" - это совсем какой-то идиотизм, причем заведомо вредный

"Всё, начиная с php авторизации, защищено от прямого доступа" - это тоже, хотя просто бесполезный

".htaccess. На самом деле это очень полезный файл" - полезность файла .htaccess сильно преувеличена. Это скорее костыль для калек, которые не умеют настраивать систему правильно. Не говоря уже о том, что в современных веб-серверах такого файла вообще нет.

В целом, из того что описано, помимо нескольких бессмысленных телодвижений, проблемы я здесь вижу по трем пунктам
1. Какая-то странная "защита от инъекций", которая скорее всего ни от чего не защищает, а только портит данные
2. Большой вопрос, как именно "генерируется" код доступа.
3. Вообще не упомянута защита от XSS. Ну и CSRF если уж на то пошло

Плюс вероятные дыры в конкретной реализации, когда на словах вроде правильно, но в коде реализовано криво. Типа location в качестве защиты страниц от доступа. Ну и в целом надо код видеть. Может быть там какое-нибудь гениальное incude $_GET['page'];
Ответ написан
@bacon
вопрос общий, а не только для php
1. Логин необязательно хэшировать, ну и главное хэшировать правильно, PBKDF2, Argon2 и т.п.
2 SSL как раз для защиты от MiitM
3 .htaccess не защищает от sql-инъекций
ну и авторизации и аутентификация - разные вещи

во-первых, мне до сих пор не попался на глаза сайт, где авторизация была бы реализована на чистом php
как это определил?

PS и самое главное, использовать готовые решения, а не свои велосипеды
Ответ написан
pro100chel
@pro100chel
Python && PHP Developer
Как уже многие писали - не стоит сейчас писать самому что-то уже давно реализованное по лучшим практикам. Как минимум стоит использовать PDO или же ORM.
А еще лучше использовать все это вместе с каким-нибудь популярным фреймворком по типу Laravel. Там уже все реализовано: от аутентификации и авторизации до запросов к сторонним API.

Если же хотите что-то свое написать без фреймворков - то по безопасности ничего конкретного нельзя посоветовать. Есть определенные правила, которых придерживаются большинство разработчиков.

- использовать на сайте SSL
- пароль в базе нужно хранить в хешированном виде.
и т.д.

Самые распространенные угрозы описаны в OWASP TOP 10. Почитайте на досуге.

Хешировать пароль на клиенте тоже правильно. Задача сервиса не только запретить доступ к сервису злоумышленникам, но и сохранить пароль клиента в тайне. Передавая пароль на сервер в открытом виде, пусть даже и по защищенному соединению, можно его отдать злоумышленникам. Как минимум запросы могут логироваться, и пароль в открытом виде будет храниться в логах. Злоумышленник может завладеть каким-либо образом доступом к серверу и украсть пароли тысяч или миллионов пользователей. Или же встроить в PHP скрипт определенный код, который будет пароли передавать на удаленный сервер (при владении доступом к серверу бекэнда).

Да, можно высунуть наружу только балансер или фронтэнд, а бекэнды держать без доступа к внешней сети. Но а если злоумышленником является разработчик/сотрудник, который может вытащить данные из этого сервера?

Хеширование пароля на клиенте является хорошей практикой. Facebook делает что-то похожее. В таком случае ни владелец сервиса, ни злоумышленник не смогут получить доступ к открытому паролю пользователя. Это защитит другие учетные записи пользователя (если он использует один пароль или главную часть пароля в других сервисах).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы