9 марта 2012 г.

Новинки Django 1.4, day 2: Безопасность и формы

Продолжаем «неделю Джанго», начало в предыдущих заметках ORM-плюшки и Day 0. До релиза 1.4 пишем про новинки фреймворка. Сегодня в фокусе безопасность.

Обновлен механизм хэширования паролей
Теперь вместо SHA1, считающегося недостаточно надёжным, по-умолчанию используется более устойчивый к брутфорсу PBKDF2. Если выбор разработчиков Django вам не по нраву, можно настроить свой предпочитаемый тип хэширования в переменной PASSWORD_HASHERS, выбрав из уже имеющегося списка, либо написав свой собственный. Надо заметить, что пароли хранятся в том же формате, что и раньше, так что пользователям сбрасывать их не придётся. Более того, в момент аутентификации со старым типом хэша последний будет апгрейдиться до PBKDF2 автоматически.

На наш взгляд очень правильное и изящное с точки зрения обратной совместимости решение.

Защита от кликджекинга (clickjacking) 
Кликджекингом называют ситуацию, когда пользователь, совершая клик на специально сформированной странице злоумышленника, на самом деле кликает по ссылке на совершенно другом сайте. Для борьбы с таким видом уязвимости вебсайтов добавили middleware, выставлющую специальный заголовок, который в современных браузерах запретит открытие сайта в ифрейме на других сайтах.

Подробнее про кликджекинг в моей заметке «Боремся с clickjacking» и в доках джанги.

Улучшения в CSRF-защите и XSS-защите
Добавлена поддержка CSRF-защиты для PUT- и DELETE- запросов, что облегчает работу с REST-вьюхами. Теперь можно настраивать путь CSRF-куки а также передавать её через HTTPS. Чтобы вид гарантированно посылал CSRF-куку появился декоратор ensure_csrf_cookie.
Подробнее про CSRF в целом

Для защиты сессионных кук от посягательств зловредного кода на javascript, оставленного на плохо защищенной от XSS странице, неплохо бы иметь дополнительную защиту. Теперь нельзя получить доступ к таким кукам через document.cookie. Это обратно несовместимое изменение, но оно вполне оправдано.

Подробнее в моей заметке «HttpOnly куки и с чем их едят».


Криптографическая подпись
Docs

В Django 1.4 появилось интересное API для криптографической подписи данных. Лучше абзаца слов скажут несколько строчек кода:
>>> signer = Signer()
>>> signer.sign('My string')
'My string:GdMGD6HNQ_qdgxYP8yBZAdAIV1w'
>>> signer = Signer(salt='extra')
>>> signer.sign('My string')
'My string:Ee7vGi-ING6n02gkcJ-QLHg6vFw'
>>> signer.unsign('My string:Ee7vGi-ING6n02gkcJ-QLHg6vFw')
u'My string'

Можно подписывать как строчки, так и любые другие объекты, в качестве ключа используется SECRET_KEY из settings, опционально можно добавить соль. Для проверки того, когда было создано подписываемое значение есть готовый класс TimestampSigner.
Это низкоуровневое API хорошо подойдет для проверки целостности данных в hidden-полях, генерации урлов для восстановления пароля, других одноразовых урлов для доступа без авториазции и т.п.

Кроме того, Django открывает разработчикам и более высокоуровневое применение Signer: хранение данных сессии в куках. Гарантируется целостность данных в сессии за счёт подписи, но сами значения не шифруются и передаются открытым текстом. Стоит также учитывать ограничение на размер куки в 4кб и то, что размер куки влияет на то, как быстро открываются страницы вашего сайта. Зачем же такие ограничения? Для нового FormWizard'а.

Новый FormWizard
Docs

Внедрение криптографической подписи в Django связано с новой реализацией многошаговых форм. Теперь FormWizard основан на Class-based Views и поддерживает различные бэкенды для записи данных форм при переходе между шагами. Ранее хранившиеся в hidden-полях, теперь они могут быть сохранены как в сессии, так и в подписанных куках.

Нет смысла повторять здесь целиком документацию FormWizard, рекомендуем ознакомиться в первоисточнике. В целом, создавать многошаговые формы должно стать сильно удобней.

To be continued...
Завтра будет пост про новые фичи в тестировании.



Комментариев нет:

Отправить комментарий