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

Question

[BYjhng]

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

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

• Стандартно в настройках доступ к БД - только из localhost
  
• Используется SSL
  

Какие меры защиты я нашёл и хочу использовать

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

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

Собственно вопрос в том, насколько оправданно применять всё это в таком виде, какие важные моменты я упустил и что ещё мне следует поискать по этой теме?

Comments

[Дмитрий]

Забыть что есть жс, все что приходит от юзера валидировать, на чистом пхп было давно, сейчас новомодный жс везде, знать основы хтмл по формам и пхп, ну и использовать подготовленные запросы, настроить сессии, использовать новые версии пхп и сервера

[WapSter]

Хз как на php, но сейчас есть куча ORM для работы с бд, в которых встроена защита от sql инъекции. Ну а вообще тебе стоило бы прочитать пару тройку специализированных статей по этому вопросу, а то ты сюда пришел с кашей в голове

[FanatPHP]

WapSter, каша в голове как раз после прочтения статей и появляется.

[Vitsliputsli]

WapSter, а что имеется ввиду под встроенной защитой от sql-инъекций в ORM? То что они используют подготовленные запросы, так им там ничего и не надо встраивать, или что-то другое?

[WapSter]

Vitsliputsli, касается конкретной ORM и ее документации, обычно пишут, какие встроенные методы безопасны, а какие применять с осторожностью

[Vitsliputsli]

WapSter, понял про что вы, тем не менее в ORM нет встроенной самописной защиты, просто нормальный код, как правило. Безопасные или небезопасные методы подразумевается, что если метод использует SQL написанный пользователем, очевидно ORM не сможет гарантировать, что там не будет инъекций. А защиты по прежнему только две: prepared statements или экранирование, причем последнее может быть реализовано на разных уровнях: в PDO, в языке, либо можно самому что-нибудь накалякать и надеяться что пронесет, но ORM так не делают насколько я знаю.

[FanatPHP]

Vitsliputsli, экранирование - это не защита.

[FanatPHP]

Впрочем все эти разговоры ни о чем.
Автор по тихому слился, то есть каша в голове только гуще стала.

[BYjhng]

FanatPHP, Я не слился) Наоборот, я благодарен всем за оставленные комментарии и ответы, стало яснее что к чему, а со своим вопросом я скорее забежал вперёд. Как я уже писал, я только начал изучать php и, конечно, мне ещё многое нужно изучить, прежде чем обстоятельно подходить к данному вопросу

[Vitsliputsli]

FanatPHP, не 100%, но тем не менее защита. Не 100%, потому что теоретически, раз нет разделения на код и данные, то инъекция возможна. Практически, сейчас нет известных уязвимостей. PDO для MySQL по-умолчанию использует именно экранирование.

[FanatPHP]

Vitsliputsli, давайте я вам приведу примитивный до идиотизма пример, в котором экранирование ни от чего вообще не защищает, и вы молча, без всяких "ой я не то имел в виду" "ну это только дурак сделает" и прочих дешевых отмазок просто признаете, что экранирование - это не защита и больше не будете повторять эту глупость?

[Vitsliputsli]

FanatPHP, давайте, только используйте PDO, а не самопальное экранирование.

[FanatPHP]

Vitsliputsli, в PDO нет функции экранирования.
Но не переживайте, никакого "самопального" не будет
https://phpize.online/sql/mysql57/undefined/php/ph...

[Vitsliputsli]

FanatPHP,

в PDO нет функции экранирования.

Да, ладно. А эмуляция prepared statements в PDO каким тогда образом работает?

[FanatPHP]

Vitsliputsli, в публичном контракте PDO нет функции экранирования.
Не отвлекайтесь.

[Vitsliputsli]

FanatPHP, так как все таки работает эмуляция? Магия? И еще раз, для MySQL PDO по-умолчанию использует именно эмуляцию.

Не отвлекаюсь, отличный пример, с таким же успехом можно заявить, что и prepared statements не защита:

$st = $db->prepare( "select * from users where id=$id" );
$st->execute();

Так что, еще раз, давайте в PDO с эмуляцией, разумеется с байндингом переменных. Потому как речь про защиту экранированием, а не как можно сделать так, что ничего не спасет.

[FanatPHP]

Vitsliputsli, не надо метаться, как зайчик по снежной полянке.
давайте закончим с исходным вопросом, а потом я отвечу на ваши вопросы по тонкостям работы пдо.

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

"экранирование" есть? есть
инъекция есть?

[Vitsliputsli]

FanatPHP, неа, мы договаривались используя PDO, т.к. догадывался, что прилетит подобная чушь. Так что не надо метаться, игнорировать условия о которых договаривались, отвечайте по-существу.
Мы говорим о проверке экранирования, а не о "смотри как я могу". Вы пока доказали, что не можете без демагогии, и то что защиты от sql-инъекций нет в принципе, если рассчитывать, что оно "как-нибудь само".

[FanatPHP]

Vitsliputsli,

А защиты по прежнему только две: prepared statements или экранирование

никакого PDO здесь нет.

В общем, потом меня спрашивают, почему я такой мизантроп
Да потому что даже лучшие из тех кто здесь ошивается, на поверку оказываются таким вот human trash
он усрётся, не не признает свою неправоту
потому что думает только о себе любименьком, а не о том вреде, который несут его идеи другим

[Vitsliputsli]

FanatPHP,

никакого PDO здесь нет.

там где договаривались есть:

FanatPHP, давайте, только используйте PDO, а не самопальное экранирование.

В общем, потом меня спрашивают, почему я такой мизантроп
Да потому что даже лучшие из тех кто здесь ошивается, на поверку оказываются таким вот human trash
он усрётся, не не признает свою неправоту
потому что думает только о себе любименьком, а не о том вреде, который несут его идеи другим

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

[FanatPHP]

Vitsliputsli,
в публичном контракте PDO нет функции экранирования (и совершенно правильно, именно по той причине, о которой я говорю)
mysqli::real_escape_string - это что угодно, но не "самопальное" экранирование
для непредвзятого наблюдателя условия соблюдены. это если говорить об абстрактном бессмысленном споре в песочнице "я прав нет я прав", который вас так занимает.
но мне он не интересен. мне важно чтобы пользователи пхп не сидели в дерьме по уши, как привыкли. и не вещали с умным видом всякий бред. но это уже вам, в свою очередь, не интересно, вам свое эго важнее. сидите с ним

[Vitsliputsli]

FanatPHP, когда вы оскорбляете делающих первые шаги в программировании, не давая никакой информации, вам почему-то плевать на этих "пользователей пхп". Но в споре со мной, почему то резко решили прикрыться ими.
Дело не в эго, я задал вопрос потому как подумал, что действительно что-то не знаю или не учел. А диалог получился чтото вроде:
"- предохранитель защищает оружие от случайного выстрела;
- ничего он не защищает;
тут ждешь чтото важное, вроде того, что на некоторых моделях при сильном нажатии, предохранитель не выдерживает, а получаешь:
- если бросить в огонь, произойдет детонация патрона.
- какого?!!!...
- ну дети будут играть и бросят в огонь."

Спасибо, за очень содержательный ответ. Что в PDO при эмуляции магия. Что экранирование, это одноименный метод и никак иначе. Профессиональный спор, блин. А че, вдруг дети будут читать. Nuff said

[FanatPHP]

Vitsliputsli, я вам предложил закончить с исходным вопросом, чтобы дальше ответить на ваши непонятнки с пдо.
но вам важнее настоять на своем. ок.

[Vitsliputsli]

FanatPHP, не, вы писали:

вам свое эго важнее. сидите с ним

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

[FanatPHP]

Vitsliputsli, на самом деле конечно проблема в том, что люди говорят одно, а имеют в виду другое.
Например вы явно имеете в виду "эмуляция prepared statements в PDO", но говорите "экранирование".
Но в этом-то и проблема, что никто не знает, что вы имеете в виду у себя в голове.
Именно поэтому надо быть точнее с формулировками, потому что от неверных формулировок очень много вреда
как например от утверждения "экранирование обеспечивает защиту"

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

[Vitsliputsli]

FanatPHP, я говорил о принципиальных подходах, а не о PDO и эмуляции (их затронул только как пример правильной реализации). Принципиальных их 2: либо с разделением sql-запроса на данные и код, либо без. Как при этом будет работать второй вариант очевидно. Ни в коем случае, не идет речи о любых методах экранирования, но как выше и писал, согласен, что кого-то это может ввести в заблуждение, поэтому стоит для них делать оговорку. Для них первостепенная важность - это байндинг переменных, "заменять все переменные в запросе на маркеры". Это минимум, без которого вообще ни о какой защите речи не может идти. Что под капотом - вопрос другой.

Answer 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
Там уже более основательно доводится доводится мысль как выстраивать защиту на основании архитектуры.

Answer 2

[Adamos]

Главная страница — Страница с формой авторизации — php авторизации
Всё, начиная с php авторизации, защищено от прямого доступа через .htaccess.

Гуглим "php роутинг|маршрутизация".
И привязываться к конкретному Апачу сейчас - не стоит.

файл с защитой от sql-инъекций — файл подключения к БД MySQL

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

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

Логин-то на хрена? Чтобы при следующей регистрации не знать, использован такой или нет?

Comments

[BYjhng]

Ладно, согласен. Логин хэшировать это уже лишнее)

Answer 3

[FanatPHP]

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

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

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

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

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

Плюс вероятные дыры в конкретной реализации, когда на словах вроде правильно, но в коде реализовано криво. Типа location в качестве защиты страниц от доступа. Ну и в целом надо код видеть. Может быть там какое-нибудь гениальное incude $_GET['page'];

Comments

[Adamos]

Где ж тут увидеть код, когда у ТС одни рассуждения по прочитанному.

[I Phoenix I]

Итог: используйте написанные профессионалами фреймворки и библиотеки.

[FanatPHP]

I Phoenix I, перед тем как использовать "написанные профессионалами фреймворки и библиотеки" надо хотя бы примерно представлять что они делают.
А тот тут развелось голозадых "специалистов", которые "используют фреймфорки" чтобы гвозди забивать.