Уважаемые форумчане помогите, пожалуйста, с ответами на ряд следующих вопросов, которые у меня появились (правда, некоторые из них уже задавались не раз и не два, но может на эти вопросы есть новые решения): 1. Как защитить код от скачивания с сервера? 2. Как защитить подключаемые файлы (к примеру хватит ли проверки константой для includов)? 3. Как правильно защитить сессии? 4. Помогут ли подготовленные выражения от xss атак? 5. Как правильно сделать несколько пользователей в бд для безопасности? 6. Как вообще правильно защитить свою БД? 7. Как правильно обрабатывать ошибки и скрывать их от вывода пользователю? 8. Какие права доступа выставлять файлам на хосте? 9. Какие еще меры безопасности нужно принять для защиты своего сайта? 10.Как можно протестировать свои скрипты на нагрузку? 11.Как правильно настроить robots.txt? 12.Как правильно настроить sitemap.xml? p.s. Учусь программированию в связке php+mysqli.
1. Если веб-сервер настроен на выполнение пхп-файлов - отдаваться будет результат работы пхп-машины. Оригинальные файлы можно будет отдать взломав какой-нибудь файл и через него делать чтение в поток. Либо взломав сервер и скачав всё с файловой системы. 2. А зачем их защищать? 3. Ну можно навелосипедить проверку адреса и названия клиента, но это не панацея. Да и зачем? 4. Нет. XSS к подготовленным запросам не имеет отношения. Они спасут от инъекций - это другой вид атаки. А от XSS нужно защищаться на выводе данных. 5. В смысле смертные подключаются с ограниченной мускул-записью, а админы с более привилегированной? Ну собственно решить кому какие права нужно дать да и потыкать нужные галки в пма. 6. От чего? 7. Много вариантов. 8. 0640 файлам, 0751 (или 0750) каталогам. 9. От чего? 10. Через seige можно изобразить нагрузку. Но профилировать нужно с другой стороны, и не только скрипты, но и все остальные аспекты информационной системы - тюнинг СУБД, файловой системы, веб-сервера, сервера, сетевого стека. 11. А какая-то может быть сложность? Что-то разрешаешь, что-то запрещаешь. Не забываешь указать хост и урл сайтмэпа. Что там еще настраивать-то? Всё равно боты болт поклали на него. 12. Что значит настраивать? У тебя есть ресурсы, ты их перечисляешь. Раздаешь различные плюшки, какие считаешь нужными. Всё равно это не ПРАВИЛА а РЕКОМЕНДАЦИИ для поисковиков. Они могут покласть болт, и сканировать в удобной манере. ЗЫ. Не путай СУБД и расширение для работы с ним.
1. По нормальному, код нельзя скачать, он исполняется. Только если украсть у вас ftp 2. Хватит 3. Тут в соседней теме сурикат об этом хорошо написал: https://php.ru/forum/threads/ne-poluchaetsja-sozdat-avtorizaciju.59560/page-4#post-482188 4. Не помогут. Они от SQL-инъекций 5. Ну есть рекомендации работать от пользователя только с необходимыми правами. Ни разу не видел, чтоб следовали 6. Большей частью - подготовленные выражение. Ну и не просрать пароль - это понятно 7. Те ошибки, которые надо скрывать от пользователя, должны быть исправлены. 8. Разным файлам - разные права 9. Следить за папками, в которые пишутся данные пользователя (например, аватарки) - в них должно быть запрещено выполнение скриптов 10. Подождём более продвинутых чуваков, я не сильно знаю 11. Не по теме форума. А вообще, у яшки куча про это написано. 12. Как и с предыдущим вопросом, это к http://searchengines.guru/.
1. Вы имеете ввиду взломать оригинальный файл с кодом php? Если да, то как максимально защититься от взлома файла? Как минимизировать взлом сервера, на котором хранятся файлы моего проекта, если я являюсь пользователем одного из хостингов? 2. Для того, чтобы обычный пользователь моего проекта не смог их открыть/прочитать/скачать. 3. Для лучшей защиты. Сейчас я сделал выбор для пользователя "запомнить меня" с помощью галочки. Если пользователь не поставил ее, то при каждом новом посещении страниц идет проверка ip и id для данного пользователя, а если поставил, то проверяется наличие только id пользователя в сессии. 4. Как тогда правильно защищаться от xss? Правильно строить запросы к бд? 5. Т.е. сделать несколько пользователей в бд и для каждого пользователя параллельно сделать свое подключение к бд? 6. От прямого доступа к ней, к примеру через phpmyadmin. 9. От взлома сайта по большей части от "школьных хакеров". Я понимаю, что если ломать начнет опытный хакер, а не школота, и его целью будет взлом, то он это сделает - вопрос времени. Вот и хочу сделать это время максимальным для опытного хакера, а для школоты - невыполнимым. ЗЫ. Да, неправильно написал, но из него Вам стало понятно, что я работаю с СУБД mysql, а расширением пользуюсь mysqli. 1. Как правильно защитить ftp? Для меня кража кода - один из главных вопросов. Не хочу через какое-то время обнаружить свой код в общем доступе... 6. Я только подготовленные выражения и использую. Как можно пароль от бд просрать? Т.е. Вы имеете ввиду не сохранять его в браузере при работе с бд (если работаешь с помощью phpmyadmin)? 9. Да, я проверяю аватарки на наличие того, что это картинка и в нее не вписан код. --- Добавлено --- Вопрос по поводу файлов, которые исполняются cron. Их выносить в отдельную папку и хранить на уровне хранения папки public_html, чтобы обычные пользователи не могли их запустить?
1. Не писать рукожопый код, который может быть атакован - от взлома изнутри. Ну и регулярно обновлять стороннее ПО. Следить за безопасностью на сервере - это снаружи. Ну там блокировать подозрительных злодеев, не использовать фтп как устаревшее говно, часто пароли менять, регулярно изучать логи в поисках подозрительной активности. 2. А как он их может открыть? 3. "Запомнить меня" к сессиям отношения не имеет. А вот когда есть проверка айпишника и вдруг переставать её делать по значению галки "запомнить меня" - глупость. Видимо от недостатка опыта и воображения. 4. Фильтровать данные на выходе. Что значит правильно строить запросы? Запрос правильный, если он оптимальным путём выполняет своё назначение. Главное входящие данные фильтровать не забывать, чтоб инъекций не было. 5. Зачем ты спрашиваешь, если не понимаешь? Да, сделать несколько учеток. Каждой настроить свои привилегии на сервер/базу/таблицу/поле и потом в зависимости от контекста - подключаться с той или иной учетной записью. Но тебе еще рано так усложнять свою информационную систему. 6. Ну если ты боишься пма, установленной удалённо, то тебе надо либо отключить внешние сетевые подключения к СУБД, либо внимательно настраивать учетные записи удалённых пользователей. Еще можно СУБД держать на нестандартном порту. Если ты боишься пма, установленной локально, то тебе надо внимательно следить за тем, чтоб к ней никто не получил нелегитимного доступа, чтоб сама она спрашивала логин-пароль подключения, а не была настроена на логин через конфигурацию. Ну и шифровать трафик будет тоже неплохой затеей. 9. Просто писать код, применяя голову. 1. Просто перестать его использовать и перейти на sftp. Не путать с ftps. Вообще всё, что не нужно запускать посетителям - неплохо держать вне докрута. Это же к вопросу про дебильные константы, типа защищающие код от выполнения. Переложи код вне докрута и константа не нужна.
2. Буду переделывать с помощью выноса файлов и папок на уровень хранения папки public_html (или папка www в Денвере). Правильно? 3. Да, недостаток опыта компенсировало воображение)). Как правильно реализовать "Запомнить меня"? Проверку ip всегда выполнять? 4. Фильтровать данные на выходе, которые выводятся с помощью формы (на примере распространенного поиска)? Фильтрацию выполнять с помощью htmlspecialchars? 5. Как мне тогда поступить на первых этапах? Отключить root пользователя (если это возможно) и сделать одного общего? А позже подробнее изучить данную тему? 6. Как правильно выполнить шифрование трафика?
2. Типа того. Адекватные IDE (например NetBeans) позволяют разделять каталог проекта, каталог исходников, и каталог вебдоступа. При деплое, соответственно, нужно докрут указывать на каталог вебдоступа, а всё, что не должно лежать в прямом доступе - оставлять в каталоге исходников. Денвер - говно мамонта. Рекомендую вообще собрать весь стек руками. 3. Запомнить меня должно быть неким токеном, который при отсутствующей сессии мы проверяем в БД и начинаем сессию. Естественно, такую плюшку нужно дополнительно защищать, а это уже простор фантазии. 4. Фильтровать просто при выводе. В форму или нет - это не важно. 5. Естественно не давать сайтам работать с СУБД через рута. Как минимум - каждому сайту свою учетку на свой набор баз данных. А позже уже можешь извращаться типа для админки сайта - пользователь с бОльшим доступом, для публичной части - с меньшим. 6. TLS уже давно придуман. На локалке можно и без шифрования девелопить, но после деплоя - лучше чтоб сайт работал через HTTPS.
денвер-ни денвер. Есть документ-рут у сайта, пишется в конфигах сервера. Вот если у тебя document root /var/www/usename/my_site/public_html, то всё, к чему не нужен прямой доступ пользователя, пишешь в папку /var/www/usename/my_site. Правда, некоторые хостинги так не позволяют, но я бы лично ими просто не пользовался
Напомню - разговор был про xss защиту. Я не совсем разобрался как правильно защищаться от xss. Можете скинуть какую-либо ссылку по этой теме, в которой подробно и правильно расписана защита от xss?
Для защиты нужно для начала понимать принцип работы самой атаки. В простом виде xss это допустим javascript-код, который, к примеру, тырит куку и отсылает её на сторонний (злодейский) ресурс. Допустим, какой-то кент зарегился под именем <script>блаблабла</script>. Ты на выводе не отфильтровал, этот код вставился в страницу, выполнился. И выполнился от имени твоего сайта, значит имеет доступ ко всем ресурсам пользовательского браузера, посещающего твой сайт. В примере - к кукам. Прочитал куку, отправил её куда надо. Всё. Для защиты достаточно заэскейпить выходные данные. Тогда все угловые скобки будут представлены html-последовательностями в html-исходнике, вместо готовых тэгов, и превратятся в бессмысленные угловые скобки после рендера. Почему не эскейпить входные данные? Ну тут опять нужно голову на плечах иметь, и серую жидкость внутри. Когда ты делаешь html-эскейп на входной строке и потом записываешь её в базу - ты уродуешь данные, а не защищаешь. Простой пример, который я уже не раз тут приводил. У тебя есть компания at&t и есть какой-нибудь усилитель, который amplifiler. Ебанув эскейп на входе ты получишь at&t, которые запишешь в базу. А потом когда захочешь поискать вхождение amp в поисках усилка - вдруг получишь название компании в результатах запроса. То есть, на входе нужно защитить сам запрос от данных, которые могут его поломать. От инъекции короче. Но не более. Хранить данные нужно в том виде, в котором они пришли. А вот на выходе уже защищаться от других видов атак, которые могут провести эти, ранее сохраненные в исходном виде, данные.
Эх... Ну вот собственно о чем и речь. Голова на плечах и серое вещество в ней - должны быть. Я тебе рассказал про принцип работы атаки, но ты уловил связь только между ввод-запись и чтение-вывод. А как же случай, когда эту же парашу передают через урл, например? Ну вот есть у тебя поисковое поле, ввёл злодей запрос со скриптом, получил классную GET-ссылку, перекинул её кому-нибудь, кому-нибудь эту ссылку открыл и словил атаку. Данные взяты из базы? Нет. Но их же нужно было фильтровать? Да. И вот мы уже пришли к выводу, что фильтровать выходные данные нужно вне зависимости от того читаешь ты их из базы или возвращаешь что-то из текущего запроса. Или сессии. Или дёрнул с другого ресурса.