2008ий рік став для мене часом перемін як професійних так і життєвих. Перемін на краще. Я вірю, що всі зміни, якими б вони не були, приносять лиш позитивний досвід, нехай навіть не одразу, а у довготривалій перспективі. Від кожної події ми виносимо щось нове, дещо таке, яке пізніше обов’язково прийде у нагоді.

Отже, визначні події за цей рік:

1. Побував на першій українській конференції веб-розробників UAWeb-2008, яка я сподіваюсь, стане щорічною традицією з не менш цікавими доповідями й людьми Саме ця подія стала рушієм для мого подальшого професійного розвитку і надала мені напрями у ньому.
2. Започаткував цей блоґ Спочатку я був сповнений ентузіазму для його розвитку, але деякі інші події нажаль пригальмували цей порив.
3. Змінив кілька місць роботи. Не хочу казати нічого поганого про колективи, часткою яких я був - вони були чудові. Бажаю їм лиш найкращого у майбутньому!
4. Дещо змінив свої професійні орієнтири. Пропрацювавши більше двох років переважно із PHP та стеком технологій пов’язаних із цією мовою (LAMP), мене переклинило і я тепер дуже зацікавлений у клієнтських технологіях у вигляді JavaScript (прекрасна мова, якщо хто не в курсі ) та серверних в особі Python та фреймворку Django. В будь-якому випадку я досі цікавлюсь PHP та всім, що із ним пов’язано. Встиг навіть із Erlang досить близько познайомитись. На мою думку, розробник має завжди дізнаватись щось нове, пробувати себе у різних технологіях і ніколи не зупинятись - не боятись щось змінювати, адже застій веде до упадку.
5. Спробував працювати на себе (фрілансером). Часом у вільний від основної роботи час, часом в якості основної роботи. Розвіяв багато міфів про щастя роботи на себе - це значно важче. І як виявилось, поки не для мене, принаймні у якості основної роботи. Щоправда, і зараз приймаю замовлення, якщо мене хтось знаходить і має суттєвий запас часу
6. Нарешті отримав місце для життя, яке можу назвати власним (нехай і не назавжди) у чудовому районі Києва - Троєщині (кияни мене зрозуміють ). Нехай воно не в найліпшому місці, невелике й мабуть не назавжди, але воно найкраще адже я його поділяю із коханою людиною.
7. Розпочав власний проект. Так-так, черговий план захоплення світу Ну най не всього, а хоч його часточки. Він зараз в процесі розробки у вільний час, якого не так багато, як хотілося б. Скажу лиш, що це тематичний портал з блоговою платформою, деякими специфічними фічами. Поки планів з монетизації нема - лиш деякі ідеї, але це поки не суттєво.

Що ж стосується планів на новий рік, то їх у мене є.

1. Пожвавити цей блоґ. Дуже хочу писати багато і цікаво… ну хоча б періодично. Думаю слід зменшити об’єм постів в обмін на частішу публікацію, адже великі глибокі статті вимагають дуже багато часу і мабуть не всім цікаво читати занадто багато.
2. На початку весни закінчити свій проект. Повністю випустити мінімальну версію. Не певний, чи це вийде, одна з причин - не знаю навіть, що робити із дизайном. Дизайнерських навичок не маю, а відверту лажу робити не хочу. Отже, якщо хтось має бажання допомогти або має знайомих, які можуть допомогти, керуючись лиш ентузіазмом - прошу, звертайтесь.
3. Поліпшити свої знання у Python, спробувати себе поза вебом.
4. Зайнятись спортом. Маючи сидячу роботу прогягом кількох років, починаєш розуміти, що фізчна форма поступово деградує, і постійні проблеми зі здоров’ям про це однозначно нагадують.
5. З’їздити кудись за кордон. Жодного разу не був поза Україною і вже давно не їздив кудись відпочівати. Хочу на Sziget Хоча українські фестивалі мене все так само цікавлять.

Зараз стало модним писати про кризу і її наслідки, а я не буду Лиш побажаю, щоб ніхто не зважав ні на які махінації, політиків та провокаторів, а вірив у власний здоровий глузд та близьких людей. Все інше - не суттєве.
Чарівна палиця прямує до virua та GrAndSE.

Міжсайтовий скриптинг (XSS) - це найчастіше використовуваний тип атак на веб-сайти (нещодавню статистику можна побачити у першій замітці із серії про безпеку у PHP). Для такої атаки, зловмисник зберігає у базі даних сайта, спеціально створений CSS, HTML або JavaScript. Пізніше, коли цей контент виводиться користувачу, скажімо у якості коментаря у блозі чи повідомлення на форумі, він змінює відображення сторінки чи виконує код, мета якого - вкрасти дані користувача, передати конфіденційні дані на лівий сервер чи якимось чином змінити функціонування сайта.

XSS - дуже популярний вид атаки та його часто дуже легко застосувати, адже неймовірно велика кількість сайтів просто виводить ввід користувача, без будь-якої попередньої фільтрації. Фактично, вдала XSS атака є результатом неякісного коду програми.

Два основних види XSS атак це:

1. Пряма дія - вставлений контент відображується тому користувачу, який його власне вставив;
2. Збережена дія - будь-яка кількість користувачів побачить (і, можливо, відчує) вставлений контент.

Метою прямої дії зазвичай є вивчення методів фільтрації вводу програмою, якщо такий взагалі є для того, щоб сконструювати більш значиму атаку. Збережена ж дія є найбільш небезпечним типом XSS, адже у результаті можуть бути вкрадені конфіденційні дані користувачів чи порушене функціонування самого сайту.

У цій частині ми розглянемо деякі методи боротьби із XSS (інші будуть розглянуті у наступних частинах).

Закодувати все!

Отже, як же нам убезпечити увесь ввід від XSS? На щастя, PHP має вдосталь вбудованих функцій, які видаляють або кодують спеціальні HTML символи.

Перша з них - htmlspecialchars. Вона приймає строку із введеними даними та кодує символи & (амперсанд), < (менш ніж), > (більш ніж), ” (подвійні лапки) та (необов’язково) ‘ (одинарні лапки). Всі вони перетворюються у відповідні HTML-сутності такі, як &lt; (<), &amp; (&) і т.п. Це змушує браузер трактувати ці символи виключно як літеральні (тобто такі, які не мають ніякого спеціального змісту).

<?php
    $input = '<a href="very.bad.com"><img src="click.gif" /></a>';
    $encoded = htmlspecialchars($input); //&lt;a href="http://very.bad.com"&gt;&lt;img src="click.gif" /&gt;&lt;/a&gt;
?>

Тож краще кодувати навіть найпростіший ввід.

Вгамування атрибутів

Якщо необхідність кодування теґів HTML очевидна, то не всі усвідомлюють цю необхідність і для атрибутів теґів.

Значна кількість користувацького вводу врешті-решт опиняється у атрибутах теґів, які можуть надавати елементу стиль чи навіть виконувати JavaScript. Для ясності розглянемо приклад. Користувач відправляє URL, щоб вказати на цікаву сторінку. Цей ввід використовується для того, щоб сформувати теґ <a>: <a href=”http://webdeveloping.com.ua”>Блоґ про веб-розробку українською</a>. Наче нормальна ситуація, а тепер уявімо, що користувач вставить у свій ввід лапки. І як тільки закриваючі лапки будуть знайдені, браузер закриє цей атрибут і відкриє новий. І тут зловмисник може зробити все, що завгодно.

Також слід пам’ятати, що типово одинарні лапки не будуть закодовані, а тільки подвійні. Тож, якщо ви використовуєте одинарні лапки у вашому HTML, це треба вказати функції htmlspecialchars другим параметром таким чином: htmlspecialchars(”‘”, ENT_QUOTES). Інакше можливий такий сценарій:

<?php
    $input = htmlspecialchars("#' real_url='http://mailicious.com'
    fake_url='http://php.net'
    onmouseover='window.status=this.attributes.fake_url.value; return true'
    onclick='window.location=this.attributes.real_url.value'");
 
    echo "<a href='$input'">Корисне посилання</a>;
?>

Отже, що робить цей ввід? А він користується саме тим, що htmlspecialchars типово не кодує одинарні лапки, а сторінка їх використовує. Вводячи два атрибути real_url та fake_url, які є відповідно справжньою адресою та підробленою, цей код вставляє підроблену у строку статусу браузера при наведенні на посилання, та переходить на справжню при натисканні. Таким чином наш користувач навіть не помітить, що його хочуть відправити кудись не туди.

HTML-сутності та фільтри

Символ амперсанда часто використовується як початок HTML-сутності, але також може бути задіяним для обходу різних фільтрів. Нехай у нас існує фільтр, що знаходить всі строки “PERL” та видаляє їх. Користувач може легко закодувати всі символи цієї строки у їх відповідні HTML-сутності, таким чином обходячи фільтр стороною:

<?php
    $input = '&#80;&#69;&#82;&#76;'; // PERL в закодованому вигляді 
    echo str_ireplace('perl', '', $input);
    // Виведе незмінену строку, адже str_ireplace не знайде того, що треба
?>

Отже, перед фільтром нам треба закодувати ввід, щоб розбити сутності. Всі амперсанди будуть закодовані у &amp;, тож спеціально створений ввід не пройде у запланованому вигляді:

<?php
    $input = '&#80;&#69;&#82;&#76;'; // PERL в закодованому вигляді
    $input = htmlspecialchars($input); // &amp;#80;&amp;#69;&amp;#82;&amp;#76;
    echo str_ireplace('perl', '', $input); //Все так само нічого не відфільтрує
    // Тепер браузер виведе &#80;&#69;&#82;&#76;
?>

Це вже краще, але насправді, кодування амперсандів - це не завжди добре та в деяких випадках може навіть зашкодити. Це актуально наприклад для застарілих сайтів, які не використовують Unicode. Уявімо таку ситуацію (поширену на сайтах, що не думають про інтернаціоналізацію): є сторінка із формою у кодуванні ISO-8859-1 (типова латинська), а користувач вводить дані у кодуванні CP-1251 (типова кирилічна). Браузер автоматично переведе всі символи із вводу у HTML-сутності задля їх правильного виводу. Ми ж на стороні сервера кодуємо всі амперсанди із вводу, які в свою чергу втрачають початковий зміст, та в результаті отримуємо нечитабельний варіант.

Тож як нам передбачити цю ситуацію? Правильніше за все - використовувати Unicode Але, якщо це з деяких причин неможливо - найліпшим варіантом є задіяти регулярний вираз, щоб перевести у дійсні сутності лише подвійно-закодовані символи:

<?php
    preg_replace('!&amp;#([0-9]+);!', '&#\1;', htmlspecialchars($input));
?>

Цим виразом ми захоплюємо подвійно-закодовані літери (адже шукаємо лише чисельні значення після &amp;#) та замінюємо їх на дійсні сутності. Ми вирішуємо проблему із подвійно-закодованими літерами, але знову повертаємо попередню проблему. В такому випадку спеціально закодоване користувачем “PERL” буде знову виведене браузером, оминаючи фільтр.

Отже, нам потрібна краща логіка обробки HTML-сутностей. Для цього існує функція preg_replace_callback - вона задіює, передану їй функцію до кожного знайденого набору, що задовольняє регулярному виразу. Цій функції передається один масив, першим елементом якого є набір, що задовольняє виразу, а всіма наступними є набори, які задовольняють всім під-виразам. Тепер у нас є все, щоб дещо покращити наш фільтр:

<?php
    $input = htmlspecialchars('&#80;&#69;&#82;&#76;'); 
    function decode($matches) { 
        if ($matches[1] > 255) { // не-ASCII
                return '&#'.$matches[1].';'; // переводимо у дійсну сутність
        } 
        if (($matches[1] >= 65 && $matches[1] <= 90) || // A - Z 
            ($matches[1] >= 97 && $matches[1] <= 122) || // a - z 
            ($matches[1] >= 48 && $matches[1] <= 57)) { // 0 - 9 
                return chr($matches[1]); // переводимо у літеральну форму
        } 
        return $matches[0]; // все інше залишаємо без змін
    } 
    echo preg_replace_callback('!&amp;#([0-9]+);!', 'decode', $input); // PERL
?>

У цьому прикладі функцію decode викликає preg_replace_callback та використовує під-вираз, який має чисельне значення для порівняння. Якщо це значення більше за 255 (тобто виходить за межі таблиці ASCII), то воно має бути перетворене у дійсну сутність, змінюючи &amp; на &. Для значень іншого діапазону ми робимо додаткову перевірку. Якщо це спеціальний символ (такий як ‘ чи <), то залишаємо все без змін, інакше (цифра або латинська літера) - переводимо у звичайну літеральну форму.

Однак навіть цього недостатньо, адже залишається декілька моментів із HTML-сутностями. Наприклад, сутність не потребує точки із комою в кінці. Тож &#45 - цілком дійсна сутність, яку браузери чудово зрозуміють. Але в такому випадку наші регулярні вирази проваляться та нічого не знайдуть. Більше того, числове значення сутності може бути представлене у вигляді шістнадцяткового числа, тож &#x05A - теж цілком дійсна сутність. А наші попередні регулярні вирази це також не зрозуміють. Отже, вдосконалюємо далі:

<?php
    preg_replace_callback('!&amp;#((?:[0-9]+)|(?:x(?:[0-9A-F]+)));?!i', 'decode', $input);
?>

Трошки ускладнили наш вираз. Тепер з одного під-виразу утворилось двоє: перший спрацьовує, коли ми маємо одну або більше цифру, другий - якщо є символ “x”, за яким йде одна або більше цифра чи літера латинського алфавіту з діапазону [A-F]. Окрім того, ми більше не вимагаємо символ “;” в кінці. Тут слід зазначити, що квантор “?:” означає те, що ми не зберігаємо результат під-запиту, таким чином у результуючому масиві буде так само два елементи. Модифікатор “i” в кінці виразу повідомляє про те, що порівняння відбувається незалежно від регістру символів.
Тепер розглянемо відповідні доповнення до функції розкодування:

<?php
    function decode($matches) { 
        if (!is_int($matches[1]{0})) { 
                $val = '0'.$matches[1] + 0; 
        } else { 
                $val = (int) $matches[1]; 
        } 
        if ($val > 255) { 
                return '&#'.$matches[1].';'; 
        } 
        if (($val >= 65 && $val <= 90) || 
            ($val >= 97 && $val <= 122) || 
            ($val >= 48 && $val <= 57)) { 
                return chr($val); 
        } 
        return $matches[0]; 
    }
?>

Тут ми додали перевірку і приведення для шістнадцяткових чисел. Спочатку перевіряємо чи перший символ результату є числом. Якщо це так, то маємо десяткове число, приводимо його до цілочислового типу (int), інакше (перший символ - “x”) - дописуємо 0 спочатку (таким чином PHP починає розуміти, що йому згодували шістнадцяткове число, тобто маємо щось типу 0×5F) та неявно переводимо до десяткового формату, додаючи до нашого числа 0. Далі код не змінився.
Ось такий буде результат:

<?php
    $input = '&#80&#69&#82&#76;&#60;&#X041;&#1103;&#x30C9;'; 
    // результат обробки:
    // PERL&amp;#60;A&#1103;&#x30C9;
?>

Ось тепер все добре, і після цієї обробки нарешті можна використовувати літеральну фільтрацію

To be continued…

У цій нелегкій справі проектом прийнято на озброєння повний арсенал соціальних інструментів: створено групи присвячені цій події у популярних соціальних мережах (MySpace, Facebook та Beebo), спеціальний аккаунт у Twitter, значки для блогів, навіть ось такий цікавий проект для організації тематичних вечірок

Наразі набільш багаті на обіцянки США (звичайно ж), Польща, Албанія(!) Італія, Бразилія, Німеччина та Японія. В Україні дано більш ніж 1,5 тисячі обіцянок, а всього близько 200 тисяч і стрімко зростає. На мою думку, це чудова ідея піарщиків Mozilla з популяризації цього вільного браузера.

Наостанок хочу побажати проекту успіхів у здобутті рекорду та популяризації Firefox, адже, чим більше людей користуватиметься Firefox та іншими, альтернативними до ІЕ, браузерами - тим більше буде мотивації у Microsoft робити кращі (за поточні ІЕ) баузери, та тим легше житиметься багатьом веб-розробникам

• Кросбраузерність
• Універсальність - скрипт має вірно працювати навіть при зміні/додаванні нових елементів
• Неможна використовувати фреймворки та бібліотеки JavaScript
• Неможна змінювати HTML чи CSS, всі зміни лиш у відповідному JS-файлі. Отже практикуємо підхід “unobtrusive JavaScript” (ненав’язливий JS).

Сам конкурс триватиме до кінця цього місяця (травня) тож ще є вдосталь часу. Ну і найголовніше - переможець отримує логотип свого блоґу від автора. У будь-якому випадку, непогана вправа для вільного часу.

Тож щасти вам, якщо бажаєте спробувати!

• Модулі поведінки моделей (Model Behavior)
• Три стандартних модулі поведінки: Acl, Translate, Tree
• Підтримка DB2, Oracle та Sybase
• Підтримка інтернаціоналізації та локалізації
• Три нових компоненти ядра: Auth, Cookie, Email
• Нові класи ядра: Set, Debugger, HttpSocket, Socket
• Іменовані агрументи для дій
• Більше можливостей для кешування - підтримка: APC, memcache, xcache, файлового та кеша, основаного на базі даних
• Більше можливостей валідації даних
• Чотири нових допоміжних класів: Js, Paginator, Rss, Xml
• Підтримка тем
• Інтегровані тести
• Багато-багато інших нових можливостей та виправлень

Я розробляю деякі проекти (серед них власна CMS для веб-студії) за допомогою цього фремворка вже близько року, всі були зроблені на нестабільних версіях гілки 1.2. Мушу сказати, що навіть альфа версії були стабільніші за більшість релізів іншого програмного забезпечення Реліз CakePHP 1.2 має стати чимось на стільки стабільним, наскільки стійкою та непорушною є скеля.

Зміни у репозиторії коду зараз відбуваються кожні кілька хвилин. Наразі розробники цього open source проекту шукають добровольців, які б могли допомогти із наступними речами:

• Долучення патчів та тестів
• Надання інформації про відтворення багів
• Пошук нових багів
• Допомога команді документування

Як пише один з розробників фреймворку, Маріано Іглесіас, допомога проекту - хороший шанс долучитись до одного з найдинамічніших та найцікавіших PHP проектів із відкритим кодом.

Від себе хочу сказати… нарешті!:) Гілка 1.2 перебуває у нестабільній стадії вже більше року і дуже багато змінилось за цей час у кращу сторону. Думаю, багато людей чекають на цей реліз. У одній з наступних заміток чекайте на огляд фреймворку CakePHP та порівняння із іншими популярними бібліотеками. А якими фреймворками користуєтесь ви?

Для оцінки маштабів цієї проблеми приведемо приклад:

<?php
    $userId = "4'; DELETE FROM users;"; //можливий ввід
    mysql_query("SELECT * FROM users WHERE id='$userId'");
?>

Цей шмат коду має на меті вибрати з бази даних дані користувача за переданим у скрипт ідентифікатором. І, якщо ви використовуєте MySQL, то власне так і зробить Адже ця БД не підтримує декілька запросів у одному виклику. А якщо ж ваша БД - SQLite чи PostgreSQL, то вони, не довго думаючи, спочатку виберуть потрібні дані, а потім видалять всі дані з таблиці “users”.

Екранування вводу

Проблемою у даному випадку є недостатнє екранування і перевірка вводу. Про це вже було достатньо сказано у статті про перевірку вхідних даних. Давайте розглянемо це у контексті SQL Injection. Найпростіший захист від цього надає вбудований у PHP механізм magic_quotes_gpc. Коли він увімкнений, перед лапками (одинарними чи подвійними) та іншими загрозливими символами автоматично буде вставлено зворотній слеш (”\”).

Однак це недостатнє рішення, оскільки не екранує деякі спеціальні до SQL символи та й не завжди цей механізм увімкнено. Тож різні розширення для роботи із БД мають свої спеціалізовані механізми екранування. У MySQL це функція mysql_real_escape_string та mysql_escape_string. Різниця між ними лиш у тому, що перша екранує відносно указаного їй у параметрах кодування, а друга до цього не чутлива. Приклад використання:

<?php
    if (get_magic_quotes_gpc()) {
        $userId = stripslashes($userId);
    }
 
    $userId = mysql_real_escape_string($userId);
    mysql_query("SELECT * FROM users WHERE id='$userId'");
?>

У цьому коді спочатку перевіряється наявність розширення magic_quotes_gpc, в разі чого його дія реверсується, щоб не виникло ситуації з подвійним екрануванням. Також специфічні до БД функції є незамінними при зберіганні двійкових даних. Якщо залишити їх неекранованими - вони можуть конфліктувати із форматом збереження даних самої БД. Функції екранування про це знають і не допускають можливої втрати даних.

У деяких БД, наприклад, PostgreSQL - окремі функції відповідають за екранування двійкових даних. Наприклад, функція pg_escape_bytea застосовує Base64-подібне кодування до вхідних даних. Щоправда, таке кодування накладає обмеження на пошук - до них неможна застосовувати такі запити як “LIKE ’str%’”, оскільки значення, збережене у БД, не обов’язково буде сходитись із тим, яке шукається за запитом. Звичайно, це не проблема для більшості веб-додатків, адже збереження у двійковому вигляді зазвичай необхідно для таких даних як картинки та зтиснені файли, а вони не є предметом глибинного пошуку.

Підготовлені вирази

На жаль, не для всіх БД існують специфічні функції екранування. Фактично, вони є лиш для: MySQL, PortgreSQL, SQLite, Sybase та MaxDB. Для інших популярних баз даних як Oracle, MS SQL Server та інших необхідно знайти альтернативу.

На перший погляд може підійти кодування даних у Base64, що ефективно екранує всі спеціальні символи. Але це створює кілька проблем: розмір даних, закодованих Base64 зростає рівно на 33% та унеможливлює вибірку даних за допомогою LIKE. Тож потрібен кращий метод.

Цей метод називається підготовленими виразами (або запитами). Такі запити фактично є шаблонами з визначеною структурою та місцями для реальних даних. Часто ці місця суворо типізовані для чисельних та текстових даних. Якщо тип даних не збігається із визначеним типом, то буде видана помилка, що додає ще один ступінь перевірки даних. Також підготовлені вирази додають швидкодію, адже вони компілюються лиш один раз і можуть використовуватись після цього із будь-якими даними. Наприклад, для PostgreSQL це може виглядати так:

<?php
    pg_query($db, 'PREPARE stmt_id (int) AS SELECT * FROM users WHERE id=$1');
    pg_query($db, "EXECUTE stmt_id ($userId)");
    pg_query($db, 'DEALLOCATE stmt_id');
?>

Якщо ви працюєте із MySQL, то підготовлені запити можна використовувати лише із розширенням mysqli чи PDO. Приклад:

<?php
    $stmt = $mysqli->stmt_init();
    if ($stmt>prepare('SELECT * FROM users WHERE id=?')) {
        $stmt->bind_param('i', $userId); //"i" означає integer
        $stmt->execute();
        $stmt->bind_result($user);
        $stmt->fetch();
    }
 
    $stmt->close();
?>

Використання трохи різне, але принцип однаковий. Спочатку створюється шаблон запиту, потім приєднуються реальні дані за їх типом та виконується сам запит. Підготовлені вирази - дуже класний інструмент, але дійсний не для всіх БД. У цих випадках слід використовувати екранування.

Коли екранування не допомагає

Існують випадки, коли екранування даних не убезпечить від зловмисних дій. Уявімо таку ситуацію:

<?php
    $userId = '0; DELETE FROM users';
    $userId = pg_escape_string($userId);
    pg_query($db, "SELECT * FROM users WHERE id=$id");
?>

Запит у даному випадку цілком дійсний, адже ми очікуємо чисельні дані і їх не обов’язково брати у лапки. Цим і наражаємо себе на небезпеку у вигляді SQL Injection. Перший вихід з цієї ситуації - абсолютно всі вхідні дані брати у лапки при використанні у запиті, незалежно від їх типу. Але як ми зараз побачимо, це також не дуже добре:

<?php
    $userId = "0'; DELETE FROM users";
    $userId = pg_escape_string($userId);
    pg_query($db, "SELECT * FROM users WHERE id='$id'")
             or die(pg_last_error($db));
?>

У цьому випадку звичайно запит не буде виконано, натомість буде видана помилка і це призведе до краху вашої програми. Але ми можемо цього легко і просто уникнути звичайним приведенням типу. Таким чином запит буде вдало виконано і нічого не зупиниться:

<?php
    $userId = '22; DELETE FROM users';
    $userId = (int)$userId; // 22
    pg_query($db, "SELECT * FROM users WHERE id=$id");
?>

Це буде абсолютно безпечно, адже до запиту прийдуть лише чисельні дані. До того ж це підвищить швидкодію, оскільки приведення типу - дуже швидка операція, яка убирає необхідність виклику функції екранування.

Оператор LIKE

Оператор LIKE у SQL запитах є дуже корисним. Він дозволяє робити вибірку в залежності від знайдених у полі підстрок. Це робиться за допомогою його складових “%” та “_“, які дозволяють відповідно знаходити строки із 0 чи більшою кількістю будь-яких символів та один будь-який символ. Проблема ж у тому, що ані функції екранування, ані magic quotes не впливають на ці символи. Тож із деякими комбінаціями можна змінити запит, ускладнити вибірку та у багатьох випадках не дозволити використання індексів, що значно вповільнить запит і надасть ґрунт до запуску DoS атаки на ваш сервер БД. Ось надзвичайно простий приклад:

<?php
    $string = mysql_real_escape_string('%substring'); // так само %substring
    mysql_query("SELECT * FROM posts WHERE title LIKE '{$string}%'");
?>

Суть запиту у тому, щоб вибрати ті записи, у яких назва починається з деякої строки. Такий запит мав би виконатись досить швидко за наявності індексації колонки “title”. Але, якщо у строку буде вставлено ще один символ “%” на початок, то це унеможливить використання індекса і значно сповільнить запит, при чому, чим більше записів у таблиці, тим повльніше буде здійснюватись пошук.

Символ “_” представляє схожу але дещо іншу проблему. Використання цього символу перед закінченням строки пошуку унеможливить використання індекса, а наявність його у кінці - дасть інший результат. Окрім того, символ “_” є досить часто вживаним, тож може стати проблемним зовсім випадково без злих намірів. Тож нам потрібно розширити множину екранованих символів. Для цього існує вбудована функція addcslashes, яка приймає строку із символами для екранування другим параметром:

<?php
    $str = addcslashes(mysql_real_escape_string('%something_'), '%_');
    //$str = '\%something\_'
    mysql_query("SELECT * FROM posts WHERE title LIKE '{$str}%'");
?>

Тож функція addcslashes є таким собі нестандартним addslashes і є досить ефективною - значно швидша за str_replace чи еквівалентний регулярний вираз.

Слідкуємо за помилками

Один із звичайних шляхів для зловмисника при пошуку уразливого до SQL Injection коду - використання інструментів розробників проти них самих. Наприклад, для полегшення відлагодження SQL-запитів, розробники часто виводять запит, що призвів до помилки і власне саму помилку бази даних:

<?php
    mysql_query($query) or die("Помилка запиту: $query<br />".mysql_error());
?>

Часто після процесу розробки такий код потрапляє на робочий варіант сайту і тоді, окрім того, що звичайні користувачі бачать ваш сайт в агонії, ще й зловмисники отримують купу інформації про вашу програму. Наприклад, можливо проаналізувати SQL-запит на предмет колонок використаних таблиць та змайструвати GET чи POST запити, які можуть призвести до ін’єкції SQL. Більше того, помилка може стати результатом спроби SQL-вставки і послужить зловмиснику інструкцією зі створення більш хитрих запитів.
Найпростіший шлях уникнути цього - написати власний обробник помилок SQL:

<?php
    function sql_failure_handler($query, $error) {
        $msg = htmlspecialchars("Невдалий запит: $query<br />Помилка SQL: $error");
        error_log($msg, 3, '/path/to/site/logs/sql_error.log');
 
        if (defined('debug')) {
            return $msg;
        }
 
        return 'Ця сторінка тимчасово недоступна. Будь ласка, повторіть спробу пізніше.';
}
 
mysql_query($query) or die(sql_failure_handler($query, mysql_error()));
?>

Ось і все. Обробник приймає строки із запитом і помилкою, виводить інформацію про збій у файл журналу, та, якщо увімкнено режим відлагодження - виводить повідомлення на екран. У робочому ж середовищі, користувач нічого, окрім стандартного повідомлення про недоступність ресурсу, не побачить.

Збігання даних про доступ до БД

Дуже важливим у створенні безпечного середовища є те, де ви зберігаєте дані про доступ до БД, тобто ваші логін та пароль. Більшість веб-програм використовують маленький PHP-файл, у якому логін та пароль присвоюються деяким змінним чи константам. На цей файл часто встановлюються права на читання для будь-кого, щоб веб-сервер міг отримати до нього доступ. Але це означає, що будь-хто на цій системі чи експлоіт може прочитати цей файл та вкрасти ваші дані про доступ до БД. Більше того, іноді цей файл кладуть у директорії, доступній для будь-кого по ту сторону сервера та дають йому яке-небудь розширення, не асоційоване із PHP. Наприклад, популярним вибором є “.inc“. Такі розширення типово не налаштовані на інтерпретацію як PHP-скрипти і веб-сервер просто віддає їх як звичайний текст, який будь-хто може побачити.

Вирішень цієї проблеми декілька з різною ступінню безпечності. По-перше, можна використати можливості веб-сервера, такі як файл налаштування .htaccess у Apache для того, щоб заборонити доступ до деяких файлів. Наприклад ось директива, яка забороняє доступ до будь-яких файлів із розширенням .inc:

<Files ~ "\.inc$">
    Order allow,deny
    Deny from all
</Files>

Або ж, наприклад, можна змусити PHP інтерпретувати .inc файли, як скрипти або змінити розширення на .php або .inc.php. Щоправда, перейменування файлів - не завжди найбезпечніший варіант. Найкращий і найпростіший спосіб - не зберігати такі файли у директоріях, доступних для веб-сервера. Але це все-одно не убезпечує від використання експоітів локальними користувачами (актуально, якщо ви на віртуальному хостингу).

Одне, на перший погляд, гарне вирішення проблеми - шифрування важливих даних. Але це робить крадіжку лиш дещо складнішою і не вирішує проблеми, адже ключ до шифру все-одно має бути доступним для PHP-скрипта, який запускається із користувачем веб-сервера, що означає те, що ключ все-одно є доступним для читання будь-ким. Повертаємось до того, з чого і почали.

Правильне вирішення має давати гарантію, що інші користувачі системи не мають жодного шансу побачити дані доступу до БД. На щастя, Apache надає такий інструмент. Файл налаштування Apache, httpd.conf, може включати в себе сторонні файли налаштування у момент запуску процесу веб-сервера, тобто доки він ще працює як root. Оскільки root має доступ до будь-яких файлів, ви можете покласти важливу інформацію у файлі в своїй домашній директорії (/home/user/) і надати права на читання лиш для себе (0600). Таким чином тільки ви та root зможуть читати цей файл. Робиться це таким чином:

<VirtualHost webdeveloping.com.ua>
    Include /home/webdeveloping/sql.conf
</VirtualHost>

Сам же sql.conf встановлює наступні змінні середовища:

SetEnv DB_LOGIN "login"
SetEnv DB_PASS "password"
SetEnv DB_NAME "my_database"
SetEnv DB_HOST "127.0.0.1"

Після запуску Apache, ці змінні будуть доступні PHP через суперглобальний масив $_SERVER або функцію getenv:

<?php
    echo $_SERVER['DB_LOGIN']; //login
    echo getenv('DB_LOGIN'); //login
?>

А ще краще заховати ці дані навіть від скрипта, якому вони потрібні Можна використати директиви php.ini для визначення типових даних для зв’язку із БД. Це також можна встановити у захищеному файлі налаштувань Apache:

php_admin_value mysql.default.host "127.0.0.1"
php_admin_value mysql.default.user "login"
php_admin_value mysql.default.password "password"

Тепер, функція mysql_connect може працювати без параметрів, адже вони будуть взяті автоматично з налаштувань. Єдине, що потрібно буде встановити - це назва бази. Але не слід використовувати цей метод, якщо ваша версія PHP < 4.3.5. У цих старих версіях був глюк, який дозволяв протікати налаштуванням PHP від одного віртуального хоста до іншого, і таким чином, користувачі інших хостів могли побачити чужі налаштування.

Вказівки до швидкодії

На останок хочу надати кілька вказівок, які можуть поліпшити швидкодію ваших веб-проектів. Це має безпосереднє відношення і до безпеки, адже повільні запити можуть призвести до інших типів атак, як це було показано із оператором LIKE. Ось кілька простих правил, які слід пам’ятати:

1. Отримуйте лише ті дані, які вам необхідні. Часто розробники використовують символ “*” у запитах для того, щоб дістати всі колонки результату, що може бути величезною кількістю даних, особливо, якщо запит складається з багатьох приєднаних таблиць. Це означає більше використання пам’яті для сортування у БД, більше часу для передачі до PHP, більше часу і пам’яті для обробки даних.
   
2. Спробуйте використовувати небуферизовані запити, які отримують дані невеличкими порціями. Але їх треба використовувати обережно, адже одночасно ви можете працювати лише із одним запитом. У випадку MySQL, ви не зможете навіть виконати INSERT чи UPDATE, доки всі дані поточного запиту не будуть отримані.
3. Створення з’єднання із БД - повільна операція, особливо у випадку “тяжких” систем, як Oracle, PostgreSQL чи MSSQL. Пришвидшити це можна використовуючи постійне з’єднання, яке дозволяє ресурсу залишатись дійсним навіть після припинення роботи скрипта, що дозволяє використовувати одне і те саме з’єднання для багатьох процесів веб-сервера. Для цього існує функція mysql_pconnect (у випадку MySQL, інші БД мають схожі функції). Але це має свої мінуси. Пул з’єднань у PHP працює на основі процесів, а не веб-серверів, тому кожен процес веб-сервера має свій пул з’єднань. Це означає, що 50 запущених процесів Apache призведуть до 50 відкритих з’єднань із БД. Якщо БД не налаштована на те, щоб приймати одночасно стільки з’єднань, то зайві будуть відкинуті, що призведе до збою вашої програми.
4. Часто веб-сервер та сервер БД працюють на одній і тій самій машині, що дозволяє оптимізувати передачу даних. Навіщо використовувати повільний і громіздкий TCP/IP, коли ви можете використати Unix Domain Sockets (UDG) - найвшидший засіб передачі даних після Inter Process Communication (IPC). Цим ви можете значно пришвидшити зв’язок між двома серверами. Для цього потрібно змінити хост у налаштуваннях з’єднання: <?php mysql_connect(’:/tmp/mysql.sock’, ‘login’, ‘password’); ?>
5. Використовуйте кешування запитів. Це збереже результат запиту на деякий час, продовж якого можна не повторювати запит, а натомість - брати готові дані із кешу. Після того, як кеш стане недійсним - повторити запит і зберегти у кеш.

Сподіваюсь, стаття була вам цікава і допоможе зробити вашу роботу із базами даних швидшою і безпечнішою. ]]> http://webdeveloping.com.ua/php/sql-injection-securing-your-database-2/feed http://webdeveloping.com.ua/firefox/firebug-and-firefox-3-beta-5 http://webdeveloping.com.ua/firefox/firebug-and-firefox-3-beta-5#comments Mon, 05 May 2008 10:14:45 +0000 MoD http://webdeveloping.com.ua/?p=28 Нова версія популярного браузера Firefox 3 є надзвичайно швидкою та приносить багато змін і виправлень (як наприклад, часті витоки пам’яті). Нажаль, поки що із новою версією працюють далеко не всі розширення - це і не дивно, адже Firefox 3 досі має статус beta. У цій замітці зайде мова про встановлення популярного серед веб-розробників додатку Firebug. Цей додаток дозволяє на ходу змінювати параметри CSS, вносити зміни у DOM документа, відлагоджувати JavaScript та спостерігати за часом завантаження веб-сторінки та її складових. Незамінна річ для тих, хто займається розробкою із використанням AJAX. Сергій Винниченко написав невеликий огляд Firebug у своєму блозі.

Отже, до 5ої бети браузера можна було використовувати версію Firebug 1.1beta. Але, не всім відомо, що існує також версія 1.2alpha. Так, судячи із статусу, вона ще має достатньо проблем, але є цілком придатною до використання із новим браузером. Також вона вводить ряд нових можливостей, серед них:

1. Програмне вимкнення журналу Firebug через JavaScript
2. Відображення HTTP статуса у вкладці Net (мережа)
3. Нова можливість відлагоджування JavaScript: перервати виконання через один брейпоінт.
4. Вдосконалений монітор заванаження мережі з урахуванням часу оброки запиту на стороні сервера
5. Новий API консолі

Firebug 1.2 можна скачати звідси - просто оберіть останній за номером реліз. Або можна взяти свіжий код з SVN. Приємного використання!

Що нового?

Kubuntu:

• KDE 4.0.3 (на вибір)
• KDE 3.5.9
• Ефекти стільниці для KDE 3.5.9
  

  

• Amarok 1.4.9.1
• Автоматичне встановлення кодеків (в тому числи DVD) при відкритті відео за допомогою Kaffeine
• Налашування шифрування файлової системи при встановленні
• Монтування NTFS-розділів користувачем
• Безпечне налаштування X-сервера та дисплея збереже від несправного налаштування
• Відображення споживання електроенергії при використанні акамулятора

Загальне для Ubuntu:

• Ядро Linux 2.6.24
• Xorg 7.3
• Firefox 3 beta 5
• OpenOffice 2.4
  
• ufw - простий у налаштуванні фаєрвол
• Inkscape 0.46
• Інтеграція у ActiveDirectory через Likewise Open
• Підтримка iSCSI
• Покращений захист пам’яті
• Підтримка SELinux
• Віртуалізація через KVM
• Інтеграція драйверів бездротових пристроїв серії Rt2×00
  
• Wubi - інсталяція Linux у Windows з використанням завантажувача останньої

Встановлення

Оскільки у мене вже стояв Kubuntu 7.10 я спробував оновитись через мережу. Для цього необхідно виконати наступну команду (у консолі чи через Alt-F2):

kdesu "adept_manager --dist-upgrade-devel"

Звичайно, у фінальній версії не потрібно буде цього робити, адже Adept сам запропонує вам оновити дистрибутив, як тільки вийде реліз. Але перед тим як продовжувати зауважте, якщо ви використовували PPA-репозиторій для KDE4, то вам треба буде його вимкнути та видалити все, що відноситься до KDE4.

Далі, переконайтесь, що у вас встановлені всі оновлення до поточної версії, якщо ні, то самий час це зробити. Також, переконайтесь, що у вас встановлений один із наступних мета-пакунків: kubuntu-desktop, ubuntu-desktop, edubuntu-desktop, edubuntu-desktop-kde, xubuntu-desktop. Інакше, оновлювач не зможе визначити начинку дистрибутиву.

Отже, у меню Adept має з’явитись додаткова кнопка для оновлення дистрибутиву. Після її натиснення все має пройти гладко (принаймні у мене все було OK). Можете піти погуляти кілька годинок (в залежності від швидкості вашого з’єднання із Мережею), адже будуть завантажені пакунки загальним розміром приблизно у 800-900Мб. Якщо трафік вам дорогий, то краще подумайте про альтернативу - диск Kubuntu 8.04 Alternative для оновлення з нього.

Якщо ви не маєте встановленого Kubuntu Linux, то використайте диск для встановлення - процедура буде простою та інтуїтивною. В разі, якщо хочете використовувати новий (але поки що не дуже стабільний) KDE4 - вам потрібен диск Kubuntu 8.04 KDE4 Remix.

Отже, якщо все пройшло добре і ви оновили свою ОС, то після перезавантаження у Adept побачите новий мета-пакунок kubuntu-kde4-desktop. Саме його необхідно встановити, якщо вам цікавий новий KDE. Це одним махом встановить всі необхідні пакунки для базової функціональності нового графічного середовища. Всі інші ви можете знайти та встановити самотужки, набравши у полі пошуку “kde4″.

Огляд

В плані графічного інтерфейсу нічого нового, окрім дещо змінених тем я не помітив. Тут слід зазначити, що всі налаштування повністю зберіглись і запрацювало все без проблем. З позитивного, у KDE4 перестали пропадати деякі іконки з системного лотка (system tray) Але, що дійсно сподобалось, то це нова бета Firefox 3. Вона тут встановлюється автоматично, тобто є типово обраним браузером. Не дивлячись на статус “бета“, працює досить стабільно. А головне, значно, значно, швидше та використовуючи менше пам’яті ніж 2га версія - я думаю, тепер є ще один аргумент на користь цього браузера. З мінусів - поки що підтримуються не всі розширення.
Серед моїх працюють:

• ColorZilla
• Download Statusbar
• DownThemAll!
• Live HTTP Headers
• Operator
• Web Developer

А не працюють дуже корисні:

• Fasterfox
• Firebug
• Google Toolbar
• HTML Validator
• Locationbar

Сподіваємось, що скоро вийдуть оновлення для цих розширень. А поки, є можливість використовувати поруч 2гу версію Firefox. У Adept ці пакунки називаються відповідно firefox-3.0 та firefox-2.
Окрім Вогнелиса, корисна для поціновувачів продукції Apple фіча у новому програвачі Amarok - тепер є підтримка iPhone та iPod Touch плюс оновлений сервіс отримання картинок альбомів з Amazon. А користувачі KDE3 тепер без зайвих танців із бубном можуть вмикати ефекти стільниці через спеціальну секцію у системних налаштуваннях. OpenOffice тепер може порадувати підтримкою баз даних у форматі MS Access.

Звичайно, дуже багато нових речей всередині ОС. Більшість оновлень стосуються стабільності та безпеки системи - це і не дивно, адже цей реліз Ubuntu (не Kubuntu) є LTS, тобто має довгий термін офіційної підтримки (3 роки для desktop-версії та 5 років для серверної) і цим розрахований на корпоративних користувачів. Хоча Kubuntu це і не стосується (через нестабільність KDE4), але ці оновлення звичайно ж присутні.

У висновок скажу, що чергове оновлення приносить велику кількість внутрішніх змін (не надто помітних користувачу), нові версії софта і підтримку KDE4 з основних репозиторіїв. Вже зараз встановлення проходить гладко і без проблем. Тому, не бачу змісту не оновитись, коли вийде реліз

UPD: Якщо ви маєте проблеми із звуком у KDE4 - спробуйте перевстановити всі пакунки, які відносяться до звуку (alsa, phonon, kmix і т.п.), після чого у “Системних параметрах” -> “Звук” видаліть ваш звуковий пристрій. Далі перейдіть до вкладки “Серверна програма” і позначте пункт “Показати пристрої OSS”, натисність “Застосувати”. Вийдіть з графічного середовища і увійдіть у нього знов. Тепер звук має з’явитись. Але будуть також з’являтись повідомлення про перехід до іншого пристрою при кожній спробі використати звук. Для того, щоб позбавитись цього пересуньте ваші пристрої догори у системних параметрах. Поекспериментуйте, який саме пристрій підходить.

Сподіваємось, що до релізу це виправлять.

Чисельні дані

Найшвидший і найпростіший метод валідації чисельних даних - приведення типу до необхідного чисельного типу (int, float):

<?php
    $_GET['id'] = (int)$_GET['id'];
    $_POST['price'] = (float)$_POST['price'];
?>

Приведення типу переводить чисельні дані у строках - це дає впевненість, що у скрипт потраплять лише чисельні дані, незалежно від того, що було введено. Якщо введена строка містить лише нечисельні дані, то приведення поверне число 0. У більшості випадків це буде небажаним, тож проста умова після приведення типу дасть змогу ефективно перевірити дані, і у разі необхідності видати помилку:

<?php
   if (!$value) {
       //Помилка
   }
?>

Пам’ятайте, що при можливості введення занадто великого числа, краще приводити до типу із плаваючою точкою (float). Наприклад, на 32-бітних системах розмір цілочисленого типу (int) сягає 4 байт, окрім того він є знаковим, тобто максимальне число для змінної такого типу - 2 147 483 647 ((2^4^8)/2). Якщо більше число буде введено, то станеться переповнення і втрата даних як наслідок. Приведення до типу із плаваючою точкою збереже дані у форматі “знак * 2^експонента * мантиса”, таким чином ті ж 4 байт дозволяють зберігати значно більші числа.

Щоправда, таким чином можна пререводити лише десяткові числа, а наприклад, шістнадцяткові та вісімкові вже - ні. Для цього існує більш гнучка функція PHP is_numeric. Вона приймає всі формати даних і повертає булеве true, в разі, якщо їй передані чисельні дані та false у іншому випадку. Ви спитаєте, чому б посто завжди не використовувати цю функцію? За все треба платити - вона працює дещо повільніше ніж просте приведення типів і не зовсім вірно перевіряє вісімкові числа, адже вважає допустимими всі цифри у проміжку [0-9], що не дійсно для вісімкових чисел. Приклад:

<?php
    is_numeric('9234'); //true
    is_numeric('0xFF7F'); //true
    is_numeric('0xYR3F'); //false
    is_numeric('0999'); //true
?>

Ще однією проблемою у валідації чисельних даних є різниця у локалях. Справа у тому, що числа із плаваючою точкою вважаються дійсними тільки, якщо цілу та дробову частину розділяє знак “.” (точка). Це складає проблему для багатьох європейських локалей - наприклад, у французькій, німецькій та й українській локалях прийнято використовувати кому як розподільний знак. І ніяка насильна зміна локалі у цьому не допоможе. У PHP можливе лише тільки використання точки.

Тепер трохи про парадигму використання цієї перевірки. Приклад перший:

<?php
    //$_GET['id'] = '1; /*Бугагагага!*/ TRUNCATE users;'
 
    if ((int)$_GET['id']) {
        mysql_query("DELETE FROM users WHERE id=".$_GET['id']);
    }
?>

Проблему бачите? Так, умова із приведенням типу буде успішно пройдена і поверне “1″, а потім запитом до БД буде видалений користувач із id=1, а разом із ним і вся таблиця “users”. Це окремий тип уразливості - ін’єкція SQL коду, який буде розглянутий більш детально у одній із наступних заміток. А тепер розглянемо правильне використання приведення типу:

<?php
    if (($_GET['id'] = (int)$_GET['id'])) {
        mysql_query("DELETE FROM users WHERE id=".$_GET['id']);
    }
?>

Тепер все добре, у запит буде вставлено лише чисельне значення.

Строкові дані

Із строковими даними не все так просто як із чисельними. Їх валідація дуже залежить від того, які власне дані передаються: URL, e-mail, ім’я, телефон і т.п.

Найпростійший і найшвидший шлях перевірити строкові дані у PHP - використати розширення ctype(воно типово увімкнене). Наприклад для перевірки імені користувача можна задіяти ctype_alpha. Ця функція поверне true, коли всі символи у переданій їй строці є літерами, незалежно від регістру. Якщо допускаються як літери так і цифри, то слід використовувати ctype_alnum, щоправда дійсними будуть лише цілі числа. Приклади:

<?php
    ctype_alpha('teststring'); //true
    ctype_alpha('teststring12'); //false
    ctype_alnum('teststring12'); //true
?>

Функції розширення ctype є залежними від встановленої локалі. Якщо строка містить літери, які не належать даній локалі - вона вважається недійсною. Тож, що працювати із необхідною вам мовою потрібно перескнути локаль за домогою функції setlocale. До того ж, ці функції працюють лише із однобайтовими символами, тож можете забути про перевірку строк із багатобайтовими символами (наприклад, не-латинські літери закодовані UTF-8, японська і т.п.). Також ця функція вважає не дійсними символ “-” та всі види пробілів.

Щоб перекрити усі інші випадки треба використовувати регулярні вирази. У цій статті ми розглянемо регулярні вирази сумісні із Perl (PCRE), оскількі вони швидші, розуміють багатобайтові символи (без спеціальних розширень як mbstring), безпечніші та гнучкіші за розширення ereg. Перевірка строк за допомогою PCRE здійснюється через функцію preg_match. При сходженні заданих шаблону та строки, функція повертає int(1) та int(0) у зворотньому випадку. Якщо на вході очікується строка із латинськими літерами, знаками “-”, “‘” та пробілами можна використати наступний вираз:

<?php
    preg_match("/[^-'a-zA-Z \t\n]/", "it's a phrase that vali-dates"); //int(0)
?>

Квантор “^” на початку виразу означає “не входить“. У фразі немає символів, які б не входили у вираз, отже повернено 0.

Також PCRE можна використовувати разом із setlocale. У деяких випадках вводити вручну символи для перевірки досить проблематично (наприклад, ієрогліфи). Для цього існує ідентифікатор “/w”, який означає алфавіт, складений із літер поточної локалі. Також PCRE повністю підтримує UTF-8, тож можна використовувати Unicode коди у виразах із оператором “u”.

Розмір даних

Для безпечної і правильної роботи скрипта також часто є сенс перевіряти розмір даних, що надходять ззовні. Наприклад, у базі даних є поле для імені користувача і воно має тип VARCHAR(20). Що станеться, якщо користувач введе ім’я довжиною 25 символів? А це залежить від самої бази даних: якщо це PostgreSQL, то буде видана помилка, якщо ж MySQL, то дані запишуться у БД, але будуть автоматично обрізані до необхідної довжини. Не знаю навіть, що гірше. Отже, нам слід відстежувати такі випадки і попереджати користувача про помилки.

Для цього існує два підходи: обмежування на клієнтській стороні (у браузері) та серверній. Найкраще застосовувати обидва. Спочатку розглянемо клієнтську сторону.

Текстові поля у HTML-формах можна обмежувати у розмірі за допомогою атрибута “maxlength“, таким чином браузер самотужки попереджає ввід більшої за цей атрибут кількості символів:

    <input type="text" name="uname" maxlength="20" />

Нажаль, maxlength можна задіяти лише для полів типу “text” та “password“. Для “textarea” наприклад, вже потрібно відстежувати це за допомогою JavaScript.

Але це ні в якому разі не є панацеєю. Проблема у тому, що зловмисник може просто скопіювати вашу форму і змінити атрибути чи надіслати відповідний POST-запит до вашого скрипта, який оброблює ці дані. Найпростіше, що можна зробити для того, щоб запобігти цьому - створити масив з необхідними вам обмеженнями і перевіряти їх при вводі у скрипті.

<?php
    $validate = array(
        'uname' => 20,
        'address' => 200,
        /* ... */
    );
 
    foreach ($validate as $input => $rule)
        if (!empty($_POST[$input]) && strlen($_POST[$input]) > $rule)
            exit('Поле '.$input.' більше за дозволену довжину '.$rule);
?>

Таким чином, для кожного визначеного поля перевіряється його довжина за допомогою функції strlen. Якщо довжина перевищує задане для цього поля значення - користувач отримує помилку. Сама перевірка дуже швидка, адже strlen не буде щоразу підраховувати довжину строки, натомість ця функція бере вже визначене значення із спеціальної внутрішньої структури PHP. Незважаючи на це, ми все-одно маємо виклик функції, який можна дещо оптимізувати. Окрім того слід пам’ятати, що для використання із багатобайтовими кодуваннями символів треба використовувати функцію mb_strlen із вказанням кодування, якщо увімкнене розширення mbstring. Якщо ж цього розширення нема - то такий спосіб не підійде, адже наприклад, 2-байтові кодування будуть підраховуватись відповідно за по 2 байти і довжина строки буде у 2 рази більшою.

Починаючи із PHP 4.3.10, можна використати одну маловідому можливість вбудованої конструкції isset. Вона може перевіряти наявність даних за зсувом (offset). Тож ми можемо це застосувати, перевіряючи, чи є щось за зсувом {$rule + 1}:

<?php
    $validate = array(
        'uname' => 20,
        'address' => 200,
        /* ... */
    );
 
    foreach ($validate as $input => $rule)
        if (!empty($_POST[$input]) && isset($_POST[$input]{$rule + 1}))
            exit('Поле '.$input.' більше за дозволену довжину '.$rule);
?>

Оскільки isset не є функцією, а натомість конструкцією мови, PHP інтерпретує це у одну інструкцію, а вона буде виконано просто миттєво. Мінус - ні в якому разі не підходить для багатобайтових кодувань строк.

Білий список

Велика кількість розробників занадто сильно покладається на одне вкрай невірне припущення - виринаючі списки, чекбокси, кнопки вибору та приховані поля не потребують перевірки, думаючи, що вони все-одно мають лише попередньо визначені варанти даних. Насправді ж, зловмисник може легко передати будь-які інші дані, скопіювавши форму або створивши свій запит до вашого скрипта. У першій частині було сказано, що неможна довіряти будь-яким зовнішнім даним. Все потрібно перевіряти.

На щастя, перевірити такі поля дуже легко. Достатньо просто створити масив із значеннями цей полів і перевіряти введені дані на наявність у цьому масиві:

<?php
    $jobTypes = array('fulltime', 'parttime', 'contract');
 
    if (empty($_POST['jobType']) || !in_array($_POST['jobType'], $jobTypes))
        exit('Обламайся, у нас все гаразд із безпекою :-P ');
?>

Завантаження файлів

Так історично склалось, що одна з найбільших проблем у PHP - завантаження файлів. І найкращим вирішенням проблеми є відключити цю можливість у налаштуваннях PHP, якщо це реально у вашому середовищі. Адже можна створити запит, який буде завантажувати велику кількість файлів, чим легко завалити сервер. Якщо ви все ж таки дозволяєте завантаження файлів, то необхідно прийняти міри для того, щоб зменшити ризики.

Налаштування:

• upload_max_size - це потрібно зробити якнайменшим, щоб попередити завантаження надто великих файлів, завантажуючи сервер. Типово, це налаштування має значення 2Мб. Часто можна зробити його меншим.
• post_max_size - обмежує розмір POST-запиту. Якщо ваша програма може завантажувати лише один файл за раз, то слід поставити його трохи більшим за upload_max_size. Якщо ж багато, то трохи більше ніж сумарний розмір всіх файлів. Типово, це має немаленьке значенняу 8Мб. В більшості випадків треба зменшити.
• upload_tmp_dir - директорія для розміщення тимчасових файлів. Типово, PHP використовує системну тимчасову директорію (наприклад, /tmp/ на *nix). Ця директорія може бути прочитана будь-ким та у деяких випадках ще й писати туди може хто-завгодно. Вона доступна для будь-якого користувача та процесу. Зазвичай правильно змінити це налаштування для кожної вашої програми.

Тепер власне про завантаження файлів.

Коли приходить запит, який включає у себе файли, то суперглобальний масив $_FILES наповнюється масивом для кожного файлу:

    //print_r($_FILES);
    $_FILES['file'] => Array
    {
        [name] => picture.jpg //назва файла
        [type] => image/jpeg //MIME-тип
        [tmp_name] => /tmp/phpsdf34ss //тимчасова назва і місце збереження
        [error] => 0 //код помилки
        [size] => 213951 //розмі
    }

Параметр “name” за специфікацією W3C має містити лише оригінальну назву файла без директорії. Але, нажаль, не всі браузери дотримуються цієї специфікації (звичайно ж ви здогадались, які саме “не всі” браузери маються на увазі Так, це Internet Explorer, який порушаючи специфікацію та приватність користувача, надсилає повний шлях до файлу). Такі браузери стають інструментом для зловмисних дій і, якщо не валідувати ввід файлів, то кінця проблем не буде видно. Приклад такого використання:

<?php
    //$_FILES['file']['name'] = '../../config.php';
 
    move_uploaded_file($_FILES['file']['tmp_name'], '/home/www/app/uploads/'.$_FILES['file']['name']);
?>

Таким чином, якщо існує файл /home/www/config.php і на нього у веб-сервера є права запису - він буде перезаписаний завантаженим. В принципі, PHP намагається автоматично захистити від таких дірок, обрізаючи все до назви файла, але це не завжди вірно працює. Так, наприклад, у версії для Windows до 4.3.10 роздільники шляху “\” могли потрапити у шлях (про це трохи далі). Щоб убезпечити програму від дірок у старих версіях і передбачити нові слід обрізати все непотрібне вручну:

<?php
    //$_FILES['file']['name'] = '../../config.php';
 
    move_uploaded_file($_FILES['file']['tmp_name'],
             '/home/www/app/uploads/'.basename($_FILES['file']['name']));
?>

Функція basename дозволяє пройти лиш імені файла.

Тепер щодо вмісту файлу. Пам’ятайте, що тип файлу, який передається у $_FILES['file']['type'] є таким, яким його вважає браузер. Це абсолютно ненадійна інформація, якій ніколи і нізащо неможна довіряти. Вся проблема у тому, що браузер визначає MIME-тип файлу просто тупо, судячи з його розширення у файловій системі, а не з його заголовків (як мав би). Тож, якщо файл bloody_virus.exe буде перейменований у beautiful_flowers.jpg, то браузер не задумуючись відправить MIME-тип image/jpeg.

Для найбільш часто завантажуваних файлів, картинок, існує функція getimagesize. Вона перевіряє заголовки файла та повертає інформацію про зображення, або false, якщо це не картинка. Для більш складних файлів існує розширення PECL fileinfo. Воно може оброблювати майже будь-які формати файлів через функцію finfo_file. Спочатку треба створити контекст за допомогою функції finfo_open (якщо передати їй FILEINFO_MIME, то у видачі буде використовуватись MIME-тип замість текстової інформації), далі можна використовувати його скільки завгодно раз для будь-яких файлів.

От ми і підготувались до власне доступу до завантаженого файлу. Тут треба запам’ятати дві функції: move_uploaded_file та is_uploaded_file. Перша переміщає завантажений файл із тимчасової директорії у постійну, а друга перевіряє, чи дійсно вказаний файл був завантажений. Обидві функції безпечні, адже перевіряють шлях до файлу через внутрішній хеш завантажених файлів. Коли файл пересунутий у постійне місце за допомогою move_uploaded_file, то його тимчасова назва видаляється із цього хешу, унеможливлюючи таким чином будь-які подальші операції із тимчасовим файлом.

І, нарешті, останнє, що можна сказати про файли - перевірка розміру. Цю інформацію можна вважати безпечною. Інформація про розмір файлу передана браузерем завжди збігається із розміром тимчасового файлу, в разі безперешкодного завантаження. Тож, щоб не засмічувати пошкодженими файлами директорію для постійних файлів слід зробити ще одну невеличку перевірку:

<?php
    if (!move_uploaded_file($_FILES['file']['tmp_name'], $dest))
        exit('Ой...');
 
    if (filesize($dest) != $_FILES['file']['size']) {
        unlink($dest);
        exit('Страшний глюк! Рятуйтесь, хто може!!');
    }
?>

Це врятує від збереження файлів, що були передані не повністю, або пошкодженні якимось ворожим процесом, поки файл знаходився у незахищеній тимчасовій директорії.

Чорна магія “Magic Quotes”

Суть механізму PHP magic_quotes_gpc у тому, що ввід користувача може включати у себе різні види спеціальних символів, як лапки (’ та “), NUL (\0) та зворотній слеш (\). Якщо залишити їх не відфільтрувавши, можна наразитись на небезпеку, передаючи їх у різні функції. Тож розробники PHP вирішили автоматично їх екранувати, фактично здійснюючи функцію addslashes до кожного джерела вводу даних, і, навіть, до назви файлів. З першого погляду, що тут поганого? Розробники турботливо захистили від небезпеки лінивих програмістів (а ми всі такі ), давши їм чарівну таблетку. Але не попередили, що вона має деякі побічні ефекти.

Основна проблема “магічних лапок” є бездумна залежність від них. А факт у тому, що цей механізм може бути вимкнутим через php.ini, httpd.conf та й .htaccess. Тому, якщо ви вважаєте, що magic quotes завжди увімкнено і не екрануєте ввід вручну, то ви самі собі вороги, оскільки залишаєте свою програму на беззастережне ураження великою кількістю експлоітів, як ін’єкція SQL, ін’єкція команд операційної системи та багато іншого.

По-друге, не завжди цей механізм продукує вірний вивід. Наприклад при використанні із спеціальними функціями для екранування можна отримати небажаний результат у вигляді подвійного екранування (а отже відміненого екранування). І нарешті, все це не надто ефективно. Функція addslashes пожирає вдвічі більше пам’яті ніж необхідно на збереження переданої строки і для нормалізації має бути реверсовано, поглинаючи вдвічі більше процесорного часу.

Очевидно, вірним рішенням є вимкнення magic_quotes_gpc та ручне екранування у необхідній мірі. Але для коректної роботи вашої програми у будь-якому середовищі потрібно нормалізувати дані. Ось шматок коду, який це виконує:

<?php
    if (get_magic_quotes_gpc()) {
    function stripQuotes(&$val) {
        if (is_array($val))
            array_walk($val, 'stripQuotes');
        else
            $val = stripslashes($val);
        }
 
        foreach (array('GET', 'POST', 'COOKIE') as $superGlobal) {
            if (!empty(${'_'.$superGlobal}))
                array_walk(${'_'.$superGlobal}, 'stripQuotes');
            }
    }
?>

Цей код реверсує діяльність магічних лапок, якщо вони увімкнені, враховуючи будь-який рівень вкладеності у суперглобальних масивах через рекурсію. Все начебто непогано, але є одна проблема, суть якої є у одній обмеженості PHP. У рекурсивних функціях PHP використовує системний стек для відстежування викликів. Але цей стек обмежений у глибині і цілком можливо переповнити стек та цим завалити PHP. У даному прикладі це тривіально зробити:

<?php
    $str = str_repeat('[]', 1000000);
    file_get_contents('http://vulnerable.site.com/insecure.php?badvar='.$str);
?>

Ми передаємо GET-запитом масив із мільйонною вкладеністю. Таким чином наш скрипт просто завалиться на рекурсії разом із PHP. Тож маємо придумати більш безпечний засіб. А це просто - ми уникнемо рекурсії, якщо “розрівняємо” багатовимірний масив у одновимірний:

<?php
    if (get_magic_quotes_gpc()) {
        $inputs = array(&$_GET, &$_POST, &$_COOKIE, &$_ENV, &$_SERVER); //масив із суперглобальними, приєднними за посиланнями, щоб виловити усі зміни до них
 
        while (list($input, $data) = each($inputs)) {
            foreach ($data as $key => $val) {
                if (!is_array($val)) { //якщо під-елемент не є масивом - реверсувати екранування
                    $inputs[$input][$key] = stripslashes($val);
                    continue;
                }
                $inputs[] =& $inputs[$input][$key]; //розрівнювання - якщо під-елемент сам є масивом, приєднуємо його за посиланням в кінець масиву із суперглобальними
            }
        }
        unset($inputs); //вивільнюємо використаний масив
    }
?>

Ми позбавились рекурсії та зайвої функції, цим зробили наш код безпечнішим і швидшим.

І ще трохи інформації про імена файлів та magic_quotes_gpc. Це зовсім цікавий випадок. Нехай у нас є файл із іменем bad’file.txt. Він включає в себе апостроф - це цілком нормально, хоча і не дуже звично. Отже екранована версія цього імені буде bad\’file.txt. А тепер уявімо, що наш скрипт працює у ОС Windows (фєє) із PHP < 4.3.10 & < 5.0.3 (для 5ої гілки). А наскільки відомо, ця ОС інтерпретує “\” як розподільник директорій. У таких умовах файл буде мати директорію “bad” і назву “‘file.txt“. Щодо більш свіжих версій PHP, то частина до останнього символу лапок буде обрізана, що призведе до втрати даних. На *nix системах це не актуально, але все-одно може призвести до втрати даних. Тож давайте розберемось із цим:

<?php
    if (get_magic_quotes_gpc())
        $_FILES['file']['name'] = stripslashes($_FILES['file']['name']);
?>

От і все. Якщо ж ви самостійно робите екранування, то краще просто оминайте ім’я файлів.

На останок хочу дати посилання на шпаргалку з убезпечення та фільтрації даних.

На цьому завершую другу частину статті про обробку зовнішніх даних. Сподіваюсь, вона була вам цікава та корисна. Будь ласка, коментуйте, якщо побачите неточності, маєте щось доповнити чи просто виразити свою думку.
Наступною заміткою із серії про безпеку буде стаття про ін’єкції SQL. Підписуйтесь на RSS-стрічку, якщо ви вважаєте мої замітки корисними. Їх буде більше!

1. Як визначити методи вводу даних?
2. Яким чином кожен метод може бути використаним зловмисником?
3. Яким чином кожен тип вводу можна перевірити з метою запобігання проблем із безпекою?

У цій частині розглянемо перші два питання.

Проблема вводу

З покон віків програмісти на PHP мали доступ до вхідних даних за допомогою вбудованого механізму “register globals” (реєстрація глобальних змінних). Цей логічний засіб дозволяє отримати легкий доступ через глобальні змінні до однойменних полів форм чи параметрів, переданих через адресну строку. Наприклад: URL script.php?foo=bar утворює у глобальному просторі імен змінну $foo ініціалізовану значенням ‘bar’.
Проблема ж тут полягає у можливому конфлікті імен. Дані до скрипта можуть надходити із декількох джерел: GET-запити, POST-запити, cookies, змінні середовища сервера, змінні системного середовища. Якщо надходить декілька змінних із однаковим іменем з різних джерел - це призведе до втрати даних, адже PHP просто об’єднає дані із всіх цих джерел у один простір - глобальний. Щоправда, є можливість контролювати порядок пріоритетності цих джерел. Для цього існує 2 директиви у php.ini:

1. старий gpc_order - визначає порядок для GET, POST та cookie.
2. новий variables_order - визначає порядок для всіх джерел: системне середовище, GET, POST, cookie та середовище сервера.

Типово, порядок є визначений таким чином - EGPCS (system Environment, GET, POST, cookie, Server environment), тобто, якщо прийде дві змінні з однаковим іменем з GET та cookie - перевага буде надана даним із cookie. При чому, немає можливості знати про втрату даних із скрипта. Можливий вихід - призначати для змінних із різних джерел різні префікси, наприклад, за допомогою функції import_request_variables. Але це можливо лише тоді, коли ви маєте повний контроль над процесом написання коду.
Для розуміння проблеми ознайомимось із наступним прикладом:

<?php
    if (isAdmin()) {
        $admin = true;
    }
 
    if ($admin) {
        //контент для авторизованого користувача
    }
?>

Коли увімкнена директива register_globals, і скрипту буде переданий параметр “admin” наприклад через GET - PHP створить у глобальному просторі імен змінну $admin, ініціалізовану переданим значенням, оскільки у другій умові немає суворого порівняння (оператор ===), зловмисник зможе легко отримати доступ до закритої частинисайту. У випадку, якщо немає можливості вимкнути register_globals, треба щонайменше ініціалізувати всі необхідні змінні перед їхнім використанням.
Нажаль, у PHP немає ніякого “суворого” (strict) режиму як у Perl чи зауважень компілятора як у С. Такі засоби могли б показати розробнику всі проблемні місця у коді. Єдиний шлях побачити місця використання неініцілізованих змінних - перемкнути рівень виведених помилок на E_ALL. Наприклад так:

<?php
    error_reporting(E_ALL);
?>

у коді чи

error_reporting=E_ALL

у php.ini
Це може дуже допомогти у процесі розробки, однак не відловить всі можливі проблемні місця. Наприклад, не побачить неініціалізованих масивів, оскільки PHP автоматично створює масив при спробі записати туди нового елемента (незалежно від його порядку). Тому масиви також слід ініціалізовувати перед їх використанням. Наприклад так:

<?php
    $vector = array();
 
    $vector[] = '25';
?>

Альтернатива

Фактично, register_globals - найпоширеніша причина дірок у безпеці програм на PHP. У самому PHP цей механізм вже досить багато часу має статус застарілого (deprecated). Але не дивлячись на це, дуже багато програмістів продовжують її використовувати замість нового кращого засобу доступу до даних вводу - суперглобальні масиви.
У PHP 4.1 з’явились масиви $_GET, $_POST, $_COOKIE, $_SERVER та $_ENV. Вони надають глобальний доступ до всіх вхідних даних без конфлікту імен у будь-якій частині скрипта та дають однозначну відповідь на питання про походження даних. Нажаль, багато хостингів досі вмикають register_globals для підтримки старих програм, тому розробники мають створювати свої програми, пам’ятаючи про це.

Найпростіший метод захисту від register_globals - використання констант, оскільки механізм реєстрації глобальних змінних не має прямого впливу на константи. Ось таким чином можна уникнути проблем у поганому серверному середовищі:

<?php
    define('ADMIN', isAdmin());
 
    if (ADMIN) {
        //показати прихований контент
    }
?>

Але при деяких обставинах константи самі можуть стати причиною небезпеки. Справа в тому, що неініціалізована константа є строкою, що зберігає ім’я константи (це витікає з того, що PHP є мовою із не суворою типізацією). Таким чином можливий наступний сценарій:

<?php
    if (isAdmin()) {
        define('ADMIN', true);
    }
 
    if (ADMIN) { //умова завжди буде істинною - або bool(true), коли визначене, або string('ADMIN'), коли - ні.
        //показати прихований контент
    }
?>

Кращим за константи підходом є вже загадане суворе порівняння (===) - окрім рівності, воно перевіряє, чи однакові типи даних зліва і зправа. Всі вхідні дані мают строковий тип або є масивами строк. Тому порівняння наприклад із булівським типом завжди буде невдалим при спробі підміни даних:

<?php
    if (isAdmin()) {
        $admin = true;
    }
 
    if ($admin === true) {
        //показати прихований контент
    }
?>

Попри все сказане, найкращий метод захисту від register_globals - вимкнути цей механізм, якщо можливо. Це можна зробити у трьох місцях: php.ini, httpd.conf, .htaccess. Найгнучкіший метод - останній, адже його можна включити у дистрибуцію вашої програми, але слід пам’ятати, що не всі використовують Apache та не всі його версії це підтримують. Тому необхідно намагатись писати універсально-безпечний код.

Ще кілька слів про останній суперглобальний масив $_REQUEST. Його було додано разом із введенням інших масивів з метою більш легкого переходу зі старого коду. Цей масив комбінує у собі дані з GET, POST та cookie заради легкості використання. Але його проблема знову ж таки у можливій втраті даних, адже їх походження ніяк не відокремлюється.
Фактично, для безпечного використання цього масиву необхідно перевіряти, з якого суперглобального масиву прийшли дані, але це нівелює всю зручність засобу. Тож легше використовувати звичайні суперглобальні масиви.

На сьогодні це все. У наступній частині я розповім про найважливіше - перевірку різних типів зовнішніх даних, тож чекайте скоро на новий запис.