Как делают защиту на сайте на PHP?

Question

[lemonlimelike]

Слышал где-то, что защиту от разных атак, типа DDos, SQL Injection, XSS attack можно написать на php, Не покажите направление в этом? Есть какие-то статьи?

Comments

[Александр Шаповал]

Почитайте о CloudFlare
https://habrahabr.ru/post/125823/

[Denis Skripchenko]

Читай про SQL Injection и XSS тут, а про ddos например тут

Answer 1

[Boris Köln]

Сам запуск PHP на каждый запрос даже при слабом DOS уже создаст такую нагрузку, что сервер упадет и без посторонней помощи.
Поэтому от DDOS защищаются с помощью iptables, сторонних систем типа Cloudflare или софтсвичей.

А как правильно написать PHP, чтобы не было SQL Injection и XSS attack - гугл в помощь.

Comments

[Александр Шаповал]

Версию PHP 5.3 и ниже можно было легко положить, а 7.0 же будет держаться прочно

[Boris Köln]

Nginx + PHP-fpm (fast-cgi) завалить чуть сложнее, но даже школота справится.

Answer 2

[dummyman]

От DDOS защититься можно неиспользованием PHP во фронтальной инстанции. Если один сервер - полное кэширование результатов в оперативной памяти.
От XSS и SQL-инъекций (кстати, по сути одно и то же, второе без первого врятли возможно) поможет защититься грамотное распределение прав на сервере. - Если интересно, могу дать консультацию. Но, скорее всего вы так не сделаете! В 95% случаев, сколько сайтов я настраивал на дедиках/vps, web-мастеры возвращают свои разрешающие все и везде права. Им, видете ли, неудобно устанавливать жумловские/вордпресовские плагины прям из админки.
Если же разрешить изменения всех файлов только пользователем ftp (то есть, запретить это делать вебсерверу), и разрешить делать только заранее заданные выборки из БД, то можно не бояться за безопасность по этим вопросам. Даже если у злоумышленника что и получится подобрать, все равно сделать он ничего не сможет. - Ни тебе шелл залить, ни базу пользователей угнать.
Но современные движки сделаны для очень ленивых пользователей, они сами формируют структуру своих файлов. Тебе надо то лишь просто залить версию дистра в корень сайта - остальное сделают скрипты, они же оставят себе права на изменеия файловой структуры для дальнейшего удобного использования. Ставишь плагины от третьих разработчиков - они тоже хотят постоянно что-то записывать в файловую структуру, их разработчики вообще не предусматривают варианты работы, когда на изменение ФС нет доступа, хорошо если выводят сообщение о том, чтобы web-мастер выдал разрешение...
Я не могу назвать этот факт никаким другим определением как долбо..бизм.

Comments

[profesor08]

Посыл сочинения: кеширование - долбо..бизм. Окай...

[dummyman]

profesor08: Ни кэширование - долбо..бизм, кэшировать можно куда угодно, хоть в /tmp. А разрешать изменять структуру ФС сайта - это открытые двери для всех видов злоумышлеников.

[dummyman]

profesor08: Даже дам более развернутый ответ.
Во-первых, как уже упомянуто выше, давать возможность php изменять ФС только лишь для кеширования - это... ну вы поняли... кэширование - неоправданная для сего деяния фича.
Во-вторых, данные кэширования по-человечески имеет смысл хранить в ОЗУ. Не знаю, скольки гигабайтная у Вас БД. Но, как правило, не ждать ответа от винтчестера - довольно эффективная практика.
В-третьих, кэширование - это вообще задача не пыховая. Пых сам по себе тормозной, а скрипты, написанные на нем, - еще медленнее. Если сервер видит данные, и они актуальны, дай ему возможность выдать ответ по запросу не запуская пых.

[Boris Köln]

dummyman:

От XSS и SQL-инъекций (кстати, по сути одно и то же, второе без первого врятли возможно)

Глупость. Никак не связанные вещи.
Например:

http://example.com/search.php?q=<script>DoSomething();</script>

- XSS, но не SQL-инъекция, да и вообще не имеет отношения к БД.

http://example.com/add_comment.php?message=<script>DoSomething();</script>

- XSS, но не SQL-инъекция.

[dummyman]

Boris Korobkov: С точки зрения пентестера - одно и то же.
Сточки зрения web-мастера - ошибки распределения прав.
А до определений придираются школьники, ни рутанувшие ни одного сервера, ни одного скрипта своим pgp ключем не подписавшие.
Один набор скриптов, единная база эксплойтов... с какого, извините, лешего разные вещи?

[Boris Köln]

Между XSS и SQL-инъекцией не понимает разницы только #тыжпрограммист.

[dummyman]

Boris Korobkov: С вами спорить как со стеной. Получите сначала сертификат хотябы OSWE. А уже потом рассказывайте разницу между молотком и зубилом

[FanatPHP]

Жесть. Я многое повидал на своем веку, но такую бредятину вижу впервые.

[dummyman]

FanatPHP: что именно?

[FanatPHP]

dummyman: я могу понять в принципе, как абстрактную XSS можно натянуть на один глобус с абстрактной SQLI. Это будет бессмысленно, но хотя бы объяснимо. Но "второе без первого врятли возможно" - это уже бескомпромиссный ад, который выдает нашего "сертифицированного специалиста" с головой. Это утверждение как бы говорит нам, "автор этих слов в принципе не понимает как работают эти уязвимости, а просто ввернул пару умных слов, не понимая их смысла"

[dummyman]

FanatPHP: Назовите 3-5 тулз, которые логически исходя из данных сайта (движок, хостинг, ОС) эксплуатируют базу ижектов sql при этом не умея эксплуатировать xss.

[FanatPHP]

Уууу. Да у тебя и с логикой совсем беда. То есть, если одна и та же банда грабит банки и бьет старушек кирпичом по голове, то ты делаешь вывод, что не стукнув старушку, банка не ограбить. Блестяще.

[dummyman]

FanatPHP: Нет. Просто есть несколько баз к нескольким программам, во всех базах эксплойты идут вперемешку. Вот и интересно, может расскажете что-нибудь новое.

[FanatPHP]

Расскажу, отчего не рассказать. Можешь начать отсюда: https://xkcd.com/327/

Answer 3

[devalone]

DDos

iptables и всяческие файерволлы

SQL Injection

Экранирование специальных символов

XSS

Тщательная проверка данных, пришедших от пользователя и экранирование специальных символов при рендере шаблона

Answer 4

[Василий Назаров]

Защита от DDoS реализуется на уровне до веб-сервера, и без таковой защиты очень легко уронить сервер на любой технологии, это [очень большие специалисты] выше пишут, что PHP для этого "лучше подходит".
А XSS и SQL injection легко гуглятся, но основное правило такое:
Никогда не доверяйте данным, пришедшим в запросе.