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

1. Application Security
ответы на ежедневные вопросы
Сергей Белов
Head of Application Security
Mail.Ru Group

2. План
➔ Автотесты и безопасность
➔ Анти CSRF токены
➔ “Скачать файл по ссылке”
➔ Секретные ключи
➔ 3rd party сайты на основном домене
➔ 3rd party мониторинги и важные данные
➔ Пуш уведомления vs SMS
➔ Внедрение FFmpeg / ImageMagick
➔ Управление юзер контентом
➔ Рейтлимиты
➔ Аутентификация
◆ “Супер” cookies
◆ Разделение сессий пользователей

3. Автотесты и безопасность

4. Автотесты:
- Уже написаны
- Покрывают большинство методов
- Знают верные параметры для вызова функций
- Чаще всего пишутся и для backend, и для frontend
- Используют валидные данные для методов (чтение своего файла, сообщения, письма и т.п.)
Автотесты и безопасность

5. Автотесты и безопасность
Тестируем безопасность через автотесты!
Frontend
● Отдаем спец символы HTML " ' < > и матчим их - покрываем XSS/HTML инъекции
Backend
● Зашиваем в автотесты различные ID, до которых у текущего пользователя не должно быть
доступа (ID папок, файлов, сообщений и т.п.) - находим уязвимости класса Insecure Direct
Object Reference

6. Плюсы:
● Сокращение времени на изучение функционала
● Большое покрытие
● Внедрение в CI
● Простое тестирование protocol specific мест (например XML - поиск XML eXternal Entity
уязвимостей, кастомные протоколы - подстановка различных типовых payload в user input)
Минусы:
● Не найдем логические и “сложные” уязвимости
● Не протестируем уязвимости платформы, библиотек, фреймворков
● На начальных этапах - большое количество false positive срабатываний
Security Testing Web Applications throughout Automated Software Tests (2006) -
https://www.owasp.org/images/9/99/AutomatedSecurityTestingofWebApplications-StephendeVries.pdf
Автотесты и безопасность

7. Анти CSRF токены

8. Анти CSRF токены
Про CSRF атаку в 1 слайд
GET: http://vulnerable/?action=update_profile&field=value
Атака - <img src="http://vulnerable/?action=update_profile&field=value ">
POST:
<form action=" http://vulnerable/user/update_profile ">
<input type="text" name="field" value="CSRF">
</form>

9. Анти CSRF токены
Защита?
CSRF токены - рандомное значение в input type="hidden" / HTTP заголовке, которое не знает
атакующий
Как генерировать, где хранить и сверять?

10. Анти CSRF токены
Framework way:
● Используем стандартные механизмы (Django, Zend, Express)
Свое решение:
● Генерация и хранение - избыточно хранить на сервере / сервере, можно взять hmac-sha* от
session_id. При каждом login/logout CSRF токен будет изменен
● Можно использовать для подписи действий
● Сверка - Перед проверкой ACL / других валидаторов

11. Анти CSRF токены
- Чем подпись действий может помочь?
- Может помочь предотвратить различного рода Parameter Tampering атаки / Insecure Direct
Object Reference уязвимости - не сверили права на действие с данными параметрами (что
данный юзер может вообще выполнить это действие, например прочитать сообщение,
отправить деньги, обновить профиль)

12. Анти CSRF токены
Подпись действий через анти CSRF токены:
1) Возьмем action_type, param_1, param_2 - это будут params
action_type = send_money
param_1 = sender_id
param_2 = receiver_id
2) Пусть эти параметры примут участие в генерации токена
csrf_token = GenerateCSRFToken(session_id, params)
3) Отдаем значение в формы (например - в едином билдире форм и сверяем при выполнении
действия)
Допустим, мы не проверили что деньги вообще можно отправить этому пользователю. Но
выполнить это действие не получится - нет нужной подписи (токена)

13. Скачать файл по ссылке

14. Таск в Jira:
Дать пользователям скачивать файлы по ссылке (или сделать превью)
Разработчик:
<?php
file_get_contents($_POST['url'])
?>
Атакующий:
url = file:///etc/passwd
“Скачать файл по ссылке” и SSRF

15. А что нужно проверять?
1. Схема - http/https
2. destination_ip - не в локальной сети / не на серверы в trusted zone
3. Ограничить перенаправления (запретить через редиректы обходить ограничения)
4. destination_port (разрешить 80/443)
5. Race Condition
- Резолвнули (IP не наш)
- Пошли за файлом - новый резолв (!)
- Во втором резолве подменяется IP уже на внутренний
Решение: резолвить, проверять IP и передавать явным параметром в CURL
6. Уязвимости библиотек, используемых в качестве HTTP клиента
7. IPv6
8. …
9. Сделать единый сервер для данных задач, изолировать его, реализовать ему API
10. Вдохновиться можно данной реализацией - https://github.com/fin1te/safecurl
“Скачать файл по ссылке” и SSRF

16. Секретные ключи

17. Секретные ключи
● Ключи для подписи сессий
● Соль для криптофункций
● Соль для генерации анти CSRF токенов
● Соль для генерации токенов восстановления пароля
● Пароли для шифрования данных
● Логины и пароли для интеграции с внешними сервисами (трекеры/аналитики и т.п.)
● ...
Одно главное правило - не зашивать их в код!
Выносим их в конфиги / деплоим через Puppet Hiera-Eyaml

18. 3rd party сайты на основном домене

19. 3rd party сайты на основном домене
Бизнес желает, чтобы:
● Промо сайты
● Сайты с вакансиями, блоги
● Сайты от аутсорсеров
● Внешние support / ticket системы
● Кастомные проекты
● И т.д.
Открывались по адресу: http://example.com/projectname

20. 3rd party сайты на основном домене
Что делают?
● Хостят прямо там же
● Ставят proxy_pass + nginx
Как сделать это безопасно?
● Общая “шапка” и <iframe sandbox … > без разрешения allow-top-navigation+ CSP

21. Пуш уведомления vs SMS

22. Пуш уведомления vs SMS
Перехват SMS:
● Атаки через SS7 (полностью удаленно)
● Таргетированный перехват SMS (нужно физически находиться рядом)
● Через IVR Spoofing (успех атаки зависит от оператора) в случае, если код вместо SMS
доставляется звонком
● Malware
● Перевыпуск сим карт
● Работа спец служб
Перехват пуш уведомлений:
● Уязвимости Google/Apple/Microsoft
● Неверный механизм подписки на пуши (проблемы backend - передаем ID своего устройства и
идентификатор жертвы)
● Возможен перехват через привилегированные приложения (например, для передачи пуша на
часы, в мультимедиа систему машины и т.п.)

23. Пуш уведомления vs SMS
Безопасный алгоритм перехода на пуши:
1) Первое подтверждение - через SMS. Дальше шлем пуши
2) В пушах не передаем секретные данные (код подтверждения) визуально, а указываем его в
payload. Приложение само вытащит и подставит этот код для проведения операции.
3) Тестируем безопасность бэкенда и все связанные с пушами методы

24. Внедрение FFmpeg / ImageMagick

25. Внедрение FFmpeg / ImageMagick
Внедрили FFmpeg? ImageMagick?
Считайте, что любой юзер может читать любые файлы на
сервере / выполнять любые команды ОС
Атаки на видеоконвертеры: год спустя - https://www.phdays.ru/program/213682/
(Эмиль Лернер и Павел Черемушкин)

26. Внедрение FFmpeg / ImageMagick
Как все-таки внедрить?
- sandbox (docker / SELinux / etc)
- Отдельная машина в изолированной сети
- API для нужного функционала
- Отключение ненужных demuxer’ов (HLS)

27. Управление юзер контентом

28. Управление юзер контентом
Несколько правил:
1) Отдаем с другого домена (*.example-content-from-users.com)
2) Отключаем различные интерпретаторы на бэкенде
3) Если файл приватный (аттач) генерим ему временный токен и сверяем при открытии на
серверах с контентом (например через nginx + LUA)

29. Рейтлимиты

30. Важно закладывать в реализацию методов:
1) Возможность ограничивать вызов API методов (по ключевым параметрам)
2) Иметь возможность мониторить сколько раз вызывается метод (позволяет выявлять
массовые атаки)
3) Реализовать несколько методов рейтлимитов: абсолютные (например - 5 раз в минуту), по
подтверждению после порога (ввод каптчи)
Рейтлимиты

31. 3rd party мониторинги и важные данные

32. Страницы:
- Ввода данных аккаунта
- Привязки карты
- Восстановления аккаунты
- Управление двухфакторкой
- И другие важные страницы
Не должны (не рекомендуется) содержать внешние трекеры / аналитику / любую другую статику
(картинки, стили и т.п.) с доменов, которые не принадлежал компании
3rd party мониторинги

33. Аутентификация

34. Вопросов много, мы рассмотрим только следующие:
1) Отдельный домен и “супер” cookies
2) Привязка сессий к пользователю
3) Разделение сессий
Аутентификация

35. Отдельный домен и “супер” cookies
https://example.com/login
<form action=" https://account.example.com ">
<input type="text" name="username">
<input type="password" name=password"
</form>
https://account.example.com
Set-Cookie: SuperAuth=_token_; Domain=account.example.com; Secure;
HttpOnly
Set-Cookie: Session=_SESSION_ID_; Domain=example.com; Secure;
HttpOnly
Аутентификация

36. Отдельный домен и “супер” cookies - для чего? Привязка сессий к пользователю
1) Изменился fingerprint браузера?
2) Изменился город (по IP)?
3) Истекла сессия?
Делаем редирект на account.example.com - там есть супер “cookie”, которая
подтверждает то, что пользователь действительно вводил пароль в этом
браузере. Все ок - выдаем новую сессию
Аутентификация

37. Разделение сессий.
Представим себе, что у нас есть example.com и account.example.com. Завтра появились:
- blogs.example.com
- messenger.example.com
- shop.example.com
- …
Которые могут работать и без https и у пользователей может быть “угнан” session_id.
Чтобы один session_id не подходил ко всем проектам можно ввести новый параметр в сессиях -
“scope”. Если текущая сессия никогда не использовалась на данном сервисе - делать редирект на
account.example.com
Аутентификация

38. @sergeybelove
s.belov@corp.mail.ru