Page 89 - 4636
P. 89
властивості. Машини деяких користувачів внутрішньої корпоративної мережі можуть містити таке ПЗ,
і воно буде виконувати атаки на сервер абсолютно без відома цих користувачів.
Незадоволені працівники. Ще одна група, яку слід брати до уваги - це працівники компанії. Ці
працівники з будь-яких причин можуть заподіяти або мати намір заподіяти шкоду компанії, в якій
вони працюють. Мотиви можуть бути різними, але такі працівники можуть, наприклад, намагатися
стати хакерами-аматорами або отримати інструменти для атак на сервери зсередини корпоративної
мережі. Якщо виставити потужний захист від зовнішнього світу, але залишитися повністю відкритими
для внутрішніх атак, то такий захист нічого не вартий. Це вагома причина для реалізації так званої
демілітаризованої зони (DMZ), яка буде розглянута нижче в даній лекції.
Крадіжки обладнання. Ви можете навіть не подумати про таку загрозу безпеки: хтось просто
заходить у приміщення сервера, відключає якийсь апарат і забирає його з будівлі. Ви не уявляєте собі,
наскільки просто можна увійти в офіси багатьох компаній і прогулюватись там, не викликаючи
жодних підозр. Зайшовши в потрібне місце в потрібний час, можна вийти звідти з новим сервером,
жорсткі диски якого забиті конфіденційними даними.
Напевно, це неприємно визнавати, але одна з найбільших проблем безпеки в наших системах - це
ми самі і написаний нами код. Якщо не звертати уваги на безпеку, якщо писати незграбний код і не
морочитися з тестуванням та перевіркою захищеності системи, то ми допоможемо зловмисникам в їх
спробах скомпрометувати нашу систему. Якщо ви щось робите, робіть це як слід. Інтернет не прощає
безтурботних і ледачих. Найважче витримати цей принцип, коли потрібно переконати шефа або
головбуха, що зусилля щодо захисту варті того. Кількох хвилин на лекцію про негативні ефекти (в
тому числі і для підсумкової прибутку) огріхів в безпеці буде достатньо, щоб переконати їх: додаткові
зусилля окупляться в світі, де репутація означає дуже багато.
4.3 Захист коду
Наступний аспект нашого підходу до безпеки - окреме дослідження кожного компонента і
обдумування, як можна підвищити їх захист. Ми почнемо цю лекцію з розгляду того, що може
поліпшити захист нашого коду. Звичайно, ми не зможемо розповісти про все, що можна зробити для
захисту від всіх можливих загроз безпеки, але, принаймні, ми намітимо основні напрямки. Тут ми
розглянемо окремі специфічні області в РНР.
Фільтрація користувальницького введення.
Один з найбільш важливих аспектів захисту нашого веб-додатка - це фільтрація всіх даних, які
вводить користувач. Автори програм повинні фільтрувати всі дані, що надходять із зовнішніх джерел.
Це не означає, що систему слід проектувати на основі припущення, що всі користувачі - шахраї.
Потрібно, щоб вони відчували себе комфортно, і щоб їм подобалося працювати з вашим додатком. Але
необхідно підготуватися до всіх варіантів неправильного використання системи. При належному рівні
фільтрації можна значно зменшити кількість зовнішніх загроз і суттєво підвищити стійкість нашої
системи. Навіть якщо повністю довіряти своїм користувачам, однак не можна бути впевненим, що в їх
комп’ютерах не завелися якісь шпигунські або інші програми, які можуть змінювати або посилати нові
запити на наш сервер. І оскільки зрозуміло, наскільки важливо фільтрувати дані, одержувані від
зовнішніх клієнтів, ми розглянемо способи такої фільтрації.
Перевірка очікуваних значень. Іноді користувач повинен вибрати одне з можливих значень -
наприклад, спосіб доставки (наземним транспортом, терміновий, нічний), область або район і т.д. А
тепер уявіть собі таку просту форму:
<html><head> '<title>Hy і якої
ти...статі?</title></head><body><formaction="submit_form.php"
method="POST"><inputtype="radio" name="gender"
value="чоловіча"/>Чоловіча<Ьr/>
86
