Всем привет, недавно решил написать PHP-движок для своих нужд, так сказать, чтобы поднять уровень и получить что-то полезное.
Почти сразу я задумался, насколько легко будет его взломать? Ни для кого не секрет, что взломать можно что угодно, но вопрос в том, насколько это будет проблематично и сможет ли это сделать каждый хакер?
Формы
Пожалуй, самая распространенная уязвимость в любом проекте, будь то форма комментариев или форма входа.Без хороших проверок эта вещь ничего не стоит. Одна из частых ошибок — сохранять все, что получаете:
Любой человек может добавить к этому же элементу через отладчик свой, пусть это и не дает большого взлома, но вещь крайне неприятная.foreach( $_POST as $item ){}
Формы подачи файлов
Я пришел к такому выводу:Защитить свой движок можно только в том случае, если у вас нет единой формы для загрузки файлов, или если они у вас есть и проверены достаточно хорошо.Я считаю, что первый из них самый надежный, но если вы без них не можете, то есть несколько рекомендаций.
- Одной проверки никогда не бывает достаточно!
- Узнайте все о содержании.
К счастью, это была админка и попасть туда мог не каждый.
Итак, вот вывод. Вы не можете этого сделать! Есть две причины.
- Возможно, у пользователя отключен JS.
- Пользователь может изменить JS в отладчике
Зачастую при показе изображения проверяют только одну сторону, ширину или высоту, но теперь представьте, что какой-то умник загрузил изображение размером 20000х50px или наоборот, зрелище будет не из приятных.
Хранение паролей
Хоть это и удобная вещь, которая в дальнейшем избавит вас от необходимости рыться в почте или записях и искать пароль, давайте посмотрим, что можно сделать, если этот компьютер попадет в руки вашего «друга».Он может открыть настройки как минимум двумя способами и посмотреть там сохраненные пароли; второй через отладчик изменить тип поля с пароля на текстовый.
SQL-инъекция (SQL-инъекция)
Для тех, кто в танке, это внедрение SQL-кода простого пользователя, через адресную строку или через те же формы.Есть одно правило:
" Никогда не доверяйте тому, что вам отправляет пользователь "Если вы будете постоянно об этом помнить, то сможете уберечь себя от многих проблем в будущем.
Проверьте, что вам отправил пользователь, если в поле пароля он укажет «lol' OR (1=1)#», это вас никак не повлияет.
Самый простой способ избавиться от этого — использовать mysql_real_escape_string, эта функция экранирует все специальные символы в SQL, а также удаляет все косые черты с помощью функции Stripcslashes.
Админ
На многих сайтах, чтобы попасть в админку, достаточно ввести адрес /[admin|admin.php|administrator| и т. д].Вариантов не так уж и много, поэтому вы сможете найти тот, который вам нужен, но если вы используете админку со сгенерированными символами, вам не о чем беспокоиться (пример: 7NVmE10SaJ.php), кому-то это может показаться паранойей, но я думаю безопасности много не бывает, если пользователь попадает на страницу ввода логина и пароля администратора, это приближает его на шаг к раскрытию всех секретов серверной части сайта.
Пароли
Чтобы не потерять какие-либо учетные записи, не позволяйте пользователям создавать свои собственные пароли, но если вы это сделаете, постарайтесь заставить их сделать пароль как можно более сложным.Недавно я начал использовать эту комбинацию для создания пароля md5($secret_key. $password. $salt); На мой взгляд это хорошая защита.
Хэш md5 строится из секретного ключа, который встроен в конфиг движка (находится где-то в коде), из пароля пользователя и соли, которая хранится в базе данных, рядом с хешем md5 пароля пользователя, и у каждого пользователя своя соль.
Что это нам дает? Если кто-то украдет нашу базу данных, без секретного ключа он не получит пароль, даже если он получит и базу данных, и движок, то без пароля ему не будет никакой пользы, только пользоваться терабайтными радужными таблицами.
phpmyadmin
Здесь все так же, как и с админкой, вы не можете дать возможность попасть в phpmyadmin, введя просто адрес /[phpmyadmin|myadmin|pma|etc].Ну и конечно же использование логинов root|123 тоже запрещено.
Сессии
Чаще всего сеансы используются для поддержки аутентификации пользователей, но хранение сеансов также является важной темой.Первое, что нужно помнить, не хранить идентификатор сессии в открытом виде, а еще лучше хранить в базе данных, и не давать нескольким пользователям сидеть под одной сессией, проверять все, ip, user_agent, чтобы злоумышленник не смог украсть что-либо.
Еще советую посмотреть антиспуфинг, чтобы хакер не смог подделать IP.
Печенье
Файлы cookie необходимы браузеру для хранения данных; многие люди часто хранят идентификатор сессии в куках, чего я не рекомендую делать, особенно в открытом виде.Если вы храните что-то в куках, то шифруйте это и тем более проверяйте, потому что здесь, как и с формами, нельзя доверять пришедшему, так как изменить это тоже не проблема.
Кстати, соль, которая использовалась для пароля пользователя, может и здесь вам помочь.
Архитектура
Вам необходимо тщательно продумать архитектуру вашего проекта, если вы будете делать весь проект с костылями и велосипедами, это ни к чему хорошему не приведет, одни дыры.Попробуйте использовать MVC, это поможет разбить ваш код на логические компоненты.
Операционные системы
Понятно, что это должен быть Linux. Насчет безопасности не знаю, но если у человека руки растут откуда надо, то можно поставить любой сервер.Со слов людей понятно, что Windows можно настроить, так что решение за вами.
Если я кого-то обидел виндой, то извините, но мне не приходилось с ней работать, я высказал свое мнение на основе отзывов друзей.
Еще можно написать про анализ трафика, но я этого не делал, поэтому не могу знать наверняка; для этого есть специалисты.
Заключение
Из вышеизложенного можно сделать следующие выводы:- Информация, отправленная пользователем, по умолчанию считается недостоверной.
- Обрабатывать любую входящую информацию
- Надежные пароли
- Умная архитектура
- Отслеживайте имена потенциально уязвимых файлов
- Не используйте чужие скрипты; если вы их используете, проверьте их несколько раз.
API не включены в это число, но используйте их на свой страх и риск.
- Сессии, файлы cookie и SQL-запросы.
Следите за ними!
- Выбор ОС
- Входящий трафик
Также помните, что проверка данных через javascript — это только полдела, так как ее можно смело отключить, перепроверить все данные, ведь из всего вашего кода только 10% — вывод или работа с информацией, все остальное — проверка и валидация данных.
ПС.
Про Windows я сказал, что точно не знаю.
Просто все, что я читал, говорит о ней плохое, так что извините, если кого-то обидел.
Нет смысла рассказывать им о каких-либо PDO или ORM. Это советы для новичков.
Знаю, что эта информация известна многим, но я не нашел статьи, где будет изложено хотя бы столько информации.
Я не собирался никого удивлять; Мне нужны были люди, которые мало что об этом знают. Теги: #php #защита #уязвимости php #уязвимости #информационная безопасность #php #sql
-
Список Лучших Альтернатив Psiphon
19 Oct, 24 -
Формируйте Разум С Помощью Игр-Одевалок
19 Oct, 24 -
Создание Идеального Списка Ключевых Слов
19 Oct, 24 -
Антивирус Как Угроза
19 Oct, 24 -
Pixelheart - Здесь Они Признаются В Любви
19 Oct, 24 -
Мобильный Контент: Рост Или Стагнация?
19 Oct, 24
