|
Модераторы: Aliance, skyboy, MoLeX, ksnk |
|
Opik |
|
||||||||||||||||||||||||||||||||||
Эксперт Профиль Группа: Vingrad developer Сообщений: 1918 Регистрация: 6.10.2004 Где: Рига Репутация: нет Всего: 55 |
Первое и самое главное правило программиста:
Никогда не доверяй тому, чего приходит от пользователя! Больше не буду мучить теорией т.к не люблю всё это, сразу к живым примерам. Ошибка №1: include-баг Ошибка №1 заключается в т.н include-баге. Описание: Вы делаете простенький движок сайта со следующей структурой:
и навигация происходит методов ссылок, типа:
т.е переменная $page содержит имя подлючаемого файла. Если Вы делаете сайт такого типа, то , что мешает хакеру воспользоваться данной дырой и сделать своё коварное дело? ничего а сделает он следующим образом: Метод №1: подставит своё значение page:
Тем самым благополучно получит содержимое этого файла на экран. (В нем хранятся пароли, однако на современных хостах они обычно зашифрованы Однако доступ можно получить будет к любому файлу.) Метод №2: Include своего скрипта. Если на сервере включена опция open_wrappers (Возможность работы с удаленными файлами), то хакер может поступить и так:
А файл hack.txt:
Если на сервере есть возможность пользоваться системыни командами, то хакер получит список всех файлов в данном каталоге. И что самое ужасное может выполнять Shell команды, что собственно влечет за собой взлом сервера. Решения: Функция basename. Эта функция вернет имя файла, чей путь был передан в качестве параметра. Если имя файла оканчивается на suffix, он также будет отброшен. Например Пример 1. Пример использования функции basename()
на деле:
Избежать инклуда можно указыв все возможные варианты:
Для полной безопасности я воспользовался уже известной функцией basename() Однако такой подход не удобен, если страниц много. Если же вам необходимо подключать файлы из разных каталогов, то можно поспользоваться оператором switch или старыми добрыми if elseif else…например:
Последний вариант, и наверное более верный, пропускать только "подходящие символолы", это A-Za-z0-9_- и делать это примерно так:
Ошибка №2: register_globals Сразу скажу, что это ошибкой не является, но это не мешает быть причиной взломов. На многих серверах эта опция PHP стоит в положении ON, что значит доступ к переменным окружения через их индекс напрямую, из вышеуказанного примера: $page, правильно будет использовать $_GET['page']. Сейчас кратко скажу почему оно именно так: Указывая суперглобальный(т.е доступным из любого места программы(main, class, function)) массив $_GET, мы говорим программе брать значение только из метода GET. Иначе хакер мог бы воспользоваться, например, методом POST и подставить своё значение и наоборот, соответсвенно.. Доступные суперглобальные массивы:
Далее распинаться по поводу register_globals я не хочу, т.к по этому поводу написана не одна статья... К добавок скажу, что на момент отладки скрипта включите отображение всех нотайсов (сообщений PHP):
в PHP5 лучше установить уровень E_STRICT И определяйте все значения заранее. Тем самым Вы избавитесь от возможных ошибок . Когда Вы заканчиваете режим отладки и выставляете Ваше творение на общее обозрение ставьте нулевой вывод ошибок, т.е
Ошибка №3: SQL-инъекции SQL – инъекции[b] – это SQL запросы, которые выполняет хакер для получения нужного ему результата. Приведу пример:
1) Узнать существующий логин, например админа – Admin; 2) Логиниться, если через форму, то, в поле для пароля ввести: ' or a = 'a Тем самым получится запрос:
Как бороться: 1) Перед подставлением параметра, обязательно его обрабатывать функцией mysql_escape_string(); Эта функция экранирует все SQL спец-символы в unescaped_string, вследствие чего, её можно безопасно. Эта функция идентична функции mysql_real_escape_string. Однако в последняя экраниует в зависимости от кодировки, в которой Вы работаете с БД; 2) Если переменная заведомо является числом, можно привести её к числовому виду:
Пару советов: 1) Тчательно шифруйте пароли доступа, например, функцией md5, чтобы усложнить расшифровку хеша, можете добавлять случайную строку. 2) Делать пароли на базу и FTP разными. Ведь имея возможность читать файлы, хакер сможет получить полный доступ к серверу. При хранении данных от пользователя, например в гостевых книгах делать проверки на html теги – htmlspecialchars(); 3) Если есть возможность обойтись без функции system. То лучше вообще её отключить (в конфиге disable_functions). В заключение: Если вы определили, что на сервере вашего провайдера возможны подобные действия, попросите администратора запретить их. если ваш скрипт написан безупречно, но вы вынуждены использовать shared hosting, вы ставите свой сайт под удар маразматиков, чьи криво написанные сайты лежат на том же сервере, что и ваш. Обсуждение здесь Это сообщение отредактировал(а) Opr - 19.5.2005, 02:57 |
||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
IZ@TOP |
|
|||
Панда-бир! Профиль Группа: Участник Сообщений: 4795 Регистрация: 3.2.2003 Где: Бамбуковый лес Репутация: 1 Всего: 73 |
Думаю что про метод №2 надо уточнить чтобы было понятно, записав в урл какую нибудь команду: cmd=rmdir(/)...
-------------------- Один из розовых плюшевых-всадников апокалипсиса... очень злой... Семь кругов ада для новых элементов языка Мои разрозненные мысли |
|||
|
||||
InfMag |
|
|||
… Профиль Группа: Завсегдатай Сообщений: 1037 Регистрация: 21.11.2004 Репутация: нет Всего: 4 |
Мдя, очень полезная статья, но она еще и дает информацию для самих хакеров...
Кстати, люди, если не хотите, чтобы юзеры видели содержимое ваших папок, набирая типа: http://mysite.ru/images/ , то просто в папках, не имеющих главных файлов посоздавайте пустые файлы просто - index.html ... Добавлено @ 19:21 И еще одна фишка, для людей таких как я - не очень любящих MySQL и использующих простые файлы и функцию explode. Для того, чтобы юзеры не могли набирая http://site.ru/data/passwd.dat увидеть ваши пароли, либо MD5 хеши (их можно легко подобрать, например через MD5 Inside), то создайте папку date в корневом коталоге Вашего сайта (то бишь где валяются папки site(или www), cgi-bin и прочие) и выложите все свои файлы, где храниться записываемая информация в нее. Если хотите инклудировать фалйы, то пишите include("../date/file.dat");. Дальше вы разберетесь. |
|||
|
||||
InfMag |
|
||||
… Профиль Группа: Завсегдатай Сообщений: 1037 Регистрация: 21.11.2004 Репутация: нет Всего: 4 |
Теперь идет речь о include баге...
Юзер может набрать http://site.ru/page.php?file=../date/passwd.dat Можно использовать обычные извращения типа:
Либо прописать замену двойных точек со слешем.
Зы. Кто не знает, то return 0; - означает, что дальше скрипт не поедет и остановится на этом месте. А return 1; - это спокойное продолжение дальше. Еще можно вместо 0 писать FALSE, а вместо 1 писать TRUE... |
||||
|
|||||
Opik |
|
||||||
Эксперт Профиль Группа: Vingrad developer Сообщений: 1918 Регистрация: 6.10.2004 Где: Рига Репутация: нет Всего: 55 |
InfMag
про index.html - можно просто запретить листинг директорий. на файлы с паролями обычно ставят права на чтение только сервером.
exit() или die() на что?
о basename внимательно читал? |
||||||
|
|||||||
pasha_kiev |
|
||||||
Новичок Профиль Группа: Участник Сообщений: 14 Регистрация: 26.1.2005 Репутация: нет Всего: нет |
Скажите,
а если у меня на стрнаице вывод переменной типа:
и потом отправка ее по почте и она задается в запросе
то хватит ли ее так обезопасить?
Это у меня в форме обратной связи Добавлено @ 14:40 И вообще, давайте затроним шире вопрос проверки переменных Это сообщение отредактировал(а) pasha_kiev - 26.1.2005, 14:39 |
||||||
|
|||||||
Vaulter |
|
|||
Эксперт Профиль Группа: Участник Клуба Сообщений: 1724 Регистрация: 30.12.2002 Где: бункер Репутация: нет Всего: 22 |
pasha_kiev
нельзя ли форму отправлять методом POST? тогда строки не будет в строке адреса page.php?string=dkl;skd;sdk |
|||
|
||||
pasha_kiev |
|
|||
Новичок Профиль Группа: Участник Сообщений: 14 Регистрация: 26.1.2005 Репутация: нет Всего: нет |
она так и отправляется через ПОСТ, просто я для пирмера показал так
Дело в том, что форма может и не передать переменную, и тогда ее может ввести через запрос кулХацкер |
|||
|
||||
pasha_kiev |
|
|||
Новичок Профиль Группа: Участник Сообщений: 14 Регистрация: 26.1.2005 Репутация: нет Всего: нет |
вообщем вопрос отсается открытым - о качественной проверке переменных вводимых из-вне.
|
|||
|
||||
Opik |
|
|||
Эксперт Профиль Группа: Vingrad developer Сообщений: 1918 Регистрация: 6.10.2004 Где: Рига Репутация: нет Всего: 55 |
pasha_kiev
если это данные SQL, то mysql_escape_string вполне хватит |
|||
|
||||
pasha_kiev |
|
|||
Новичок Профиль Группа: Участник Сообщений: 14 Регистрация: 26.1.2005 Репутация: нет Всего: нет |
нет, это простые переменные, которые потом передаются по мылу
|
|||
|
||||
Opik |
|
|||
Эксперт Профиль Группа: Vingrad developer Сообщений: 1918 Регистрация: 6.10.2004 Где: Рига Репутация: нет Всего: 55 |
pasha_kiev
если это само мыло, то смотреть регами на правильность емайла. Да думаю тут опасного ничего нет. |
|||
|
||||
pasha_kiev |
|
|||
Новичок Профиль Группа: Участник Сообщений: 14 Регистрация: 26.1.2005 Репутация: нет Всего: нет |
при чем здесь мыло?
я хочу узнать как надежно проверять переменные вводимые пользователем несмотря на цели их использования |
|||
|
||||
Opik |
|
|||
Эксперт Профиль Группа: Vingrad developer Сообщений: 1918 Регистрация: 6.10.2004 Где: Рига Репутация: нет Всего: 55 |
pasha_kiev
всё как раз зависит от целей. |
|||
|
||||
IZ@TOP |
|
|||
Панда-бир! Профиль Группа: Участник Сообщений: 4795 Регистрация: 3.2.2003 Где: Бамбуковый лес Репутация: 1 Всего: 73 |
pasha_kiev, для переданных данных об адресе мейла будет одна проверка, при проверке номера ICQ, адреса сайта - другие, при передаче данных в MySQL третья, при записи в файлы четвертая. И для разных случаев необходимы разные проверки, например при ситуации когда надо чтобы в тесте созхранялся HTML, делаем одно, а когда нужно чтобы его там небыло - другое.
-------------------- Один из розовых плюшевых-всадников апокалипсиса... очень злой... Семь кругов ада для новых элементов языка Мои разрозненные мысли |
|||
|
||||
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | PHP: Избранное | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |