Page 93 - 4636

<p align="center">Користувач дав нам
"15000€".</p>$lt;script type="text/javascript"><br />//
Шкідливий JavaScript-код.<br /></script><p
align="center">Користувач дав нам "15000€".</p><script
type="text/javascript"><br />// Шкідливий JavaScript.<br
/></script>
А в браузері він буде відображено так:
<р align="center">Користувач дав нам
"15000€".</р><scripttype="text/javascript">// Шкідливий JavaScript-
код.</script><p align="center">Користувач дав нам "15000
євро".</р><script type="text/javascript">// Шкідливий JavaScript-
код.</script>
Зверніть увагу, що функція htmlentities замінила символ євро (€) відповідною символьною
підстановкою (€ ), htmlspecialcharsзалишила його без змін.У тих випадках, коли потрібно
дозволити користувачам вводити деякі елементи HTML - наприклад, на електронній дошці оголошень,
де добре б керувати шрифтом, його кольором і стилем (напівжирний або курсив) - доведеться
виконувати розбір рядків, щоб знаходити в них дозволені і заборонені елементи.

4.5 Організація коду

Багато хто вважає, що будь-який файл, до яких користувачі не звертаються з Інтернету, не
повинен бути в кореневому каталозі сайту. Приміром, якщо кореневий каталог сайту дошки
оголошень має шлях /home/httpd/messageboard/ www, то включаються файли та інші файли
слід помістити в якесь інше місце - наприклад, /home/httpd/messageboard/code. Тоді якщо
потрібно вказати в коді включення таких файлів, можна написати:
require_once('../code/user_object.php');
Причина такої обережності полягає в тому, що користувач-зловмисник може запросити файл,
який не відноситься до .php - або HTML-файлів. Більшість веб-серверів за замовчуванням просто
виводять вміст такого файла у вихідний потік. І якщо запитати сценарій користувача object.php,
який міститься десь в каталозі загальнодоступних документів, то користувач побачить весь вміст
цього сценарію. Маючи повний код реалізації, користувач отримує в своє розпорядження вашу
інтелектуальну власність, а також може проаналізувати сценарій та знайти можливі прогалини в
безпеці, які ви випустили з уваги. Щоб такого не сталося, потрібно налаштувати веб-сервер так, щоб
він дозволяв запити тільки .php і . html-файлів, а запити інших файлів повинні повертати помилку
сервера. З цієї ж причини не слід зберігати у каталозі загальнодоступні документи та інші файли:
файли паролів, текстові файли, файли конфігурації або спеціальні каталоги. Навіть якщо ми впевнені в
правильному налаштуванні нашого веб-сервера, ми могли щось упустити. А в майбутньому наш веб-
додаток може переміститися на інший сервер, конфігурація якого може виявитися не настільки
бездоганною, і ми опинимося відкритими для проникнення. Якщо у файлі php.ini включений параметр
allow_url_fopen, то теоретично ми можемо включати або вимагати файли з видалених серверів.
Це може виявитися ще одним порушенням безпеки в нашому додатку, тому краще відмовитися від
включення файлів з віддалених комп'ютерів - особливо з недоступних нашому контролю. Аналогічно
не варто вирішувати, які файли включати або вимагати, на основі введених користувачем даних,
оскільки невірні дані можуть також наробити проблем.
Вміст коду.
Чимало наведених нами фрагментів коду для доступу до баз даних містили ім'я бази, ім'я
користувача та пароль у вигляді звичайного тексту, начебто
$соnn = @newmysqli("localhost", "bob”, "secret”, "somedb");
90