Page 94 - 4636

Звичайно, так зручніше, але від цього страждає безпека, тому якщо . php-файл потрапить до рук
зломщиків, вони тут же отримають доступ до бази даних з усіма правами, які є у користувача bob.
Краще все-таки помістити ім'я користувача і пароль на файл, що міститься за межами каталогу
документів веб-додатку, і включити цей файл сценарій:
<?php// Це файл dbconnect.php
$db_server = 'localhost';$db_user_name = 'bob';$db_password =
'secret';$db_name =
'somedb';?><?phpinclude('../code/dbconnect.php');$conn =
@newmysqli($db_server, $dbusername, $db_password, $db_name);// іт.д.?>
Ці міркування справедливі для будь-яких секретних даних, яким не зашкодить ще один рівень
захисту.

4.6 Файлова система

РНР був розроблений з урахуванням роботи у локальній файловій системі. У зв'язку з цим
необхідно розглянути два питання.
1. Чи-будуть якісь файли, які ми записуємо на диск, видимими ще комусь?
2. Якщо так, то чи будуть інші користувачі мати доступ до файлів, до яких не слід, наприклад,
до /etc/passwd?
Або потрібно не записувати інформацію у файли з широкими правами доступу, або не поміщати
файли в такі місця, до яких можуть мати доступ інші користувачі багатокористувацької операційної
системи на зразок різновидів Unix.Крім того, необхідно бути особливо обережним при вирішенні
користувачам самим вводити ім'я потрібного їм файлу. Якщо в нашому кореневому каталозі
документів (c:\Program Files\Apache Software Foundation\Apache2.2,htdocs\) є каталог з набором
файлів, доступ до яких хотілося б дозволити користувачам, то ми можемо нарватися на неприємності,
якщо хтось захоче побачити файл ..\\.\php\php.ini.Це дозволить зловмиснику побачити деталі
нашої інсталяції РНР і дізнатисяпро наявність очевидних проломів в безпеці, якими можна
скористатися. Усунути цю проблему також нескладно: якщо користувачам дозволено введення імен
файлів, необхідна агресивна фільтрація. Для попереднього прикладу достатньо видалити всі рядки . . \,
а також заборонити абсолютні шляхи типу с:\mysql\my.ini.
Стійкість коду і помилки. Ми вже говорили про це: не варто очікувати від веб-додатка ні гарної
ефективності, ні безпеки, якщо його код не був ретельно протестований і проглянутий, або ж він
настільки складний, що просто незрозумілий. Це не звинувачення, а просто констатація факту, що всі
програмісти можуть помилятися при написанні коду. Коли користувач заходить на веб-сайт, вводить у
поле пошуку слово (наприклад, “викидання”) і клацає на кнопці “Пошук”, навряд чи у нього
залишиться хороша думка про стійкість або безпеку, якщо відразу після цього він побачить
повідомлення:
Ой-ой-ой! Це не повинно було статися. ПОМИЛКА ПОМИЛКА ПОМИЛКА! ! ! !
Якщо з самого початку планувати стійкість роботи програми, можна істотно знизити ймовірність
виникнення проблем через людські помилки. Можливі такі заходи:
 проведіть повний етап проектування продукту, можливо, зі створенням прототипів. Чим
більше народу перегляне план ваших дій, тим більша вірогідність, що будуть виявлені проблеми ще до
їх виникнення. На цьому етапі зручно також перевірити зручність використання інтерфейсу;
 виділіть спеціальних людей для тестування проекту. У багатьох проектах це просто не
виконується, або ж для перевірки роботи 50 розробників наймається один тестер. Розробники зазвичай
не бувають хорошими тестерами! Вони пишуть чудовий код, що відмінно працює з вірними вхідними
даними, але в інших областях вони не так сильні. У великих компаніях по розробці ПО відношення

91