>>43024 Всерьёз подразумевает изучение администрирования, кодинга и алгоритмов шифрований(обзорно) в принципе. Для этого стоило бы изучать операционки, сети, сервера, базы данных и протоколы в принципе, узкой специализацией не отделаешься.
Хотя можешь обратить внимание на самые известные типы уязвимостей со своими названиями тоже: XSS, CSRF, SQL-инъекции и вообще инъекции кода, загрузка на сервер файлов с кодом.
Для веба безопасность - это и отсутствие тупняков в самой программе, которую кодер пишет, и хитрые настройки сервера, так что надо изучать тонкости настройки apache/nginx/другой
http-демонна_выбор. Ещё надо всё обновлять периодически и вовремя. А то и в чужом коде есть косяки. Хартблиды там всякие.
Самое широко известное, о чём стоит знать, самая попса:
по коду: 1) все данные, поступающие от пользователя из форм, кукисов, строки запроса и прочая, должны подвергаться валидации и экранированию.
а) Нельзя конкатенировать SQL-запросы из строчек, содержащих данные, пришедшие от пользователя. Обычно всегда их или втыкают посредством специальных функций внутрь запроса, или прогоняют просто через функцию, которая экранирует.
б) Перед выплёвыванием данных на страницу, если данные исходят от пользователя, то надо экранировать от вставок html-тегов, особенно от вставок джаваскрипта и других особо злых вещей. Я как-то видел, как на 2ch.hk чувак сделал, что у всех вся страница на /s была курсивом. А можно и на фишинговый сайт ссылку запилить.
в) Файлы, которые пользователи аплодят, как, на пример, аватар, картинка в посте или вордовский файл с резюме на сайте с вакансиями и т.п., должны проверяться на соответствие типа файла одному из разрешённых. Двумя способами сразу: и по расширению и по MIME-типу. А то загрузят php-файл вместо аватара и потом его выполнят.
...и др. Вообще данные пользователя всегда опасны.
2) формы все надо снабжать csrf-токенами. Обычно фреймворки имеют встроенный функционал для этого.
3) Команды, выполняющие произвольный код из строк опасны и их надо опасаться. Такие как eval и exec(и ряд других). Есть даже возможность вообще отрубить их настройками php.ini(конфиг. файл). В php до последнего времени(до php 5.4) не было лямбд(анонимных функций) и из-за этого старый код пестрит eval довольно часто.
4) Пароли на серверах хранить только в виде хешей, тогда даже завладев базой хакер не получит пароли. В кукисах по идее должен быть только id сессии и должны быть реализованы его смена и устаревание, тогда кукисы нельзя подделать(но всё ещё можно украсть). Всё это есть во фреймворках, cms-ках, расширениях и т.п. Ничего изобретать не надо. Для твоей задачи, мб, можно даже обойтись функционалом, встроенным в сам апач и получить там примитивную авторизацию без php. Этот вариант самый простой и надёжный, если есть доступ к настройкам сервера. Обычно такого доступа нет на обычных shared-хостингах.
5) Если ты убрал кнопку "редактировать", то это не значит, что чувак не додумается прямо вбить адрес страницы редактирования. Должен быть контроль доступа кодом в начале посещения каждой страницы на основе или просто авторизации, или ролей, или авторства и другой произвольной логики. На фронтендовые проверки js и просто отсутствие кнопки или ссылки нельзя надеяться, всё проверяют на бэкенде.
6) Фатальные действия вроде удаления только через POST. А то тебе в скайп кинут адрес на
http://tvojsajt.ru/articles/42/delete и перейдя по нему ты удалишь статью.
7) Вообще лучше использовать softdelete и ничего не удалять, много данных в закромах - это же хорошо.
8) Когда у тебя в head-е напсиана версия CMS-ки - это полный кретинизм. Чувак просто сверит, какие в твоей недавно устаревшей версии были уязвимости по сраному справочнику уязвимостей в cms для кулхацкеров. И всё по инструкции "как взломать сайт" для идиотов" сделает. Школьник-кун approves. Я не понимаю, зачем вордпресс и некоторые другие его ставят. Вообще в целом чем меньше пользователь знает о технических подробностях твоего сайта, тем лучше. Считается, что phpinfo(), например(и ряд других), может снабдить взломщиков полезной инфой о твоём сайте и иногда её тоже отрубают настройками. Кроме того, вообще надо учитывать, что HTML, CSS и js - это всегда открытая книга для любого пользователя. Пытаться обфусцировать их бесполезно.
9) В линуксах у всех файлов и папок свои права в виде 8-ричного код с тремя цифрами. Обычно на все файлы ставят права 644, чтобы левые юзеры не могли редактировать, а на папки - 755, чтобы в них нельзя было создавать файлы левым юзерам(имеются в виду юзеры в операционке). Только на ряд определённых папок ставят 777, где нужна возможность создания файлов. Обычно это папки для аплода файлов пользователями, папки с кешем и логами(сайт сам пишет в них файлы периодически). Смысл в том, что владелец папок и файлов - админ сайта(в смысле этот человек, который админит, а не рут), а сервер запускается под другим юзером(апач - вроде под юзером www обычно) в системе и таким образом автоматом ограничен в правах на них.
10) Про https уже все диванные параноики тут слышали, я полагаю. В SSL-сертификатах ещё понимать что-то надо, есть те, у которых алгоритмы устарели. Браузер начнёт ругаться на них. Кроме того, если будет man-in-the-middle-атака на сайт с https, то так как у злоумышленника по идее не будет правильного приватного ключа от SSL-сертификата для данного домена, браузер заблочит и скажет, что сертификат не доверенный. Однако, если пользователя это не остановит, то он проигнорирует это предупреждение. Все другие проблемы, насколько я знаю, связаны с теориями заговора и большим братом. Ну вроде чё-то какие-то ещё проблемы были, но там уже всё очень сложно, там совмещают с кучей других атак типа XSS и т.п. Если нужно шифрование от своего сайта до узкого круга пользователей, то можно выпустить бесплатно SSL-сертификат самостоятельно самоподписный и пользователям тогда надо будет добавить его к себе в браузер как доверенный руками.
11) Есть программы, которые позволяют на сервере зашифровать весь php-код и выполнять его зашифрованный. Тогда даже получив весь код, хакер не сможет читать код, только запускать. Очень много гемора. У Zend, ionCube, может ещё у кого есть такое.
12) Я не пробовал Джумлу, но все говорят, что любой кретин может взломать её. Почему-то я решил, что это стоит упоминания. Когда я работал в веб-студии, то наши сайты на Джумле очень многие были взломаны. Других проблем со взломами, не связанных с джумлой у меня в реальной жизни не было(мы потом на ненавистный битрикс перешли, лол. Всё это было давно, сейчас я уже на нём к счастью не пишу). Раз для кого-то это оказывается самым большим косяком по статистике, почему не упомянуть.
по настройкам сервера и т.п.: - Если настроен доступ на папку, то пользователь обычно может запустить или скачать всё, что в ней лежит. И надо следить, чтобы конфиги с паролями, например нельзя было скачать. Чтобы нельзя было не предназначенный для этого php-файл запустить прямой наводкой. Можно настроить(это непросто), чтобы файл был доступен для скачивания только залогиненным или ещё как-то. Во всех фреймворках обычно доступна из веба только одна подпапка проекта(обычно называется public или web). Некоторые вместо этого костылят .htaccess-файлами или даже приписывают в самом коде вверх каждого файла строчку(битрикс так делает), которая останавливает скрипт, если его запускают прямой наводкой.
- Надо, чтоб все сообщения об ошибках были спрятаны, чтобы они не сыпались на экран пользователю. Многие фреймворки подразумевают, что их надо перевести из режима девелопмент в режим продакшен. Злоумышленник может их(сообщения об ошибках) использовать. Они могут засветить куски php-код, sql-запросы и прочая.
- И др. Я в этом мало шарю.
и ещё: - Пользуясь гитом или другой системой контроля версий, надо сразу игнорить все конфиги с паролями. Если конфиг с паролем от базы закомитишь, то уже трудно его потом из истории гита будет вытащить. Можно на хабре почитать смешные истории про поиск на гитхабе репозиториев с файлом db.php с паролем от базы с помощью гугла.
- Гит отслеживает не только содержимое файлов, но и вот эти вот биты прав на файлы 755/644/777 и т.д. Если у себя поменяешь права файлов и закоммитишь, то они попадут на репозиторий. Но вроде, я слышал, для деплоя есть проги предусмотренные для автоматической коррекции всех битов перед деплоем.
Думал, ща пару абривиатур напишу и отправлю. Написал...