Всем привет, недавно задался идеей написать PHP движок для своих нужд, так сказать и уровень повысить и получить что-то полезное. Почти сразу задался вопросом, а на сколько легко можно будет его взломать? Не секрет, что взломать можно все, что угодно, но вопрос в том, на сколько это будет проблематично и каждый ли хакер сможет это сделать?
Пожалуй, самая частая уязвимость в каком-либо проекте, будь то форма для комментариев, или форма логина. Без хороших проверок, эта штука ничего не стоит.
Одна из распространенных ошибок — это сохранять все что ты получил:
Любой человек может через отладчик добавить в тот же свой собственный пункт, пусть это и не дает большого взлома, но вещь крайне не приятная.
Я пришел к такому выводу:
Я считаю первое, это самое надежное, но если без них никуда, то тут есть несколько рекомендаций.
Однажды у меня был проект и мне нужно было что-то сделать с формой загрузки фотографий, когда я посмотрел код, там вообще не было проверок файла, даже проверки типа файла, просто, что приходит то и записывает. Первой моей мыслью было: «Что за х?». Порывшись еще немного я понял, что эту форму обрабатывает JS скрипт. Благо, это была админка и не каждый мог туда попасть.
Так вот, вывод. Так делать нельзя!
Причины две.
Уделяйте больше внимание проверки файлов, размер, тип, если это картинка, то ширина, высота. Часто, при выводе картинки делают проверку, только по одной стороне, по ширине или высоте, а теперь представьте, что какой-то умник залил картинку 20000x50px или наоборот, зрелище будет не из приятных.
Хоть это и удобная вещь, которая в дальнейшем избавит вас от рысканья в вашей почте или записях и поиска пароля, но посмотрим, что можно сделать если этот компьютер попадает в руки к вашему «другу».
Он может как-минимум двумя способами открыть настройки и там посмотреть сохраненные пароли, второе через отладчик поменять тип поля с password на text.
Для тех, кто в танке — это внедрение 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|myadmin|pma|и тд]. Ну и естественно использовать логины root|123 тоже запрещается.
Наиболее частое использование сессий – это поддержка авторизации пользователя, но хранение сессий – это тоже огромная тема. Первое, что нужно помнить, не храните ID сессии в открытом виде, а еще лучше, храните его в БД, и не давайте нескольким пользователям сидеть под одной сессией, проверяйте все, ip, user_agent, чтобы злоумышленник ничего не смог своровать. Так же советую посмотреть в сторону антиспуфинга, чтобы, хакер не смог подделать ip.
Куки нужны для хранение данных браузером, зачастую многие хранят в куках id сессии, чего делать не рекомендую, особенно в открытом виде. Если что-то храните в куках, то шифруйте, а тем более проверяйте, потому что тут как и с формами, нельзя доверять тому что пришло, так как изменить тоже не проблема. Кстати говоря тут вам снова может помочь соль, которую использовали для пароля пользователя.
Нужно грамотно продумать архитектуру вашего проекта, если вы будете делать весь проект костылями, да велосипедами, ни к чему хорошему это не приведет, только к дырам. Старайтесь использовать MVC, это поможет разграничить ваш код, на логические составляющие.
Ясное дело, что это должен быть линукс. На счет защищенности не знаю, но если у человека руки растут откуда надо, то настроить можно любой сервер.
Из слов людей понятно, что и виндос можно настроить, так что решение за вами.
Если кого обидел с виндосом, извините, но мне не приходилось с ним работать, мнение высказал опираясь на отзывы знакомых.
Еще можно написать про анализ трафика, но этим я не занимался, поэтому не могу знать наверняка, для этого есть специалисты.
Из вышесказанного можно сделать следующие заключения:
Все эти советы не избавят вас от угрозы взлома, но помогут её очень сильно усложнить, так что теперь не любой хацкер сможет её взломать. Так же помните, что валидация данных через javascript, это только пол дела, так как его можно спокойно отключить, проверяйте дважды все данные, ведь из всего вашего кода лишь 10% это вывод или работа с информацией, все остальное, это проверки и валидация данных.
PS. Про виндос я сказал, что не знаю точно. Просто все что читал, про неё плохо отзываются, так что извините, если кого обидел.
Эти советы для новичков, ни про какие ПДО и ОРМ им рассказывать нету смысла.
Я знаю, что эта информация известна многим, но статьи где будет изложено хотя бы столько информации я не нашел.
Никого удивить я не собирался, хотел, чтобы люди, которые мало в этом разбираются.
Формы
Пожалуй, самая частая уязвимость в каком-либо проекте, будь то форма для комментариев, или форма логина. Без хороших проверок, эта штука ничего не стоит.
Одна из распространенных ошибок — это сохранять все что ты получил:
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, это поможет разграничить ваш код, на логические составляющие.
Операционные системы
Ясное дело, что это должен быть линукс. На счет защищенности не знаю, но если у человека руки растут откуда надо, то настроить можно любой сервер.
Из слов людей понятно, что и виндос можно настроить, так что решение за вами.
Если кого обидел с виндосом, извините, но мне не приходилось с ним работать, мнение высказал опираясь на отзывы знакомых.
Еще можно написать про анализ трафика, но этим я не занимался, поэтому не могу знать наверняка, для этого есть специалисты.
Вывод
Из вышесказанного можно сделать следующие заключения:
- Информация, присланная пользователем, по умолчанию считается ненадежной
- Обрабатывать любую поступаемую информацию
- Надежные пароли
- Грамотная архитектура
- Следить за названиями потенциально уязвимых файлов
- Не использовать чужие скрипты, если использовать то проверять несколько раз. API в это число не входят, но используйте их так же на свой страх и риск
- Сессии, куки и SQL запросы. Следите за ними!
- Выбор ОС
- Поступающий трафик
Все эти советы не избавят вас от угрозы взлома, но помогут её очень сильно усложнить, так что теперь не любой хацкер сможет её взломать. Так же помните, что валидация данных через javascript, это только пол дела, так как его можно спокойно отключить, проверяйте дважды все данные, ведь из всего вашего кода лишь 10% это вывод или работа с информацией, все остальное, это проверки и валидация данных.
PS. Про виндос я сказал, что не знаю точно. Просто все что читал, про неё плохо отзываются, так что извините, если кого обидел.
Эти советы для новичков, ни про какие ПДО и ОРМ им рассказывать нету смысла.
Я знаю, что эта информация известна многим, но статьи где будет изложено хотя бы столько информации я не нашел.
Никого удивить я не собирался, хотел, чтобы люди, которые мало в этом разбираются.
