Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Application Security - ответы на ежедневные вопросы / Сергей Белов (Mail.Ru Group)

284 views

Published on

РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 13:00

Тезисы:
http://ritfest.ru/2017/abstracts/2798.html

В данном докладе будет рассмотрено множество вопросов, с которыми сталкивается AppSec-отдел - как генерировать анти-CSRF токены, где хранить секретные ключи, как тестировать безопасность в сжатые сроки и многое, многое другое.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Application Security - ответы на ежедневные вопросы / Сергей Белов (Mail.Ru Group)

  1. 1. Application Security ответы на ежедневные вопросы Сергей Белов Head of Application Security Mail.Ru Group
  2. 2. План ➔ Автотесты и безопасность ➔ Анти CSRF токены ➔ “Скачать файл по ссылке” ➔ Секретные ключи ➔ 3rd party сайты на основном домене ➔ 3rd party мониторинги и важные данные ➔ Пуш уведомления vs SMS ➔ Внедрение FFmpeg / ImageMagick ➔ Управление юзер контентом ➔ Рейтлимиты ➔ Аутентификация ◆ “Супер” cookies ◆ Разделение сессий пользователей
  3. 3. Автотесты и безопасность
  4. 4. Автотесты: - Уже написаны - Покрывают большинство методов - Знают верные параметры для вызова функций - Чаще всего пишутся и для backend, и для frontend - Используют валидные данные для методов (чтение своего файла, сообщения, письма и т.п.) Автотесты и безопасность
  5. 5. Автотесты и безопасность Тестируем безопасность через автотесты! Frontend ● Отдаем спец символы HTML " ' < > и матчим их - покрываем XSS/HTML инъекции Backend ● Зашиваем в автотесты различные ID, до которых у текущего пользователя не должно быть доступа (ID папок, файлов, сообщений и т.п.) - находим уязвимости класса Insecure Direct Object Reference
  6. 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. 7. Анти CSRF токены
  8. 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. 9. Анти CSRF токены Защита? CSRF токены - рандомное значение в input type="hidden" / HTTP заголовке, которое не знает атакующий Как генерировать, где хранить и сверять?
  10. 10. Анти CSRF токены Framework way: ● Используем стандартные механизмы (Django, Zend, Express) Свое решение: ● Генерация и хранение - избыточно хранить на сервере / сервере, можно взять hmac-sha* от session_id. При каждом login/logout CSRF токен будет изменен ● Можно использовать для подписи действий ● Сверка - Перед проверкой ACL / других валидаторов
  11. 11. Анти CSRF токены - Чем подпись действий может помочь? - Может помочь предотвратить различного рода Parameter Tampering атаки / Insecure Direct Object Reference уязвимости - не сверили права на действие с данными параметрами (что данный юзер может вообще выполнить это действие, например прочитать сообщение, отправить деньги, обновить профиль)
  12. 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. 13. Скачать файл по ссылке
  14. 14. Таск в Jira: Дать пользователям скачивать файлы по ссылке (или сделать превью) Разработчик: <?php file_get_contents($_POST['url']) ?> Атакующий: url = file:///etc/passwd “Скачать файл по ссылке” и SSRF
  15. 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. 16. Секретные ключи
  17. 17. Секретные ключи ● Ключи для подписи сессий ● Соль для криптофункций ● Соль для генерации анти CSRF токенов ● Соль для генерации токенов восстановления пароля ● Пароли для шифрования данных ● Логины и пароли для интеграции с внешними сервисами (трекеры/аналитики и т.п.) ● ... Одно главное правило - не зашивать их в код! Выносим их в конфиги / деплоим через Puppet Hiera-Eyaml
  18. 18. 3rd party сайты на основном домене
  19. 19. 3rd party сайты на основном домене Бизнес желает, чтобы: ● Промо сайты ● Сайты с вакансиями, блоги ● Сайты от аутсорсеров ● Внешние support / ticket системы ● Кастомные проекты ● И т.д. Открывались по адресу: http://example.com/projectname
  20. 20. 3rd party сайты на основном домене Что делают? ● Хостят прямо там же ● Ставят proxy_pass + nginx Как сделать это безопасно? ● Общая “шапка” и <iframe sandbox … > без разрешения allow-top-navigation+ CSP
  21. 21. Пуш уведомления vs SMS
  22. 22. Пуш уведомления vs SMS Перехват SMS: ● Атаки через SS7 (полностью удаленно) ● Таргетированный перехват SMS (нужно физически находиться рядом) ● Через IVR Spoofing (успех атаки зависит от оператора) в случае, если код вместо SMS доставляется звонком ● Malware ● Перевыпуск сим карт ● Работа спец служб Перехват пуш уведомлений: ● Уязвимости Google/Apple/Microsoft ● Неверный механизм подписки на пуши (проблемы backend - передаем ID своего устройства и идентификатор жертвы) ● Возможен перехват через привилегированные приложения (например, для передачи пуша на часы, в мультимедиа систему машины и т.п.)
  23. 23. Пуш уведомления vs SMS Безопасный алгоритм перехода на пуши: 1) Первое подтверждение - через SMS. Дальше шлем пуши 2) В пушах не передаем секретные данные (код подтверждения) визуально, а указываем его в payload. Приложение само вытащит и подставит этот код для проведения операции. 3) Тестируем безопасность бэкенда и все связанные с пушами методы
  24. 24. Внедрение FFmpeg / ImageMagick
  25. 25. Внедрение FFmpeg / ImageMagick Внедрили FFmpeg? ImageMagick? Считайте, что любой юзер может читать любые файлы на сервере / выполнять любые команды ОС Атаки на видеоконвертеры: год спустя - https://www.phdays.ru/program/213682/ (Эмиль Лернер и Павел Черемушкин)
  26. 26. Внедрение FFmpeg / ImageMagick Как все-таки внедрить? - sandbox (docker / SELinux / etc) - Отдельная машина в изолированной сети - API для нужного функционала - Отключение ненужных demuxer’ов (HLS)
  27. 27. Управление юзер контентом
  28. 28. Управление юзер контентом Несколько правил: 1) Отдаем с другого домена (*.example-content-from-users.com) 2) Отключаем различные интерпретаторы на бэкенде 3) Если файл приватный (аттач) генерим ему временный токен и сверяем при открытии на серверах с контентом (например через nginx + LUA)
  29. 29. Рейтлимиты
  30. 30. Важно закладывать в реализацию методов: 1) Возможность ограничивать вызов API методов (по ключевым параметрам) 2) Иметь возможность мониторить сколько раз вызывается метод (позволяет выявлять массовые атаки) 3) Реализовать несколько методов рейтлимитов: абсолютные (например - 5 раз в минуту), по подтверждению после порога (ввод каптчи) Рейтлимиты
  31. 31. 3rd party мониторинги и важные данные
  32. 32. Страницы: - Ввода данных аккаунта - Привязки карты - Восстановления аккаунты - Управление двухфакторкой - И другие важные страницы Не должны (не рекомендуется) содержать внешние трекеры / аналитику / любую другую статику (картинки, стили и т.п.) с доменов, которые не принадлежал компании 3rd party мониторинги
  33. 33. Аутентификация
  34. 34. Вопросов много, мы рассмотрим только следующие: 1) Отдельный домен и “супер” cookies 2) Привязка сессий к пользователю 3) Разделение сессий Аутентификация
  35. 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. 36. Отдельный домен и “супер” cookies - для чего? Привязка сессий к пользователю 1) Изменился fingerprint браузера? 2) Изменился город (по IP)? 3) Истекла сессия? Делаем редирект на account.example.com - там есть супер “cookie”, которая подтверждает то, что пользователь действительно вводил пароль в этом браузере. Все ок - выдаем новую сессию Аутентификация
  37. 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. 38. @sergeybelove s.belov@corp.mail.ru

×