Page 1

Средства обеспечения

безопасности

веб-приложений на основе фреймворка

Django

ст.гр.ПС-10м

Ларин Борислав

Почему выбран Django?

●Легкий в узучении

●Легкочитаемый код (благодаря Python)

●Широкие возможности

●Использование в бизнесе

○Необходимо хранить секреты

●Многие вопросы безопасности продуманы

заранее

Возможные уязвимости

Большинство сайтов сталкиваются с одинаковыми проблемами

безопасности, независимо от фреймворка

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

● Подделка HTTP-запросов

● SQL-иньекции

● Разграничение доступа

● etc

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

Представление:

def say_hello(request):

name = request.GET.get('name', 'world')

return render_to_response("hello.html", {"name" : name})

Шаблон:

<h1>Hello, {{ name }}!</h1>

Предполагаемый результат:

<h1>Hello, Jacob!</h1>

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

Опасность:

Пользователь вводит в поле name:

<i>Jacob</i>

Получаем результат:

<h1>Hello, <i>Jacob!</i></h1>

Намного более опасно - <script>

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

Возможные последствия:

● Нарушение верстки и внешнего вида страницы

● Измененная логика поведения JavaScript

Утечка данных (cookies)

Выход: обязательно экранировать ВЕСЬ пользовательский ввод с

помощью тега {% escape %}

Подделка HTTP-запросов

Подделка HTTP запросов» (Cross-Site Request Forgery) является

дырой в системе безопасности веб сайта. Она случается когда

вредоносный сайт заставляет пользователя, незаметно для него,

загрузить URL с сайта, на котором пользователь уже авторизован.

Например, для выхода из авторизации сайта необходимо посетить

страницу http://me.com/logout. Вредоносному сайту достаточно

показать в <iframe> необходимую страницу, и запрос по ней будет

отослан от имени вашей сессии.

Подделка HTTP-запросов

Решение:

Использование для всех критических к подобным

уязвимостям частям сайта использовать запрос

POST, и присоединять т.н. csrf token, уникальный

для данной сессии и запроса.

При разборе запроса на сервере он проверяется, и

если установлено, что он валидный, выполнение

запроса продолжается — иначе возвращается

ошибка доступа 403.

SQL-иньекции

Во многом похожи на атаки межсайтового скриптинга (XSS), но в

SQL-иньекциях атакуется база данных веб-приложения

Пример:

def user_contacts(request):

user = request.GET['username']

sql = "SELECT * FROM user_contacts WHERE username = '%s';" % username

Ввод пользователя:

' OR 'username'='admin

Итоговый SQL-запрос:

SELECT * FROM user_contacts WHERE username = '

' OR 'username'='admin'

SQL-иньекции

Защита от подобных видов атаки упрощается использованием Object

Ralation Mapping (ORM), благодаря которой нет необходимости

напрямую писать SQL-запросы.

Но в некоторых случаях, при сложных запросах к БД, может

понадобится “чистый” SQL.

Решение этой проблемы такое же, как и в XSS-атаках —

экранирование пользовательского ввода. Однако там экранировался

вывод на страницу, а в данных видах защиты экранируются данные,

передаваемые в БД с помощью django.db.backend.quote_name()

Разграничение доступа

Многие веб-приложения предоставляют возможность работы с

персональными данными: фотографии, письма, сообщения и т.д.

Подобные данные необходимо защитить от несанкционированого

просмотра другими пользователями.

Возможно, необходимо показывать некую информацию только

авторизованным пользователям.

● Декоратор @login_required — дает доступ к представлению

только после login

Разграничение доступа

Поэлементная защита объектов приложения:

Каждому объекту добавляется поле “владелец”, и список

разрешенных пользователей

class Photo(models.Model):

photo = models.ImageField()

owner = models.ForeignKey('User')

shared_with = models.ManyToMany('User')

....

Разграничение доступа

При доступе пользователя к объекту проверяется, входит ли он в одну

из этих категорий:

user = session.user

if not user in (shared_with.objects.all() + owner):

raise Http403

Спасибо за внимание

Вопросы?