Формы
Пожалуй, самая частая уязвимость в каком-либо проекте, будь то форма для комментариев, или форма логина. Без хороших проверок, эта штука ничего не стоит.
Одна из распространенных ошибок — это сохранять все что ты получил:
foreach( $_POST as $item ){} Любой человек может через отладчик добавить в тот же свой собственный пункт, пусть это и не дает большого взлома, но вещь крайне не приятная.
Формы отправки файлов
Я пришел к такому выводу:
Можно защитить свой движок только в том случае, если у тебя нет ни одной формы для загрузки файлов, либо они есть и достаточно хорошо проверяются
Я считаю первое, это самое надежное, но если без них никуда, то тут есть несколько рекомендаций.
- Одной проверки никогда не бывает достаточно!
- Узнайте о содержимом все.
Однажды у меня был проект и мне нужно было что-то сделать с формой загрузки фотографий, когда я посмотрел код, там вообще не было проверок файла, даже проверки типа файла, просто, что приходит то и записывает. Первой моей мыслью было: «Что за х?». Порывшись еще немного я понял, что эту форму обрабатывает JS скрипт. Благо, это была админка и не каждый мог туда попасть.
Так вот, вывод. Так делать нельзя!
Причины две.
- У пользователя может быть отключен JS
- Пользователь может изменить JS в отладчике
Уделяйте больше внимание проверки файлов, размер, тип, если это картинка, то ширина, высота. Часто, при выводе картинки делают проверку, только по одной стороне, по ширине или высоте, а теперь представьте, что какой-то умник залил картинку 20000x50px или наоборот, зрелище будет не из приятных.
Хранение паролей
Хоть это и удобная вещь, которая в дальнейшем избавит вас от рысканья в вашей почте или записях и поиска пароля, но посмотрим, что можно сделать если этот компьютер попадает в руки к вашему «другу».
Он может как-минимум двумя способами открыть настройки и там посмотреть сохраненные пароли, второе через отладчик поменять тип поля с password на text.
SQL Injection (SQL инъекции)
Для тех, кто в танке — это внедрение SQL кода простого юзера, через адресную строку или через те же формы.
Есть одно правило:
"Никогда не доверяй тому, что прислал тебе пользователь"
Если постоянно его помнить, то можно избавить себя от множества проблем в будущем.
Проверяйте то, что вам прислал пользователь, если в поле пароль он указывает «lol’ OR (1=1) #», на вас это никак не скажется.
Самый просто способ, как от этого избавиться, это использовать — mysql_real_escape_string, эта функция экранирует все спец символы в SQL, а также убирать все слеши с помощью функции stripcslashes.
Админка
На многих сайтах, для попадания в админку достаточно ввести адрес/[admin|admin.php|administrator| и тд]. Вариантов не так много, так что найти нужный можно, но если вы будете использовать админку с генерированными символами, то можете не беспокоиться (пример: 7NVmE10SaJ.php), кому-то это может показаться паранойей, но я считаю безопасности никогда не бывает много, если пользователь попал на страницу ввода логина и пароля администратора, это на шаг приближает его к раскрытию всех тайн back-end части сайта.
Пароли
Во избежание пропадания каких-либо учетных записей, не давайте пользователям самим создавать пароли, но если даете, то старайтесь заставить его сделать пароль как можно сложнее. С недавних времен я начал использовать такую связку для создания пароля md5($secret_key. $password. $salt);
На мой взляд это хорошая защита. md5 хэш строится из секретного ключа, который вшит в конфиг движка (расположен где-то в коде), из пароля пользователя и соли, которая хранится в базе, рядом с md5 хэшом пароля пользователя, и у каждого пользователя соль своя. Что это нам дает? Если кто-то выкрадет у нас базу данных, без секретного ключа он не получит пароля, даже если получит и базу и движок, то толку от этого без пароля ему тоже не будет, только использовать терабайтные радужные таблицы.
phpmyadmin
Тут все так же как и с админкой, нельзя давать возможность попасть в phpmyadmin введя, просто адрес/[phpmyadmin|myadmin|pma|и тд]. Ну и естественно использовать логины root|123 тоже запрещается.
Сессии
Наиболее частое использование сессий – это поддержка авторизации пользователя, но хранение сессий – это тоже огромная тема. Первое, что нужно помнить, не храните ID сессии в открытом виде, а еще лучше, храните его в БД, и не давайте нескольким пользователям сидеть под одной сессией, проверяйте все, ip, user_agent, чтобы злоумышленник ничего не смог своровать. Так же советую посмотреть в сторону антиспуфинга, чтобы, хакер не смог подделать ip.
Печеньки(Cookie)
Куки нужны для хранение данных браузером, зачастую многие хранят в куках id сессии, чего делать не рекомендую, особенно в открытом виде. Если что-то храните в куках, то шифруйте, а тем более проверяйте, потому что тут как и с формами, нельзя доверять тому что пришло, так как изменить тоже не проблема. Кстати говоря тут вам снова может помочь соль, которую использовали для пароля пользователя.
Архитектура
Нужно грамотно продумать архитектуру вашего проекта, если вы будете делать весь проект костылями, да велосипедами, ни к чему хорошему это не приведет, только к дырам. Старайтесь использовать MVC, это поможет разграничить ваш код, на логические составляющие.
Операционные системы
Ясное дело, что это должен быть линукс. На счет защищенности не знаю, но если у человека руки растут откуда надо, то настроить можно любой сервер (кроме windows конечно, там само ядро сплошная дыра).
Еще можно написать про анализ трафика, но этим я не занимался, поэтому не могу знать наверняка, для этого есть специалисты.
Вывод
Из вышесказанного можно сделать следующие заключения:
- Информация присланная пользователем, по умолчанию считается ненадежной
- Обрабатывать любую поступаемую информацию
- Надежные пароли
- Грамотная архитектура
- Следить за названиями потенциально уязвимых файлов
- Ни использовать чужие скрипты, если использовать то проверять на несколько раз. API в это число не входят, но используйте их так же на свой страх и риск
- Сессии, куки и SQL запросы. Следите за ними!
- Выбор ОС
- Поступаемый трафик
Все эти советы не избавят вас от угрозы взлома, но помогут её очень сильно усложнить, так что теперь не любой хацкер сможет её взломать. Так же помните, что валидация данных через javascript, это только пол дела, так как его можно спокойно отключить, проверяйте дважды все данные, ведь из всего вашего кода лишь 10% это вывод или работа с информацией, все остальное, это проверки и валидация данных.
ссылка на оригинал статьи http://habrahabr.ru/post/173701/
Добавить комментарий