Статьи

Безпека веб-додатки Django

  1. огляд
  2. Поширені загрози / методи захисту
  3. Міжсайтовий скриптинг (XSS)
  4. Міжсайтовий підробка запиту (CSRF)
  5. інші атаки
  6. підводимо підсумки
  7. Дивіться також
  8. In this module

Захист даних користувача - важлива частина проектування будь-якого веб-сайта.Ранее ми розглядали деякі найбільш поширені загрози безпеки в темі веб безпека . У даній статті буде представлена ​​практична демонстрація того, як вбудовані механізми захисту Django's обробляють подібні загрози.

огляд

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

Важливо: Найбільш важливий урок, який ви повинні засвоїти, полягає в тому - що ніколи не варто довіряти переданим користувачем даних. Вони включають в себе GET параметри в URL, тіло POST запиту, HTTP заголовки, cookies, завантажені користувачем дані і т.д. Завжди перевіряйте і обробляйте всі вхідні дані. Завжди готуйтеся до гіршого.

Доброю новиною для всіх розробників, які використовують Django, є те, що більшість відомих атак обробляється фреймворком! Стаття Безпека в Django (Django docs) описує методи забезпечення безпеки Django і стратегії захисту веб-додатки розробленого на даному фреймворку.

Поширені загрози / методи захисту

Ми не будемо дублювати документацію Django і в даній статті продемонструємо деякі основні методи забезпечення безпеки в контексті розробляється в даному керівництві додатки LocalLibrary .

Міжсайтовий скриптинг (XSS)

XSS це термін, що застосовується для опису класу атак, що дозволяє атакуючому, через веб-сайт впровадити скрипти, які будуть виконані на пристрої зайшов на сторінку користувача. Часто це відбувається через збереження шкідливого коду в базі даних, звідки даний код буде повернутий і виконаний для що запросив якісь дані користувача (типовий приклад - збереження тега <script> з шкідливим кодом в коментарі, який може побачити інший користувач). Інший вектор атаки - в тому щоб згенерувати певну посилання, при кліці на яку користувач запустить виконання якогось замаскованого коду JavaScript у своєму браузері.

Система шаблонів Django захищає від більшості XSS атак, екрануючи певні символи , Що вважаються "небезпечними" в HTML. Ми можемо продемонструвати це, спробувавши впровадити довільний JavaScript код в наш додаток LocalLibrary через форму додавання автора, створену в Керівництво частина 9: Робота з формами .

  1. Відкрийте веб-сайт, використовуючи сервер розробки (python3 manage.py runserver).
  2. Відкрийте сайт в вашому браузері і ви повинні увійти під обліковим записом супер-користувача.
  3. Перейдіть на сторінку додавання автора (вона повинна бути доступна по URL: http://127.0.0.1:8000/catalog/author/create/ ).
  4. Введіть дані про ім'я та прізвища, дати народження та смерті автора. Потім додайте наступний рядок в поле прізвища:
    <Script> alert ( 'Test alert'); </ script>.

    Примітка: Це нешкідливий скрипт, який, якщо буде виконано, покаже вікно з повідомленням "Test alert" у вашому браузері. Якщо дане вікно з'являється при відкриванні сторінки з створеної подібним чином записом - значить сайт вразливий перед атаками XSS.

  5. Натисніть Submit для збереження запису.
  6. Після збереження автора - він повинен бути відображений, як показано нижче. Так як спрацював захист від XSS - команда alert () не запущена. Замість цього скрипт буде відображатися як звичайний текст.

Якщо ви подивіться вихідний HTML код, ви побачите, що "небезпечні" символи - наприклад такі як дужки тегів - були замінені на їх безпечні еквівалентні html суті (наприклад> на & gt;)

<H1> Author: Boon & lt; script & gt; alert (& # 39; Test alert & # 39;); & lt; / script & gt ;, David (Boonie) </ h1>

Використання шаблонів Django захищає вас від большінтсва XSS атак. Однак існує можливість відключення даного захисту, при якому екранування автоматично не застосуються до всіх полів, які не повинні будуть заповняться користувачем (наприклад, поле help_text зазвичай заповнюється не користувачем, тому Django НЕ буде екранувати його значення).

Так само XSS атаки можуть бути здійснені через інші ненадійні джерела даних, такі як cookies, сторонні сервіси або завантажені файли (і інші джерела, дані яких не були спеціально оброблені перед відображенням на сторінці). Якщо ви відображаєте дані з цих джерел, ви повинні додати ваш власний обробник для "санітарізаціі" даних.

Міжсайтовий підробка запиту (CSRF)

CSRF атаки дозволяють атакуючому виконувати дії від імені іншого користувача без його згоди. Наприклад, припустимо що є хакер, який хоче додати авторів в наш додаток LocalLibrary.

Примітка: Очевидно, що наш хакер робить це не заради грошей! Більш амбітні хакери можуть використовувати описуваний підхід для виконання більш небезпечних завдань (наприклад, перекази грошей користувачів на їх особисті рахунки і т.д).

Для того, щоб зробити це, хакер може створити HTML файл, подібний продемонстрованому нижче, який буде містити форму створення автора (схожу на ту, що ми розробляли в попередніх частинах керівництва), яка буде відправлена ​​як тільки даний файл буде завантажений в браузер. Хакер відправить даний файл всім Бібліотекарям і буде чекати поки хтось із них відкриє файл (він містить тільки нешкідливу інформацію, чесно!). Якщо файл буде відкритий будь-яким залогіненним пользователм, з правами бібліотекаря - тоді форма буде відправлена ​​від його імені і створить нового користувача.

<Html> <body onload = 'document.EvilForm.submit ()'> <form action = "http://127.0.0.1:8000/catalog/author/create/" method = "post" name = 'EvilForm'> <table> <tr> <th> <label for = "id_first_name"> First name: </ label> </ th> <td> <input id = "id_first_name" maxlength = "100" name = "first_name" type = "text" value = "Mad" required /> </ td> </ tr> <tr> <th> <label for = "id_last_name"> Last name: </ label> </ th> <td> <input id = "id_last_name" maxlength = "100" name = "last_name" type = "text" value = "Man" required /> </ td> </ tr> <tr> <th> <label for = "id_date_of_birth"> Date of birth: </ label> </ th> <td> <input id = "id_date_of_birth" name = "date_of_birth" type = "text" /> </ td> </ tr> <tr> <th> <label for = "id_date_of_death"> Died: </ label> </ th> <td> <input id = "id_date_of_death" name = "date_of_death" type = "text" value = "12/10/2016" /> </ td> </ tr> </ table> <input type = "submit" value = "Submit" /> </ form> </ body> </ html>

Відкрийте веб-сервер розробки і прихильника чи критика наразі супер-користувача. Скопіюйте наведений вище текст в файл і потім відкрийте його в браузері. Ви повинні отримати CSRF помилку, тому що у Django є захист від атак даного виду!

Механізм захисту полягає в тому, що ви додаєте тег шаблону {% csrf_token%} в вашу форму. Цей токен буде відображено у вашому HTML як показано нижче, із значенням, унікальним для кожного запитувача форму користувача.

<Input type = 'hidden' name = 'csrfmiddlewaretoken' value = '0QRWHnYVg776y2l66mcvZqp8alrv4lb8S8lZ4ZJUWGZFA5VHrVfL2mpH29YZ39PW' />

Django генерує унікальний для користувача / браузера токен і відхиляє всі форми, які не містять його або містять його невірне значення.

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

Захист Django від CSRF атак за замовчуванням включена. Вам завжди слід використовувати тег {% csrf_token%} в ваших формах і використовувати POST для запитів, які можуть змінити або додати дані в вашу базу даних.

інші атаки

Django так само надає захист від інших видів атак (демонстрація більшості з яких була б складна новачкам для розуміння і не дуже корисна):

Захист від SQL ін'єкції Уразливість SQL ін'єкції дозволяє атакуючому виконати довільний SQL код в базі даних і отримати доступ до даних (прочитати, відредагувати і змінити) незалежно від поточних прав доступу користувача. У більшості випадків ви будете отримувати доступ до даних бази даних, використовуючи суті queryset / model Django. Використовуючи їх для генерації SQL запитів, ви отримаєте коректно сформований і екранований запит для обраної бази даних. Якщо вам необхідно писати "сирі" запити, вам так само потрібно буде продумати захист від ін'єкцій. Захист від Клікджекінга В даному виді атак атакуючий перехоплює введення на видимому шарі сторінки і перенаправляє їх на прихований шар під ним. Цей метод може бути використаний наприклад для відображення офіційного сайту банку, з перехопленням даних для входу в невидимому <Iframe> , Який контролює атакуючий. Django містить захист від клікджекінга у вигляді проміжного програмного забезпечення (middleware) X-Frame-Options , Який підтримується браузерами і може заборонити відображення сторінки всередині <Iframe> . SSL / HTTPS SSL / HTTPS може бути використаний на веб-сервері для шифрування всього трафіку між сервером і користувачем, включаючи дані входу, які інакше будуть відправлятися як звичайний текст (який зможе прочитати будь-який перехопив запит людина). Використання HTTPS високо рекомендовано. Якщо використовується HTTPS, Django дозволяє використовувати такі методи захисту:
  • SECURE_PROXY_SSL_HEADER може бути використано для перевірки що завжди використовується безпечне підключення, навіть якщо дані надходять з проксі, що використовує протокол відмінний від HTTP.
  • SECURE_SSL_REDIRECT використовується для перенаправлення всіх запитів з HTTP на HTTPS.
  • використовуйте HTTP Strict Transport Security (HSTS). Цей HTTP заголовок інформує браузер про те, що всі наступні запити повинні завжди використовувати HTTPS. Спільно з перенаправленням HTTP запитів на HTTPS, ця опція дозволяє забезпечити використання HTTPS в кожному запиті. HSTS може так само бути налаштований опціями SECURE_HSTS_SECONDS і SECURE_HSTS_INCLUDE_SUBDOMAINS або на веб-сервері.
  • Використовуйте 'безпечні' cookies виставивши SESSION_COOKIE_SECURE і CSRF_COOKIE_SECURE в True. Це дозволить забезпечити пересилку даних cookies тільки через протокол HTTPS.
Валідація заголовка Host Використовуйте ALLOWED_HOSTS щоб приймати тільки запити від довірених хостів.

Так само існує безліч інших технік захисту і вказівок щодо їх використання. Ми сподіваємося, що дана стаття дала вам розуміння, яку техніку Django пропонує для забезпечення безпеки. Ми сподіваємося, що ви продовжите вивчення цього питання по документації Django.

підводимо підсумки

Django має методи забезпечення захисту від поширених видів атак, включаючи XSS і CSRF атаки. У даній статті ми продемонстрували, як різні види атак обробляються Django на прикладі нашого застосування LocalLibrary. Ми так само коротко розглянули інші види вразливостей і методи захисту від них.

Це було дуже коротке занурення в питання веб-безпеки. Ми вкрай рекомендуємо вам прочитати Безпека в Django для більш глибокого розуміння.

Наступним і останнім кроком в цьому посібнику буде виконання самостійної роботи .

Дивіться також

In this module

Новости