1. ИКОНОМИЧЕСКИ УНИВЕРСИТЕТ – гр.
Варна
ЦЕНТЪР „МАГИСТЪРСКО ОБУЧЕНИЕ“
Защита при създаване на PHP-приложения
в Интернет
Представил:
Пламен Христов
Проверил:
доц. д-р Стефан Дражев
фак. №116556
Варна 2013

2. Съдържание
Въведение ............................................................................................................................................ 3
Общи съображения ............................................................................................................................ 3
Инсталация като CGI ......................................................................................................................... 4
Инсталация като Apache модул ...................................................................................................... 5
Сигурност на файловата система .................................................................................................. 6
Сигурност на базата данни .............................................................................................................. 7
Дизайн на базата ............................................................................................................................ 7
Връзка с базата ............................................................................................................................... 8
SQL инжекции .................................................................................................................................. 8
Използвана литература................................................................................................................... 10

3. Въведение
PHP е мощен език и интерпретатор без значение дали се изпълнява
вграден в уеб сървър или директно като CGI скрипт. Има
възможност за достъп до файлове, изпълняване на команди,
отваряне на мрежови връзки и др. Тези свойства правя всичко,
което се изпълнява на уеб сървър несигурно. PHP е направен
специално да е по-сигурен език за писане на CGI програми от Perl
или C, с правилния избор от компилаторни и опции по време на
изпълнение, добри практики за писане на код той може да ви даде
точно свободата и сигурността, която ви трябва.
Гъвкавостта на конфигурацията на PHP е еквивалентна на
гъвкавостта на код. PHP може да бъде използван за цели сървърни
приложения, с цялата сила на потребителската обвивка. Как се
създаване обкръжението и колко е сигурно зависи изцяло от PHP
разработчика.
Общи съображения
Изцяло сигурна система е невъзможно, затова се използва подход,
който балансира риска и използваемостта. Ако всяка променлива,
която потребителя въвежда изисква сложна валидация, то това ще
доведе до това потребителите да търся други начини, заобикалящи
сигурността. Би било отнело половин час на обиквен потребител да
попълни сложните форми.

4. Следната фраза си струва да бъде запомнена: „Системата е добра
(сигурна), колкото най-слабата й връзка“. Ако всички транзакции се
записват на база време, място, вид на транзакцията, но
потребителят се верифицира базирайки се на единична бисквитка
(cookie), то валидността на потребителските транзакции е
значително по-слаба.
Когато тествате, имайте предвид, че няма да успеете да предвидите
всички възможностти дори за най-простите страници. Входните
данни, които очаквате няма да имат нищо общо с тези на кракер с
голям опит или с тези на котки ходеща по клавиатурата. Затова е
най-добре да се гледа на кода от логическа перспектива, да се
различава къде могат да се въведат неочаквани данни. Интернет е
пълен с хора, които се опитват да счупят вашия код, да съборят
сайта ви, да публикуват неподходящо съдържание или като цяло да
направят деня си интересен. Няма значение дали имате малък или
голям сайт, щом сте онлайн, вече сте жертва. Много кракерски
програми не различават размера, просто обхождат блокове от IP
адреси и търсят жертви.
Инсталация като CGI
Използването на PHP като CGI е опция за конфигурации, които
поради определена причина не искат да използват PHP интегрирано
като модул в сървърния софтуер (Apache) или ще използват PHP с
различни видове CGI обвивки за създаване на сигурност chrootи
setuidсреди за скриптове. Тази конфигурация обикновено изисква
инсталиране на изпълнимо PHP байнъри в cgi-bin директорията.
CERT препоръчва да не се слагат интерпретатори в cgi-bin. Въпреки
това, че PHP може да се използват като независим интепретатор,
той е създаден с възможност за защита от атаките, които тази
конфигурация правят възможни:

5. - Достъп до системни файлове: http://my.host/cgibin/php?/etc/passwdИнформацията от заявката в URL адреса
след въпросителния знак се предава като аргумент на
командния ред към интерпретатора. Обикновено
интерпретаторите отварят и изпълняват файла специфициран
като първи аргумент на командния ред. Когато се изпълнява
като CGI, PHP отказва да интерпретира аргументи на
командния ред.
- Достъп до уеб документи на сървъра: http://my.host/cgibin/php/secret/doc.htmlПътят, който е част от URL адрес след
името на PHP байнърито, /secret/doc.html е конвенция за
спецификацията на името на файла, който трябва да бъде
отворен и интерпретиран от CGI програмата. Обикновено
някои конфигурационни директиви (Apache: Action) се
използват за пренасочване на заявки към документи като
http://my.host/secret/script.phpкъм PHP интерпретатора. За
съжаление, ако заявката е подадена в такава форма не се
правят проверки от уеб сървъра за файла /secret/script.php, а
само за /cgi-bin/php. По този начин всеки потребител, който
може да достъпи /cgi-bin/php има възможност за достъп до
всеки защитен документ на уеб сървъра. В PHP директивите
за изпълнение на програмата (cgi.force_redirect, doc_root,
user_dir) могат да бъдат използвани за предпазване от тази
атака.
Инсталация като Apache модул
Когато PHP се използва като Apache модул, то наследява
разрешенията на Apache потребителя (обикновено това е nobody).
Товаиманяколконяколко влияния върху сигурността и
автентикацията. Например, ако използвате PHP за да достъпите
база данни и тя няма вътрешен контрол за достъпа, то ще трябва да
направите базата достъпна за nobody потребителя. Това означава,
че злонамерен скрипт може да достъпи и промени базата, дори без
потребителко име и парола. Бихте могли да предотвратите това
чрез Apache authorization или да създадете собствен модел чрез

6. LDAP, .htaccessфайлове и да ги включите към вашите PHP
скриптове.
Често, когато сигурността стигне до момента, в който PHP
потребителя съдържа минимален брой рискове, то тогава се
установява, че PHP няма достъп за писане на файлове или
директории. Или че базата данни не е достъпна за достъп и
промяна.
Често срещана грешка в сигурността е да се дадат root привилегии
на Apache. Ескалирането на привилегиите е много опасно и може да
изположи цялата система на риск.
Съществуват няколко прости решения. Чрез използването на
open_basedir може да се контролира и ограничи кои директории са
позволени за използване от PHP.
Сигурност на файловата система
PHP е обект на сигурност вграден в повечето сървърни системи
считайки правата за достъп на файл или директория. Това
позволява да се контролира кои файлове на файловата система
могат да бъдат прочетени. Трябва да се внимава с файлове, които
могат да се достъпват от всеки в системата.
Тъй като PHP е създаден да позволява достъпа до файловата
система, то е напълно възможно да се създаде PHP скрипт, който
позволява четенето на файлове като /etc/passwd, да модифицира
мрежови връзки, да изпраща спам от задачи за принтера и др.
Например следващия скрипт, където потребителят избира дали да
изтрие файл от собствената си директория. Това предполага
ситуация в която PHP уеб интерфейса е редовно използван за
мениджър на файлове, затова Apache потребителя има достъп за
триене.
<?php
// remove a file from the user's home directory
$username = $_POST['user_submitted_name'];
$userfile = $_POST['user_submitted_filename'];

7. $homedir
= "/home/$username";
unlink("$homedir/$userfile");
echo "The file has been deleted!";
?>
Поради това, че потребителското име и паролата се въвеждат от
която и да е форма, могат да се въведат такива принадлежащи на
друг човек. В този случай бихте искали да използвате друга форма
на автентикация. Представете си какво би се случило ако
променливите за въвеждане бяха “../etc” и “passwd”. Има 2 вариант,
които могат да се използват за предотвратяване на подобни атаки:
- Лимитиран достъп на PHP байнърито
- Проверка на всеки променливи, които се въвеждат
Сигурност на базата данни
В днешно време базите данни са кардинален компонент от всяко
уеб приложение, позволяващо на уеб сайт да представя динамично
съдържание. Много от личната и частна информация може да бъде
записана в базата, затова трябва сериозно да се взема предвид
сигурността на данните. За да извлечете или запишете каквато и да
е информация, трябва първо да се свържете с базата данни, да
изпратите заявка, да вземете резултат и след това да затворите
връзката. Най-използвания език за интеракция с базите е Structured
Query Language (SQL).Кактосепредполага PHP не може да предпази
базата.
Дизайн на базата
Първата стъпка е създаването на базата данни, освен ако не
използвате такава на чужд източник. Когато базата данни се
създаде тя притежава собственик. Обикновено собственикът може
да прави всичко с обектите в базата и за да могат други
потребители да я ползват трябва да се създадат нови привилегии.

8. Приложенията никога не трябва да правят връзка с базата данни
чрез собственик, защото подобен потребилен може да модифицира
цялото съдържание. Могат да бъдат създадени различни
потребители спрямо всеки аспект на приложението и да им бъде
разрешен достъп до специфични част от обектите. Препоръчително
е да не се създава цялата бизнес логика в приложението , а да се
ползват инструментите на базата като views, triggers, rules. Когато
системата се разшири, има възможност други клиенти да искат да
се свържат и ще трябва логиката да се дублика, докато
инструментите на базата правят това ненужно.
Връзка с базата
Бихте могли да използвате криптирани връзки чрез SSL за
допълнителна сигурност или да използвате ssh за криптиране на
мрежовия трафик между клиента и сървъра. Ако някое от предните
бива използвано, то следенето на трафика и използването на
информацията му ще бъде трудно за атакуващия.
SQL инжекции
Много от уеб разработчиците не знаят как SQL заявките могат да
бъдат фалшифицирани и предполагат, че те са надежни команди.
SQL заявките могат да бъдат използвани за промяна контрола на
достъп, заобикаляне на стандартни защити за автентикация и др.
Директните SQL инжекции е техника, при която атакуващия създава
или използва съществуващи SQL команди за да получи достъп до
скрити данни, да модифицира съществуващи такива или да изпълни
системни команди на машината. Ако не съществува валидация на
входните данни и връзката до базата данни е осъществена чрез
собственик, то атакуващия може да създаде друг собственик във
вашата база. Например:

9. <?php
$offset = $argv[0]; // внимание! Няма валидация
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET
$offset;";
$result = pg_query($conn, $query);
?>
Нормалните потребители натискат върху „next‟ , „prev‟ връзките
където $offset е част от URL адреса. Този скрипт очаква, че
входната променлива $offset е число. Въпреки това, какво би
станало, ако някой се опита да използвано следната форма в
urlencode() вид:
0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
select 'crack', usesysid, 't','t','crack'
from pg_shadow where usename='postgres';
--
Ако това се беше случило, то скрипта щеше да създаде потребител
собственик. Забележете, че 0; се използва за да се въведе валидно
число за $offset.
Техники за избягване:
- Никога не правете връзка до базата чрез собственика
- Използвайте “prepared statements”. Могат да се намерят в
PDO, MySQLi модулите и други библиотеки
- Проверявайте дали входните данни имат правилния тип. PHP
има широк набор от валидиращи функции
- Ако приложението очаква числово съдържание може да
използвате ctype_digit() или просто да промените типа с
settype()

10. Добре е също така да поддържате лог със заявките чрез вашия
скрипт или базата. Очевидно това не може да предотврати горните
атаки, но би било полезно за намиране източника на проблема.
Използвана литература
http://php.net
http://www.amazon.com/Essential-PHP-Security-ChrisShiflett/dp/059600656X/ref=sr_1_1?ie=UTF8&qid=1389452171&sr=81&keywords=php+security
http://www.amazon.com/Pro-PHP-Security-ApplicationImplementation/dp/1430233184/ref=sr_1_2?ie=UTF8&qid=1389452171&
sr=8-2&keywords=php+security
http://www.amazon.com/Securing-PHP-Applications-TriciaBallad/dp/0321534344/ref=sr_1_3?ie=UTF8&qid=1389452171&sr=83&keywords=php+security
http://php.net/manual/en/security.php
https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet