Kursova 116679
23
Икономически университет – гр. Варна ЦЕНТЪР „МАГИСТЪРСКО ОБУЧЕНИЕ“ специалност “Приложна информатика” по БЕЗОПАСНОСТ И ЗАЩИТА „Филтриране и валидиране данните на PHP уеб приложение“ Разработил: Проверил: Асен Сапунджиев Спец.Приложна информатика , курс 7, Фак.N116679 Доц.д-р Стефан Дражев Варна 2013
Transcript of Kursova 116679
Икономически университет – гр. Варна
ЦЕНТЪР „МАГИСТЪРСКО ОБУЧЕНИЕ“
специалност “Приложна информатика”
по
БЕЗОПАСНОСТ И ЗАЩИТА
„Филтриране и валидиране данните на PHP уеб приложение“
Разработил: Проверил:
Асен Сапунджиев
Спец.Приложна информатика ,
курс 7, Фак.N116679
Доц.д-р Стефан Дражев
Варна
2013
2
Съдържание
Въведение .................................................................................................................................. 4
1. Видове атаки. ..................................................................................................................... 6
A1 – Injection: ........................................................................................................................ 6
A2 –Broken Authentication and Session Management: ......................................................... 6
A3 – Cross-Site Scripting (XSS): ........................................................................................... 6
A4 –Insecure Direct Object References: ............................................................................... 7
A5 – Security Misconfiguration: ........................................................................................... 7
A6 – Sensitive Data Exposure: ............................................................................................... 7
A7 – Missing Function Level Access Control : ..................................................................... 7
A8 – Cross-Site Request Forgery (CSRF): ............................................................................ 8
A9 – Using Components with Known Vulnerabilities: .......................................................... 8
A10 –Unvalidated Redirects and Forwards: .......................................................................... 8
2. Валидиране на входните данни ....................................................................................... 9
Проверка на целочислени числа. ...................................................................................... 10
Проверка на логически стойности. ................................................................................... 12
Проверка на числа с десетична запетая. ........................................................................... 13
Проверка чрез регулярни израз. ........................................................................................ 13
Проверка на URL адреси.................................................................................................... 14
Проверка за валидност на IP адрес. .................................................................................. 15
Проверка за валидност на email адрес. ............................................................................. 16
3. Филтриране на данните. ................................................................................................. 17
Филтриране стрингове ....................................................................................................... 18
Филтриране на URL адрес. ............................................................................................... 18
Филтриране на специални символи. ................................................................................. 18
Филтриране на email адрес. ............................................................................................... 19
Филтриране на URL адрес. ................................................................................................ 19
3
Филтриране на цели числа. ................................................................................................ 20
Филтриране на числа с десетична запетая. ...................................................................... 20
Филтриране чрез функция дефинирана от потребител. .................................................. 21
Използвана литература .......................................................................................................... 23
4
Въведение
В наши дни използването на интернет е ежедневие. Всяка уважаваща себе си
организация има страница, която да я представя в Интернет.
Уеб приложение e приложение, до което потребителите имат достъп през мрежа
като Интернет или интранет. Терминът също може да означава софтуерно приложение,
което е написано на поддържан от браузър програмен език (като JavaScript,
комбинирано с браузърно-рендериран маркиращ език като HTML) и което разчита
обичайните уеб браузъри да успеят да рендират приложението.
Уеб приложенията са популярни заради наличието навсякъде на уеб браузъри и заради
удобството при ползването на браузъра като клиент или тънък клиент.
Уеб приложенията може да се разделят основно на две групи:
Статични (всяка страница от сайта се изгражда сама за себе си. Тя представлява
самостоятелен HTML файл, в който се съдържат всички елементи от страницата - както
дизайнът, така съдържанието на самата страница. Когато посетител кликне върху
адреса на тази страница, сървърът директно я изпраща за разглеждане към браузъра на
посетителя.).
Динамични (дизайнът (общото оформление на сайта и навигацията) се дефинира в
отделен общ за всички страници шаблон (темплейт), а съдържанието на всяка отделна
страница се съдържа в база данни, откъдето се "извиква" за динамичното генериране на
страницата. Когато посетител кликне върху някой елемент от менюто, системата за
управление на съдържанието "поръчва" от базата данни нужното съдържание и
изпраща така "сглобената" страница на потребителя. ).
Независимо от вида на сайта, при изграждането му трябва да мислим и за неговата
сигурност. Повечето слабости в сигурността са в следствие на един или друг вид
доверие във въведените от потребителя данни. Основен принцип при разработката на
сигурни приложения е, че НЕ трябва да се гласува доверие на нищо и никого.
PHP е скриптов език със синтаксис базиран на C и Perl. Използва се предимно в Web-
среда за реализиране на широк кръг от услуги. Той е един от най-популярните езици за
програмиране в Интернет и популярността му расте непрекъснато.
PHP се разпространява под отворен лиценз (PHP License), който по своята същност
е BSD лиценза и който позволява безплатно разпространяване на програмния код на
5
интерпретатора на езика, както и създаването на производни интерпретатори под други
лицензи с уговорката, че тези интерпретатори не могат да включват PHP в името си.
Фактът, че PHP се разпространява свободно, го прави удачен избор за изграждане
на Web-сървър базиран изцяло на свободни продукти -
GNU/Linux, Apache, MySQL/PostgreSQL и др.
При поискване, кодът, който е написан на PHP се интерпретира от уеб сървъра на който
е качен, и резултатът се връща на уеб браузърът. Потребителят не може да види
чистият PHP код без да има достъп до самият файл в който той е записан. По този
начин е помислено за сигурността.
Самият език е преносим на много изчислителни архитектури и операционни системи
като GNU/Linux, UNIX, Mac OS X, Windows.
6
1. Видове атаки.
A1 – Injection:
Пропуски за вмъкване на код, като вмъкване на код в База данни (SQL), ОС и др.
Вмъкването на код се изразява във на информация (код) към обработчика на заявки
(код), като част от команда или заявка. „Вредните“ данни подадени от атакуващия (или
по погрешка от неразбиращ потребител) могат да объркат обработчика на заявки (код)
да изпълни нежелана команда или да получи достъп до чувствителна информация, за
която няма право на достъп.
A2 –Broken Authentication and Session Management:
Функционалността на приложението свързано с оторизацията и управлението на
сесиите са често не са изпълнени правилно. Това позволява на „нападателите“ да
достигнат до пароли, ключове, маркировките на сесиите или използват други пропуски
недостатъци на изпълнението за да вземат идентификацията на други потребители.
A3 – Cross-Site Scripting (XSS):
XSS се проявява, когато приложението приема непроверена информация и я изпраща
към браузъра без правилна валидация и верификация. При успешна XSS атака се
изпълнява скрипт на потребителските браузъри, при което може да се „открадне“
потрбителската сесия на „жертвата“, да се показва друго съдържание или да се
7
пренасочват потребителите към други сайтове (да се пренасочва съдържанието от
попълнените форми към друг получател, като се заблуждава „жертвата“).
A4 –Insecure Direct Object References:
Директна препратка към обект се проявява, когато разработчика излага препратка към
вътрешен обект, като файл, директория или ключ от база данни, без контрол за достъп
или друга защита, атакуващият може да манипулира тази препратка и да получи достъп
до информация, за която няма права. Пример за такава атака е, когато предаваме име на
файл през GET. Тогава атакуващият може да промени името на файла и ако нямаме
проверка, дали потребителя има право да види този файл, той ще получи достъп до
него.
A5 – Security Misconfiguration:
Добрите практики за сигурност изискват да имаме определени настройки за
приложението, приставките, сървър на приложения, уеб сървър, сървър за бази данни,
както и платформата. Всички тези настройки трябва да бъдат дефинирани, изпълнени и
подържани (обновявани), тъй като много от тях не са настроени оптимално със
зададените им стойности по подразбиране, това включва и редовно обновяване на
използвания от нас софтуер.
A6 – Sensitive Data Exposure:
Много уеб приложения нямат адекватна защита при използването на чувствителна
информация, като за кредитни карти, идентификационни номера и идентификационни
данни за удостоверяване на самоличността. Нападателите могат да променят така слабо
защитената информация, могат да „откраднат“ самоличността на потребителите, да
извършат измами с кредитните карти на потребителите на системата или да извършат
други престъпления. Чувствителната информация изисква допълнителна защита, като
криптиране при съхранението или при препредаването ѝ. Особено внимание е нужно,
когато се обменя информация между браузъра и приложението.
A7 – Missing Function Level Access Control :
Почти всички уеб приложения проверяват правата за достъп на ниво функция, преди да
се направи тази функционалност видима в потребителския интерфейс. Въпреки това,
8
приложенията трябва да изпълняват едни и същи проверки за контрол на достъпа и на
сървъра, когато всяка функция е достъпна. Ако заявките не са проверяват, нападателите
ще могат да се възползват от достъп до неразрешена функционалност.
A8 – Cross-Site Request Forgery (CSRF):
При тази атака се принуждава браузъра на „жертвата“ да изпрати подправена HTTP
заявка, включваща сесийната бизквитка на „жертвата“ и всичката нужна информация за
автоматична идентификация към уязвимото уеб приложение. Това позволява
нападателя да принуждава браузъра на „жертвата“ да генерира заявки със
самоличността на „жертвата“, като приложението приема, че те са валидни заявки от
„жертвата“.
A9 – Using Components with Known Vulnerabilities:
Уязвими компоненти, като например библиотеки, рамки и други софтуерни модули
почти винаги се изпълняват с пълна привилегия. Така че, ако се използват, те могат да
причинят сериозни загуби на данни или се получи достъп за контрол на сървър.
Приложенията, които използват тези уязвими компоненти може да намалят защитата
си и дават възможност на редица възможни атаки и въздействия.
A10 –Unvalidated Redirects and Forwards:
Уеб приложения често пренасочват и препращат потребителите към други страници и
сайтове. Използването на ненадеждни данни, за да се определи дестинацията
страниците. Без правилно валидиране, атакуващите могат да пренасочат жертвите към
фишинг сайтове или злонамерен софтуер, или да получат достъп до неоторизирани
страници
Пропуските в сигурността са част от функционалността на програмата. Но, те
използват много специфичен модел. Компютърният софтуер е основан на
математическата концепция за функциите. Функционалностите на дадено приложение
се реализира чрез подпрограми. Подпрограмите включват функции, процедури,
шаблони и методи. Въпреки, че всяка от тези дефиниции се различава една от друга, за
да се разбере софтуерната уязвимост могат да бъдат използвани взаимнозаменяемо.
9
Целта на всяка функция е да получи някаква входяща информация да я обработи и да
върне резултат. Входящата информация може да бъде предоставена от самата
програма или от потребителя.
Когато дадена функция получава на входа си непроверени данни от потребителя, може
да възникне уязвимост. Ако тази информация се подава към база данни, може да се
появи SQL инжекция. Ако входът е върнат обратно на потребителя в браузъра може да
се реализира крос- сайт скриптова уязвимост. Ако входът е предоставен на системата,
ние можем да имаме командна инжекция. Ако входът е твърде голям, за да се сложи в
заделената памет, може да се реализира препълване на буфера.
Както се вижда от гореизложеното в основата на всички атаки е липсата на проверка и
валидация на входните данни. Затова в следващите редове ще се опитам да представя
някои от добрите практики за проверка и валидация на входните данни.
Едно от най-големите предимства на PHP е лесната му употреба. За съжаление същата
тази полза работи срещу PHP. Много нови програмисти забравят всички мерки за
сигурност, или липсата на опит ги спира да реализират елементрна функционалност за
проверка на входните данни. PHP включва разширение за да помогне с този процес.
Разширението на PHP филтър, има много от функции необходими за проверка на
данните въведени от потребителя. Изпълнявана на сървъра тази филтрация е еднаква и
стандартна за цялото приложение. Това допринася за по-лесно четене на кода, тъй като
всички ще използват едни и същи функции, а не да се налага да се създават наши
собствени, с това при откриването на пропуск се коригира на едно място и цялото
приложение се възползва от промяната. Това ще доведе до засилване на PHP
сигурността. Програмистите могат лесно да прилагат прост, но сигурен начин за
филтриране на данни. С така предоставената функционалност е обидно за всеки
разработчик да пуща в употреба код като следния:
<?php
include($_GET['filename']);
?>
Или още по- лошо за заявка към база данни нещо като следния код:
<?php
10
mysql_query("INSERT INTO table (field_one, field_two)
VALUES ({$_POST['var1']}, {$_POST['var2']})";
?>
2. Валидиране на входните данни
В настоящата глава ще разгледам вградените разширения в PHP (функциите filter_var,
filter_input) за валидация на данни. Filter_var позволява да валидираме съдържанието
през зададения филтър, докато filter_input позволява да посочим външна променлива
(като $_POST или $_GET) , да валидираме всичко в нея и да върне резултат. Двете
функции имат едни и същи филтри. Важно е да се има предвид, че двете функции имат
различно поведение от is_нещо() функциите. Те непроверяват типа на дадената
стойност, а я връщат ако отговаря на критерия или връщат FALSE ако стойността не
отговаря на зададения филтър.
Проверка на целочислени числа.
Проверката дали дадена стойност е цяло число се извършва, като се зададе параметър
на функцията FILTER_VALIDATE_INT. Ето и няколко примера:
<?php
/*** an integer to check ***/
$int = 1234;
/*** validate the integer ***/
echo filter_var($int, FILTER_VALIDATE_INT);
?>
Резултата от изпълнението на горния код, ще бъде показано числото 1234. Това
означава, че въведената стойност е валидно цяло число. Ако зададем стойност на
променливата $int например ‘abc123’ или FALSE или празен низ то на екрана няма да
се изведе нищо. Функцията filter_var() ни позволява да добавим още един параметър,
който е масив с име options и в него можем да добавим елементи с ключове min_range,
max_range, с помощта подадената стойност се проверява дали е цяло число от
посочения интервал. Ето и кода:
<?php
/*** an integer to check ***/
$int = -2;
/*** lower limit of the int ***/
$min = -10;
/*** upper limit of the int ***/
$max = 100;
/*** validate the integer ***/
11
echo filter_var($int, FILTER_VALIDATE_INT,
array("options" => array(
"min_range"=>$min, "max_range"=>$max)));
?>
Функцията ни позволява да използваме и само един от параметрите min_range и
max_range, като с това можем да проверим съответно дали стойността е по- голяма или
по- малка от зададената.
Разновидност на функцията filter_var() е filter_var_array(), която позволява да
филтрираме масив.
<?php
/*** an array of values to filter ***/
$arr = array(10,"109","", "-1234", "some text",
"asdf234asdfgs", array());
/*** create an array of filtered values ***/
$filtered_array = filter_var_array($arr,
FILTER_VALIDATE_INT);
/*** print out the results ***/
foreach($filtered_array as $key=>$value)
{
echo $key.' -- '.$value.'<br />';
}
?>
Резултата от горния код ще бъде:
0 – 10
1 -- 109
2 --
3 -- -1234
4 --
5 --
6 – Array
От резултата се вижда, че винаги върнатия резултат ще ни бъде цяло число или
логическо FALSE.
Също така можем да проверим и шестнайсетични и осмични числа. Това става като
дадем флаг FILTER_FLAG_ALLOW_OCTAL,FILTER_FLAG_ALLOW_HEX.
12
Проверка на логически стойности.
С функциите за валидиране можем да проверяваме стойността за нейното логическо
значение. Следните стойности връщат логическо TRUE (истина):
1
01
0х1
"1"
"yes"
"true"
"on"
TRUE
Функцията не прави разлика между курсора на символите т.е. няма значение дали
буквите са малки или големи. Като връща резултат 1, ако стойността е логическа
„истина“ и логическо FALSE (“лъжа”), ако стойността не е логическа „истина“. Ето
един пример за проверка на стойностите в многомерен масив дали са със стойност
логическа „истина“ или „лъжа“:
<?php
/*** a multi dimensional array ***/
$array = array(0,1,2,3,4, array(0,1,2,3,4));
/*** create the list of values ***/
$values = filter_var($array, FILTER_VALIDATE_BOOLEAN,
FILTER_REQUIRE_ARRAY);
/*** dump the values ***/
var_dump($values);
?>
Резултатът от изпълнението на кода е:
array(6) {
[0]=> bool(false)
[1]=> bool(true)
[2]=> bool(false)
[3]=> bool(false)
[4]=> bool(false)
[5]=> array(5) {
[0]=> bool(false)
[1]=> bool(true)
[2]=> bool(false)
13
[3]=> bool(false)
[4]=> bool(false)
}
}
Проверка на числа с десетична запетая.
Проверката на числа с плаваща запетая става по същия начин, както за целочислените
числа, като позволява в масива с опциите да добавим и опция и за разделителя. Ето и
един пример за използването на функцията:
<?php
/*** an array of values ***/
$array = array(1.2,"1.7","", "-12345.678", "some text",
"abcd4.2efgh", array());
/*** validate the array ***/
$validation_array = filter_var($array,
FILTER_VALIDATE_FLOAT,array('flags'=>
FILTER_REQUIRE_ARRAY,
'options'=>array('decimical'=>'.')));
/*** dump the array of validated data ***/
var_dump($validation_array);
?>
Ето резултата от горния код:
array(7) { [0]=> float(1.2) [1]=> float(1.7) [2]=> bool(false) [3]=> float(-
12345.678) [4]=> bool(false) [5]=> bool(false) [6]=> array(0) { } }
след като сме проверили стойностите, можем да ползваме новия масив с
„чистите“ стойности. В масива опции, с параметъра decimical можем да
определим разделителя за цяла и дробна част.
Проверка чрез регулярни израз.
Това е един от най- силните техники за проверка на входни данни, тъй като
можем да зададем точен вид и какви символи да включва. Ето един пример за
проверка на email адрес:
<?php
/*** an email address ***/
14
$email = "[email protected]";
/*** the pattern we wish to match against ***/
$pattern = "/^\S+@[\w\d.-]{2,}\.[\w]{2,6}$/iU";
/*** try to validate with the regex pattern ***/
if(filter_var($email, FILTER_VALIDATE_REGEXP,
array("options"=>array("regexp"=>$pattern))) === false)
{
/*** if there is no match ***/
echo "Sorry, no match";
}
else
{
/*** if we match the pattern ***/
echo "The email address is valid";
}
?>
Резултата от кода ще бъде валиден email адрес или „лъжа“. Функциите за валидиране
дават грешки при въвеждането символи на кирилица, за това е добра идея, когато се
проверяват текстови стойности да се проверява с регулярни изрази дали те съдържат
такива символи.
Проверка на URL адреси.
Проблема при валидацията адресите на интернет ресурсите е тяхното разнообразие и
форма. В заявката към даден ресурс, чрез адреса може да се подават и различни
параметри под различна форма. Валидацията отговаря на изискванията на стандарт
http://www.ietf.org/rfc/rfc1738.txt. Функцията може да бъде с един от следните
параметри, като „флагове“:
FILTER_FLAG_PATH_REQUIRED- изисква в адреса да има и път към ресурс
FILTER_FLAG_QUERY_REQUIRED- изисква в адреса да има и параметри
Ето един пример за валидация да URL адрес:
<?php
/*** a URL with a path ***/
$url = "http://test.org/path/to/foo";
/*** try to the validate the URL ***/
if(filter_var($url, FILTER_VALIDATE_URL,
FILTER_FLAG_PATH_REQUIRED) === FALSE)
{
/*** if there is no match ***/
echo "Sorry, $url is not valid!";
}
15
else
{
/*** if the URL is valid ***/
echo "The URL, $url is valid!";
}
?>
Този пример ще върне, че въведения адрес е валиден, защото има и път към ресурс
(path/to/foo). Ако използваме REST URLs тогава чрез този флаг може да проверяваме
има ли параметри в заявката.
Проверка за валидност на IP адрес.
С функцията можем да валидираме IP v4 и IPv6, също така можем да проверяваме дали
адреса е от „частно“ или „запазено“ множество. Функцията може да бъде изпълнена със
следните флагове:
FILTER_FLAG_IPV4
FILTER_FLAG_IPV6
FILTER_FLAG_NO_PRIV_RANGE- връща „лъжа“, ако се въведе IPv4 от следните
диапазони :10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. За IPv6 започващи с FD или FC.
FILTER_FLAG_NO_RES_RANGE- връща „лъжа“, ако се въведе IPv4 от следните
диапазони :0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24 и 224.0.0.0/4. Този флаг е неприложим
за IPv6 адреси.
Ето и един пример:
<?php
/*** an IP address ***/
$ip = "192.168.10.20";
/*** try to validate a non reserve range address ***/
if(filter_var($ip, FILTER_VALIDATE_IP,
FILTER_FLAG_NO_RES_RANGE | FILTER_FLAG_NO_PRIV_RANGE)
=== FALSE)
{ echo "$ip is within a reserved or
private range";
}
еlse {
echo "$ip is not within a reserved or private
range";
}
?>
Резултата от изпълнението на кода ще бъде, че адреса е от „частната или запазена“ зона
на адреси.
16
Проверка за валидност на email адрес.
Това е може би най- важната проверка за всяко едно уеб приложение, защото email
адреса се използва, като потребителско име при автентикация или за връзка с
потребителя, което позволява при регистрация да поискаме от потребителя да последва
линк, с който да активира акаунта си, така можем да проверим дали потребителя е
„истински” и собственик на предоставения ни адрес. Ето и пример как можем да
валидираме предоставения ни адрес.
<?php
/*** an email address ***/
$email = "[email protected]";
/*** try to validate the email ***/
if(filter_var($email, FILTER_VALIDATE_EMAIL) === FALSE)
{
/*** if it fails validation ***/
echo "$email is invalid";
}
else
{
/*** if the address passes validation ***/
echo "$email is valid";
}
?>
Функцията няма флагове при валидирането на email адреси.
Това са функциите за валидиране на данните въведени от потребителите предоставени
ни от вградените функции в PHP. Хубавото от използването на тези функции е, че
всички разработчици имат възможността да използват еди и същи функции и съответно
да получават едни и същи резултати при еднакви входни данни, функциите са част от
езика и се обновяват и подържат. Лошото е, че библиотеката е част от езика и
съответно се променя с всяка следваща версия, с цел оптимизация и поправка на
открити пропуски. Това може да доведе до разлика в резултата при изпълнение на една
и съща функция на сървъри с различни версии или при обновяване на версията на
използвания от нас сървър. Тези функции подържат освен филтриране/ верификация на
въведените данни и изчистване на информацията от „вредни” части код.
17
3. Филтриране на данните.
Филтрирането на информацията става чрез същите функции разгледани по- горе като се
подават параметри за филтриране на данните. Функциите подържат следните
параметри за филтриране:
FILTER_SANITIZE_EMAIL- премахва всички символи без букви, цифри и !#$%&'*+-
/=?^_`{|}~@.[].
FILTER_SANITIZE_ENCODED - URL- извлича елементите от адреса, има възможност
за разкодиране на низ или премахване на специални символи.
FILTER_SANITIZE_MAGIC_QUOTES- Пред знаците единични кавички ('), двойни
кавички ("), обратно наклонена черта (\) и NUL (на NULL байт), поставя символ за
„неутрализиране“ (\).
FILTER_SANITIZE_NUMBER_FLOAT- премахва всички символи с изключение на
цифрите знаците +,- и еЕ.
FILTER_SANITIZE_NUMBER_INT- премахва всички символи с изключение на
цифрите и знаците + и -.
FILTER_SANITIZE_SPECIAL_CHARS- премахва специалните символи използвани в
HTML кода ('"<>& ), символите с код по-малък от 32 по и допълнително имаме
възможност да кодираме или премахнем други специални символи.
FILTER_SANITIZE_FULL_SPECIAL_CHARS- Някои знаци имат специално значение
в HTML, и трябва бъдат представени от HTML субекти, ако искат да запазят техните
значения. Тази функция връща низ с тези реализации, като например '&' (ampersand)
се представя като '&'.
FILTER_SANITIZE_STRING- премахва таговете, с добавяне на флагове можем
допълнително да премахнем или кодираме специални символи.
FILTER_SANITIZE_STRIPPED- премахва таговете, с добавяне на флагове можем
допълнително да премахнем или кодираме специални символи.
FILTER_SANITIZE_URL- премахва всички символи с изключение на буквите,
цифрите и следните символи: $-_.+!*'(),{}|\\^~[]`<>#%";/?:@&=.
FILTER_UNSAFE_RAW-по подразбиране не прави нищо, чрез добавяне на флагове
може да премахне или кодира специалните символи.
18
Филтриране стрингове
Филтрирането на стрингове ни позволява да изчистим и/или да кодираме въведената
информация от потребителя и да я ползваме или съхраним без това да доведе до
непредвидено поведение на приложението. Ето и един пример:
<?php
/*** a string with an ampersand ***/
$string = "http://test.org/file.php?foo=1&bar=2";
/*** sanitize the string ***/
echo filter_var($string, FILTER_SANITIZE_STRING,
FILTER_FLAG_ENCODE_AMP);
?>
Резултата в браузъра ще бъде http://test.org/file.php?foo=1&bar=2 а кода който ще
бъде подаден от сървъра към браузъра ще бъде http://test.org/file.php?foo=1&bar=2
както се вижда вече символа е преобразуван.
Филтриране на URL адрес.
Филтрирането на URL става с подаване на опцията FILTER_SANITIZE_URL.
Резултата е стринг изчистен от непозволените символи и кодиране на специалните
символи. Ето един пример:
<?php
/*** a url string ***/
$url = "http://test.org/a dir!/file.php?foo=1&bar=2";
/*** sanitize (url encode) the url ***/
echo filter_var($url, FILTER_SANITIZE_ENCODED);
?>
Резултата от изпълнението на горния код ще бъде :
http%3A%2F%2Ftest.org%2Fa%20dir%21%2Ffile.php%3Ffoo%3D1%26bar%3D
2. Както се вижда интервалите и специалните символи са кодирани.
Филтриране на специални символи.
С подаване на параметъра FILTER_SANITIZE_SPECIAL_CHARS премахваме
символите '"<>& и тези които имат код по- малък от 32. Ето и пример:
<?php
/*** our string ***/
$string = "fooкириллицаbar";
/*** echo the sanitized string ***/
19
echo filter_var($string,
FILTER_SANITIZE_SPECIAL_CHARS);
?>
Резултата от изпълнението ще бъде fooкириллицаbar , но ако добавим флага
FILTER_FLAG_STRIP_HIGH то резултата ще бъде foobar, тъй като символите на
кирилица имат код по-голям от 127 и затова ще бъдат премахнати.
Филтриране на email адрес.
Преди това разгледахме как може да проверим дали въведения стринг отговаря на
изискванията за валидност на email адрес, но въпреки това в името на адреса може да се
съдържат много специални символи($-_.+!*'(),{}|\\^~[]`<>#%";/?:@&=), което
позволява да се въведе нежелан код към приложението. Това е и причината да
филтрираме вече миналия валидация адрес. Ето един пример:
<?php
/*** an email address ***/
$email = "kevin&friends@(foo).ex\\ample.com";
/*** sanitize the email address ***/
echo filter_var($email, FILTER_SANITIZE_EMAIL);
?>
Резултата от горния пример ще бъде kevin&[email protected], чист и
отговарящ на изискванията адрес, а по- добрия начин би бил първо да
филтрираме и после да валидираме. Това би изглеждало по следния начин:
<?php
/*** an email address ***/
$email = "kevin&friends@(foo).ex\\ample.com";
/*** sanitize the email address ***/
echo
filter_var(filter_var($email,FILTER_SANITIZE_EMAIL),
FILTER_VALIDATE_EMAIL);
?>
Филтриране на URL адрес.
Този филтър се използва да се премахнат забранените символи от въведен
адрес. Използва се по следния начин:
<?php
/*** a URL ***/
$url = "http://www.teÆst.oФrg";
/*** sanitize the URL ***/
20
echo filter_var($url, FILTER_SANITIZE_URL);
?>
Резултата ще бъде http://www.tеst.org .
Филтриране на цели числа.
Резултата от филтрирания стринг ще бъде само числа и знаковете + и -. Ето и пример:
<?php
/*** an interger ***/
$int = "abc40def+;2";
/*** sanitize the integer ***/
echo filter_var($int, FILTER_SANITIZE_NUMBER_INT);
?>
Резултата от изпълнението на горния код ще бъде:
40+2, който е върнат стринг от функцията, но не е число и ако го преобразуваме на
число ще се вземе стойността до математическия оператор.
Филтриране на числа с десетична запетая.
Филтъра позволява да изчистим всички невалидни символи от подадения вход, като
можем допълнително да определи символа за разделителя между цяла и дробна част,
хилядните също така и да позволим числа с научен запис (1.23Е5).
Допълнителните флагове към функцията са:
FILTER_FLAG_ALLOW_FRACTION
FILTER_FLAG_ALLOW_THOUSAND
FILTER_FLAG_ALLOW_SCIENTIFIC
Ето и един пример:
<?php
/*** a floating point number ***/
$float = "abc40.4def";
/*** sanitize the float ***/
echo filter_var($float, FILTER_SANITIZE_NUMBER_FLOAT,
FILTER_FLAG_ALLOW_FRACTION);
?>
Резултата ще бъде 40.4 . Също като и при целочислените числа върнатия резултат е
стринг. Така че ако има знаците +,-,е,Е във входния израз върнатия резултат може да
бъде невалидно число, а низ от числа и горепосочените символи.
21
Филтриране чрез функция дефинирана от потребител.
Това позволява да разширяваме функционалността, чрез добавяне на нови функции
дефинирани от нас. Употребата е изключително лесна, ето и един пример:
<?php
$str="<script>alert('fddf')</script>";
function makeASCII($char=0){
return '&#'.ord($char).';';
}
$strarray= str_split($str);
$strencoded=filter_var($strarray,FILTER_CALLBACK,array(
'options'=> 'makeASCII'));
$str=implode('',$strencoded);
echo $str;
?>
Резултат от изпълнението на кода ще бъде:
<script>alert('fddf')</script> , а кода който се подава към браузъра ще бъде:
<script>aler&#
116;('fddf')</sc&#
114;ipt> ,а ако се подаде стойността на променливата $str
без да се обработи ще се изпълни кода и ще се появи изскачащ прозорец със
съобщение.
Горе разгледаните филтри и флагове могат да бъдат използвани по аналогичен начин и
със следните функции:
filter_has_var — проверява дали променлива от определен тип съществува.
filter_id — връща цифровото представяне на даден филтър чрез подаване на
неговото име (number_int - 519).
filter_input_array — взема външна променливи и при поискване се филтрира или
валидира ($_GET, $_POST и др.).
filter_input — взема определена променлива чрез подаване на нейното име и я
филтрира или валидира ($_GET[‘var’], $_POST[‘var’] и др.).
filter_list — връща списък с подържаните филтри.
filter_var_array — приема множество от променливи и при поискване се
филтрират или валидират.
filter_var — филтрира дадена променлива със зададените параметри.
22
В заключение бих казал, че предоставените ни функции от езика не са съвършени, но
със сигурност са по- добре от нищо и ако нямаме нужния опит е по- добре да ползваме
тях от колкото да се опитваме да откриваме топлата вода. Функциите са част от езика и
това е една добра причина да ги ползваме, защото са изпробвани от много потребители
и откритите бъгове се коригират своевременно.
Нека не забравяме, че сигурността на нашето приложение трябва да бъде непрекъснат
процес и ние винаги трябва да се грижим за него, ако искаме то да ни служи по начина,
който ние бихме искали.
23
Използвана литература
1. http://bg.wikipedia.org/wiki/%D0%A3%D0%B5%D0%B1_%D0%BF%D1%80%D0%B8
%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
2. http://thehackerspost.com/2013/02/owasp-top-10-2013-application-security.html
3. http://bretthard.in/2012/10/the-security-and-developer-passion-dilema/
4. http://www.phpro.org/tutorials/Filtering-Data-with-PHP.html
5. http://thehackerspost.com/2013/02/owasp-top-10-2013-application-security.html
6. http://phpchunk.net/2011/06/validate-sanitize-data-php-filter-part-1/
7. http://www.php.net/manual/en/filter.filters.validate.php
8. http://www.ietf.org/rfc/rfc1738.txt
9. http://bg.wikipedia.org/wiki/REST
10.http://www.php.net/manual/en/ref.filter.php
