Міжсайтовий скриптинг (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. Використовуйте кешування запитів. Це збереже результат запиту на деякий час, продовж якого можна не повторювати запит, а натомість - брати готові дані із кешу. Після того, як кеш стане недійсним - повторити запит і зберегти у кеш.

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

Отже, до 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. Вона приймає всі формати даних і повертає булеве t