В миналата статия започнахме темата с интернет инжекциите и днес ще разгледаме какво представлява инжектирането на вреден код в базата данни и как да се защитим от тази атака.

В миналата статия не го казах директно, но ще го направя сега: никога не оставяйте потребителите да въвеждат свободно информация през адресната лента на браузера и формите във вашия сайт – за коментар, имейл, регистрация и т.н.

Филтриране на въведената инфромация

Информацията от всяко поле трябва да се обработва от собствен филтър съобразно целта и вида на събираната информация.

Ако в полето трябва да се въведе телефонен номер, филтъра трябва да разрешава само арабски цифри.

Ако в полето се въвежда имейл адрес, филтъра трябва да потвърди, че е въведен само един синтактично коректен имейл адрес.

В полето за коментари филтъра трябва да замени специалните символи с техните ASCII заместители и да постави обратна наклонена черта пред единични и двойни кавички (escaping).

Филосфията е същата като заключването на външната врата на дома – всеки си заключва къщата вместо да се надява, че само добри хора ще влизат през тази врата.

Защо в интернет тази толкова очевидна практика се пренебрегва, аз лично нямам отговор, по-скоро няма да го напиша.

Подобни неща не трябва да ви се случват

Някой от читателите може би ще се изкуши да си помисли: този Иван го гони яко параноята.

Размисли пак по темата за моята параноя като прочетеш следното:

Най-голямата афера с кражба на 45 милиона номера на кредитни карти, довела до загуби за около 200 милиона долара за компанията TJX и дъщерни компании е причинена от ползване на некриптирана безжична интернет връзка и същата тази беззъба (както ще се увериш след малко) mysql инжекция.

Някой си е отворил новия лаптоп в тузарското кафене в Амстердам и е решил да си прегледа баланса на банковата сметка, не е забелязал другия клиент с лаптоп в ъгъла и ... е бръкнал в торбата с грешките.

Така че, по-добре прочети тези статии внимателно и направи това, което ти препоръчаме, преди да установиш, че си спонсорирал местните хакери с няколко хилядарки.

Да се върнем на темата с MySQL инжекцията.

Уникалното в случая е, че за да успее тази инжекция трябва да има двоен пропуск от страна на скрипта:
1. не се филтрира информацията, въведена от потребителя във формата.
2. не се добавят обратна наклонена черта пред кавичките когато се записва информацията в базата данни.

На този адрес може да намерите много примери за MySQL атаки ( статията е на английски език):
http://www.unixwiz.net/techtips/sql-injection.html

Защо не трябва да се използва РНР функцията magicquotesgpc ?

Поради следните причини:
• Несигурност - никога не можете да сте сигурни функцията дали е on или off
• Производителност – не цялата информация от формите е предназначена за импортиране в база данни, така че системата извършва ненужна работа. В този случай ползването на функцията addslashes() е за предпочитане.
• Некоректност – неприятно впечатление прави четенето на текст (например в имейл, или коментар), който е пълен с обратно наклонени черти (escaping) преди всяка кавичка – корекцията на този недостатък на *magicquotesgpc() изисква допълнителна интензивна употреба на stripslashes*().

Т.е. ефекта от употребата на тази функция предизвиква много повече проблеми, отколкото реално решава – затова и от версия 4.2. на РНР функцията е по подразбиране изключена (off), a от версия 5.3 не се поддържа изобщо.

За мен е необяснимо, че дори сега клиенти ни пишат да активираме функцията защото тяхната програма давала грешка при инсталацията.

Едно такова писмо от клиент за съпорта означава 90% сигурна работа в бъдеще с този сайт поради ползването на очевидно стара и компрометирана по отношение на сигурността програма и по-лошо – поради нежеланието на уебмастера да се движи в синхрон с актуалните интернет тенденции.

И така, нека завършим темата със защита от mysql инжекция – решението е обидно елементарно и се свежда до ползването на готова PHP функция - *mysqlrealescape_string*().

Ще ви дам и една много полезна комбинирана функция, която първо проверява дали е активирана *magicquotesgpc() и ако да, втора функция stripslashes() възстановява въведената информация като изтрива символите (escaping). Накрая фунцията mysqlrealescape_string*() приготвя текста за въвеждане в базата данни като прави mysql инжекцията невъзможна.

Ето и самата функция: function clean($str) {
$str = @trim($str);
if(getmagicquotesgpc()) {
$str = stripslashes($str);
}
return mysqlrealescapestring($str);
} и начинът, по който се използва при регистрация на нов потребител: function clean($str) {
$str = @trim($str);
if(getmagicquotesgpc()) {
$str = stripslashes($str);
}
return mysqlrealescapestring($str);
}----------

$name = clean($POST['name']);
$password = clean($POST['password']);

$qry = "INSERT INTO members(name, passwd) VALUES('$name', '".sha1($password)."')";

Всяка от горните променливи, постъпващи от регистрационната форма е дефинирана и спокойно може да се въведе в базата данни (разбира се, това не е пълен код, а само пример).

Към тези променливи може да се приложат и филтри според вида на очакваната коректна информация, които подробно разгледахме в статията за предпазване от email инжекция.

Надявам се, че информацията в тази статия ви е била полезна.