Чеклист по безопасности сайта? Что еще посоветуете?

Question

[Narts]

Имеется сайт на PHP. Движок намопис
Перед релизом хочется быть полностью готовым ко всему

Вот что уже сделали:
1. CSFR токены на все ajax запросы
2. Валидация всех пользовательских данных (имеется в виду соотношение типов. Т.е. проверка на int, если в бд столбец int)
3. PDO от инъекций
4. Проверка форм. Т.е. почти у всех форм количество полей фиксированно, если в запросе данных больше, то запрос отменяем

Что еще можно реализовать для более менее полной уверенности, что сайт не сломают?

Comments

[Sanes]

Перед релизом хочется быть полностью готовым ко всему

Вы так его никогда не выпустите.

[Karmashkin]

https://stackoverflow.com/questions/1865020/php-ho...

Answer 1

[АртемЪ]

Перед релизом хочется быть полностью готовым ко всему

Быть готовым ко всему невозможно даже теоретически!
Вы поставили заведомо невыполнимую цель

Стандартный чеклист по проверке основных типов угроз.
Если есть какие-то очень критичные места именно в вашем проекте - дополнительно их проверьте.
А что касается остального -
Безопасность это процесс!
Невозможно взять и сделать сайт безопасным.
Можно следить за безопасностью сайта и своевременно устранять наиболее критичные угрозы.

Comments

[VanJo]

Категорически не согласен с вашим выражением "Невозможно взять и сделать сайт безопасным".

Быть готовым ко всему не готов никто, но поставить целью обеспечение безопасности сайта в автоматическом режиме, т.е. как само собой разумеющееся - всего лишь ваша воля.

[АртемЪ]

Я сделал тестовый сайт и считаю что его невозможно взломать и поэтому он безопасен.

Никто вам не запрещает так считать.

[VanJo]

Вы хотите проверить?

[АртемЪ]

VanJo,

его невозможно взломать и поэтому он безопасен

Все известные мне фреймворки, веб сервера, и ОС содержат уязвимости.
Вы же утверждаете что сделали сайт который невозможно взломать - следовательно ОС, фреймворки и веб сервера у вас все свое и абсолютно безопасное?

Сайт кодирует все текстовые данные
передаваемые как с сервера так и на сервер.
Декодирование полученного текста производится непосредственно в Вашем браузере с использованием динамического секретного ключа.

Т.е данные передаются в открытом виде?

[VanJo]

Не совсем Вас понимаю - не хотите ли Вы сказать, что для того чтобы человек посередине, задумавший взломать мой сайт, использовал для взлома либо уязвимости ОС моего ПК, либо веб сервера?
Тогда не так далеко и до терморектального криптоанализа :)

[АртемЪ]

человек посередине, задумавший взломать мой сайт, использовал для взлома либо уязвимости ОС моего ПК, либо веб сервера?

Да, это один из самых популярных способов взлома.

Неужели повсеместно и на раз ломают https,

О взломе протокола https не слышал, вроде никто еще его не сломал. Хотя обойти его - не проблема.

Те символы, что Вы могли видеть по окончании загрузки страницы с моего сайта приходят в Ваш браузер в кодированном виде, и декодируются непосредственно в браузере с использованием длинного-предлинного ключа,

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

Поэтому и считаю свой сайт НЕВЗЛАМЫВАЕМЫМ!

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

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

[VanJo]

И то уж хорошо, что все же существуют относительно хорошо защищенные системы.
АртемЪ, ну что Вам стоит попробуйте взломать, будете первым ВЗЛОМАВШИМ! Ну хоть разочек :)
Где то читал, пишут же, что можно взломать даже html.

[АртемЪ]

VanJo,

Ваш сайт хочет передать мне пароль доступа, при том что я зашел на Ваш сайт первый раз, и не собираюсь к тому же светить свой телефон, какую защиту он может применить? только https?

Да, https. А разве вам известны более эффективные методы защиты?

ну что Вам стоит попробуйте взломать, будете первым ВЗЛОМАВШИМ!

Закон Неуловимого Джо знаете? Именно он мешает взломать ваш сайт, как и множество других :)

[VanJo]

Вот! Наконец то Вы подкрались к моему Jo !

Вернемся в начало:
"Невозможно взять и сделать сайт безопасным" - можно!
Сделать сайт безопасным - всего лишь ваша воля! - примем это за аксиому.

[АртемЪ]

Где же найти ЛЮБОПЫТНОГО хакера ?

Нигде, таких идиотов нет.
Положите на сайт что-то ценное, и его взломают. А бесплатно это никому не нужно.

[VanJo]

Обнаружен дамп, содержащий 773 млн email-адресов и 21 млн уникальных паролей
https://xakep.ru/2019/01/18/collection-1/

[АртемЪ]

VanJo,

Сайты почтовики настолько беспечны

При чем тут сайты почтовики? Можно подумать пароли оттуда берут.

это ли не доказательство ненадежности тайны личной переписки.

Что за тайна личной переписки, и почему она должна быть надежна?

Если хочется чтобы переписка была в тайне - это можно обеспечить предприняв некоторые меры.
Если никаких мер не предпринимать - о какой тайне можно говорить?

[VanJo]

"Что за тайна личной переписки, и почему она должна быть надежна?" ??? Вы меня поражаете своим вопросом, похоже даже не подозреваете что где то может быть написано:
Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений.

[АртемЪ]

VanJo,

Каждый имеет право

Ну никто это право не отбирает.
Вам что запрещают это? Ни в коем случае.
Но обеспечивать за вас это никто не будет. Это уж сами обеспечивайте.

"некоторые меры" не иначе как кодирование?

При чем тут кодирование?
Кодирование это преобразование информации в другую форму. Например кодирование текста в код Морзе, для передачи по телеграфу, или кодирование в BASE64.
Кодирование никак не защищает информацию, просто позволяет с ней более удобно работать.

а кодированию сайта не доверяете

Кто сказал что я не доверяю кодированию сайта? В сайтах обычно используется BASE64 - прекрасно работающая стабильная система кодирования.
Не замечал чтобы она работала со сбоями - нет причин не доверять.

[VanJo]

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

[АртемЪ]

VanJo,

Вы о кодировании символов, я о шифровании

Вы же сказали - кодирование.

Шифрование то какое отношение к кодированию имеет?

И пароли пачками - хакеры 21 млн. их обозначили, откуда?

Да элементарно.
Ломаешь какой нибудь интернет магазин сливаешь хэши паролей и адреса почты, после чего по радужным таблицам подбираешь пароль.
У 80% людей один пароль на большинство сервисов.

Или все же пароли в открытом виде идут в трафик,

Сейчас откуда в открытом виде пароли в трафик попадут? Даже самый никому не нужный сайт использует https.

[АртемЪ]

https у меня встроен в javascript

Это чушь собачья.
javascript это язык программирования.
https - это расришение для протокола передачи данных.
Это все равно что заявить что в русский язык встроено расширение для передачи данных по сети.
Можете привести текст из документации javascript где указано что в язык встроен какой-то там протокол?

Радужные, подобранные пароли - так их же как то надо испробовать, а и на этот случай я что то там еще придумал. Не пройдут радужные! Проверяйте.

Что такое радужные пароли? Никогда о таком не слышал.

Ломаешь какой нибудь интернет магазин.........." - Вы же не пробовали практически ничего никогда ломать, я прав?

Разумеется не пробовал. Я умный и законопослушный человек.
И если я совершил преступление, то разумеется не буду признаваться в этом публично.

[VanJo]

https у меня встроен в javascript - а у Вас разве нет? может javascript Ваш более ранней версии, или браковый попался :))))))))))))))))))))))))))))))))))

[АртемЪ]

VanJo,

знаете, я тоже нигде не встречал чтобы в яп javascript встроен протокол

Ну если не знаете, то зачем такую чушь пишите? Что у вас встроен?

та не пароли радужные - а таблицы (от Вас о них же и услышал)

Радужные таблицы это индексированные таблицы хэшей для некоторого количества значений. Служат для быстрого поиска значения по его хэшу. . О радужных паролях я ничего не слышал.

так вот не пройдут все эти попытки с паролями

Какие попытки?

[VanJo]

Продолжать разговор с Вами у меня пропал интерес.

[АртемЪ]

VanJo, Ну а какой смысл вести с вами диалог, если вы не знаете базовых вещей и несете явную ахинею про https встроенный в javascript, про какое то доверие кодированию, радужные пароли, и.т.п.
Такое впечатление, что умных слов нахватались, а смысла не понимаете.

Answer 2

[ebroker]

1) Настройка сервера Проверить например что по такому пути mysite.com<имя папки> сервер не возвращает список файлов в директории
2) Проверить что будет при прямом обращении к файлам mysite.com/core/some.php (если у вас не переопределен роутинг через .htaccess)
3) Проверить авторизацию, что-бы куки были httponly
4) Если на сайте есть функции загрузки файлов то сделать все возможные проверки(https://habr.com/post/44610/)

Comments

[Snewer]

Сюда же бы добавил из часто встречающегося: папка .git должна быть закрыта из веб-доступа.

Да и вообще, по-хорошему в веб должна быть видна только папа с index.php и статикой.

Answer 3

[Виктор Батиенко]

Сложные пароли на sftp,ftp,ssh..
Последние обновления на сервере.
Нужно смотреть не только со стороны кода, но и со стороны сервера.

Comments

[Sanes]

как это относится к php приложению?

[Виктор Батиенко]

Sanes, тут речь о безопасности сайта а не о php только

[Sanes]

Виктор Батиенко, так можно договориться и до квалификационных экзаменов для пользователя.
Автор пишет php приложение. При чем тут сервер? Может на шареде он будет размещать.

[Sanes]

Nikolay Petyukh, а еще бывают дыры на стороне микрокодов процессора и контоллерах жестких дисков. Почему бы это тоже не учитывать?

[Sanes]

Nikolay Petyukh, вы вопрос, чтоль перечитайте. Автор пишет приложение на PHP. Каким боком тут сервер? Совсем другая компетенция.

[Виктор Батиенко]

Sanes, а что плохого в том что ему подсказали и не только в части php.
А то с чем чаще всего сталкиваются люди которые заботятся о безопасности сайта.
Или которых уже взламывали. Каждый высказал свой совет и опыт.

[Sanes]

Виктор Батиенко, ничего плохого, кроме того, что не в тему.

[Станислав Тамат]

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

Answer 4

[Alister O]

Owasp top10
Cis benchmark
Vulnerability auditing
Kali gathering

Answer 5

[Андрей]

Не давать администраторам создавать слабые пароли.

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

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

Ну и на серверах резать sudo до необходимого минимума.

Люди скорее всего будут самым слабым местом.

Comments

[Sanes]

как это относится к php приложению?

[Константин Нагибович]

Люди скорее всего будут самым слабым местом.

Люди всегда самое слабое место. Болевой порог ни кто не отменял.

Answer 6

[khomaldi]

Во-первых, проверка данных и на клиенте и на сервере!
Во-вторых, опробуйте сами роль мамкиных хацкеров. Посмотрите, какие данные должны придти верными и попробуйте всячески послать кривые данные. F12 + Request-Builder вам в помощь.