Документ описывает модель аутентификации HTTP-сообщений на основе хэш-функций для веб-приложений, учитывая проблемы, связанные с безопасностью, такие как атаки CSRF и недостатки в действующих протоколах. Разработан общий метод аутентификации, позволяющий контролировать и валидировать данные с клиентской стороны, и представлен прототип механизма защиты веб-форм, реализованный в Django. Основное внимание уделяется контролю целостности параметров, авторизации пользователей и защите от различных типов атак.

1. Общая модель аутентификации
HTTP-сообщений на основе хэш-
функций в веб-приложениях
Денис Колегов, Николай Ткаченко
Кафедра защиты информации и криптографии
Томский государственный университет
Positive Hack Days IV
21 – 22 мая 2014

2. Актуальность работы
• Протокол HTTP не имеет встроенных механизмов
аутентификации сообщений
• Аутентификация HTTP-сообщений
– Аутентичность источника запроса
– Целостность имен и значений параметров
• OWASP TOP 10 2013
– A4 – Insecure Direct Object Reference
– A7 – Missing Function Level Access Control
– A8 – Cross-Site Request Forgery (CSRF)
• Дополнительные возможности
– Уменьшение поверхности атак на приложение
– Противодействие средствам автоматизации 2

3. Пример 1
3

4. Пример 2
• Атака <BASE> jumping
<base href='http://evil.com/'> ← HTML-инъекция
<form action=‘create_folder.php'>
<input type=“hidden" name=“csrf_token“ value=“21312”>…
</form>
• Выполняется запрос
http://evil.com/create_folder.php?csrf_token=21312
• Использование полученного токена в другом
контексте
http://example.com/admin/delete_account.php?csrf_token=21312
4

5. Известные механизмы
• «Подписи запросов» API
– Yahoo, Amazon S3, Facebook
• WAF
– Trustwave ModSecurity: HMAC Token Protection
– F5 Networks ASM: Dynamic Content Value
• ASP.NET
– Event Validation
– View State MAC
5

6. Научная новизна
• Разработана модель аутентификации HTTP-сообщений в
рамках модели ABAC
• Предложен общий метод аутентификации сообщений,
позволяющий контролировать и валидировать данные,
генерируемые на клиентской стороне
• Построен протокол аутентификации сообщений,
адаптированный для применения в веб-приложениях
– Хранение данных в сессии
– Хранение данных на стороне клиента
6

7. Аутентификатор
• Аутентификатор – это строка, вычисленная по атрибутам
объекта доступа в соответствии с политикой безопасности
• Auth = {упорядоченный список имен параметров} ||
{cписок (имя параметра = значение) ||
список (имя параметра = #)} ||
идентификатор пользователя ||
идентификатор ресурса ||
операция
• Атрибут объекта mac = h(kr, auth, time)
7

8. Метод построения
1. Построить список L параметров запроса к объекту O
2. Если параметры из списка L являются контролируемыми по
имени, то положить auth = auth || i1 ||… || im, где {i1, …, im} –
упорядоченное множество имен параметров
3. Для каждого контролируемого по значению параметру lL
положить auth = auth || l || Permit_Value(O, l) и удалить его из L
4. Для каждого валидируемого параметра lL положить auth = auth
|| l || ([Permit_Value(O, l)] / Permit_Alphabet) и удалить его из L
5. Положить auth = auth || IDs || IDr || op
8

9. • Элементы модели
– Операции – методы GET, POST, PUT, DELETE
– Объекты – URI
– Атрибуты объектов – параметры доступа к объекту
– Субъект-сессии – HTTP-запросы к объектам
– Атрибуты субъектов – параметры и заголовки запроса
• Предикат доступа
– Доступ субъект-сессии к объекту разрешен, если и только
если аутентификатор, построенный по атрибутам объекта,
равен аутентификатору, построенному по атрибутам
субъект-сессии
Модель ABAC
9

10. Протокол
• Параметры протокола
– k – долговременный ключ сервера
– kr – одноразовый случайный ключ сервера
– IDr – идентификатор защищаемого ресурса
– IDs – идентификатор пользователя
– LP – политика безопасности
– time – текущее значение времени
• Действия протокола (IDs, IDr)
– Client → Server: начальный запрос с IDs к ресурсу
– Client ← Server: описание объекта O с атрибутами mac = h(kr,
auth, time), Ek(LP , time, kr)
– Client → Server: запрос с IDs’ к IDr’, mac, Ek(LP, time, kr)
10

11. Возможности
• Контроль целостности имен и значений параметров
• Базовая валидация значений параметров в заданном алфавите
• Базовая авторизация пользователей
• Независимость от устойчивых и разделяемых сессий
• Защита от атак класса CSRF
• Защита CSRF-токенов
– время жизни – защита от атак повтора
– рандомизация – защита от атак BREACH
– контекст – защита от атак утечки 11

12. Proof of concept
• Django
• Механизм защиты веб-форм
• Предположения
– Использование метода POST для отправки формы
– Защита только критичных веб-форм
• Режимы
– Stateless
– Stateful
• Адрес проекта
– https://github.com/tsu-iscd/django-HTTPauth 12

13. Схема взаимодействия
13

14. Описание политики
auth_policy = {
“object”: “регулярное выражение”,
“subject”: “имя идентификатора пользователя”,
“name_protection”: True | False,
“replay_protection”: {
“enable”: True | False,
“interval”: “значение”},
“parameter_protection”: {
“имя параметра”: {
“value”: “значение” | “регулярное выражение”,
“action”: “control” | “validate”}, … }
} 14

15. Пример политики
class ClientForm(forms.Form):
product = forms.CharField(initial='Test')
price = forms.IntegerField()
policy = {'object':'http://127.0.0.1:8000/add/',
'name_protection' : False,
'replay_protection': {
'enable':True,
'interval':'30' },
'parameter_protection': {
‘product': {
'action':'validate',
'value':'[A-Za-z]+'},
'price': {
'action':'control',
'value' : '200' }}}
15

16. Пример формы
16

17. Заключение
• Построена модель аутентификации HTTP-сообщений в
рамках модели ABAC
• Предложен общий метод аутентификации сообщений,
позволяющий контролировать и валидировать данные,
генерируемые на клиентской стороне
• Реализован прототип механизма защиты веб-форм в
Django
– Контроль целостности имен и значений параметров, а также их
валидация в заданном алфавите
– Базовая авторизация пользователей
– Независимость от устойчивых и разделяемых сессий
– Защита от атак класса CSRF
17

18. Благодарю за внимание!
Вопросы?
Колегов Денис
Доцент кафедры защиты информации и криптографии
Томский государственный университет
E-mail: dnkolegov@gmail.com
Николай Ткаченко
Аспирант кафедры защиты информации и криптографии
Томский государственный университет
E-mail: notkachenko@gmail.com
18