О чем мы говорим, когда говорим «проблемы безопасности переднего плана»?
«Безопасность» — это большая тема, и существует много типов проблем с безопасностью. Если мы классифицируем проблемы безопасности в соответствии с областью, в которой они возникают, тоВсе проблемы безопасности, возникающие во внутренних серверах, приложениях и службах, являются «внутренними проблемами безопасности», а все проблемы безопасности, возникающие в браузерах, одностраничных приложениях и веб-страницах, считаются «внешними проблемами безопасности». ". Например, уязвимость внедрения SQL-кода возникает во внутреннем приложении и представляет собой проблему безопасности внутреннего интерфейса, а атака с использованием межсайтовых сценариев (XSS) представляет собой проблему безопасности внешнего интерфейса, поскольку она возникает в браузере пользователя.
В дополнение к классификации по области, в которой возникает проблема безопасности, о ней также можно судить по другому измерению: какая роль в команде лучше всего подходит для решения проблемы безопасности? Это back-end разработка или front-end разработка?
В целом, когда мы говорим о «проблемах безопасности внешнего интерфейса» ниже, мы говорим о проблемах безопасности, которые возникают в браузерах, внешних приложениях или обычно устраняются разработчиками внешнего интерфейса.
8 проблем с внешней безопасностью
В соответствии с приведенным выше методом классификации мы суммировали 8 типичных проблем безопасности внешнего интерфейса, а именно:
- Старомодный XSS
- Будьте осторожны с рисками, связанными с фреймами
- Не попасться на кликджекинг
- неверный вывод о содержании
- Огонь, воровство и товарищи по команде свиньи: небезопасные сторонние зависимости
- Использование HTTPS также может попасть в яму
- Нарушение данных локального хранилища
- Отсутствует проверка целостности статического ресурса
Из-за нехватки места в этой статье сначала будут представлены первые четыре проблемы безопасности переднего плана.
Старомодный XSS
XSS — это аббревиатура от Cross-Site Scripting, старая чепуха, которая долгое время доминировала в списке 10 лучших веб-приложений OWASP и никогда не выпадала из первой тройки. Основная причина проблем с безопасностью, таких как XSS, заключается в том, что браузер ошибочно выполняет вводимые пользователем данные, предоставленные злоумышленником, как сценарий JavaScript.
Существует несколько различных методов классификации XSS, например, в зависимости от того, хранится ли злонамеренно введенный скрипт в приложении, XSS делится на «сохраненный XSS» и «отражение XSS», а также в зависимости от того, есть ли взаимодействие с сервером, его можно разделить на «XSS на стороне сервера XSS» и «XSS на основе DOM».
Независимо от того, как они классифицируются, XSS-уязвимости всегда представляют угрозу безопасности, угрожающую пользователям. Злоумышленники могут использовать уязвимости XSS для кражи различной конфиденциальной информации, включая идентификационную информацию пользователя, изменять веб-страницы для обмана пользователей, даже контролировать браузер жертвы или объединяться с другими уязвимостями для формирования атак червей и т. д. Короче говоря, относительно использования XSS-уязвимостей есть только неожиданные, но не невозможные.
как защитить
Лучший способ защититься от XSS — выполнить строгое кодирование вывода данных, чтобы данные, предоставленные злоумышленником, больше не рассматривались браузером как сценарий и выполнялись по ошибке. Например<script>После кодирования HTML становится<script>, и эти данные будут рассматриваться браузером как обычная строка, а не выполняться как скрипт.
Кодирование — непростая задача, и его необходимо кодировать в соответствии с контекстом, в котором находятся выходные данные. Например, в предыдущем примере, поскольку данные будут помещены в элемент HTML, выполняется кодирование HTML, а если данные будут помещены в URL-адрес, необходимо выполнить кодирование URL-адреса, чтобы изменить его на %3Cscript%3E. Кроме того, существует кодировка JavaScript, кодировка CSS, кодировка атрибутов HTML, кодировка JSON и многое другое. К счастью, современные интерфейсные среды разработки по умолчанию обеспечивают интерфейсное кодирование вывода, что значительно снижает нагрузку на партнеров по фронтенд-разработке.
Другие меры защиты, такие как настройка заголовка HTTP CSP, проверка ввода, включение защиты браузера XSS и т. Д. Все необязательно, поскольку эти меры могут быть обойдены и не могут полностью гарантировать защиту от атак XSS. Тем не менее, они и выходные коды могут работать вместе для реализации стратегий защиты угрожеспособных.
вы можете проверитьOWASP XSS Prevention Cheat Sheet_Prevention_Cheat_Sheet), который содержит подробные инструкции по XSS и его защите.
Будьте осторожны с рисками, связанными с фреймами
Иногда нашим внешним страницам необходимо использовать компоненты страницы, предоставленные третьими лицами, которые обычно представляются в виде фреймов. Типичными примерами являются использование iframe для добавления на страницу сторонних рекламных объявлений, прогнозов погоды, плагинов для обмена в социальных сетях и т. д.
Хотя iframe предоставляет нашим страницам более богатый контент и возможности, он также создает множество рисков для безопасности. Поскольку содержимое в iframe предоставляется третьей стороной, по умолчанию они не находятся под нашим контролем, они могут запускать скрипты JavaScript, плагины Flash, всплывающие диалоговые окна и т. д. в iframe, что может нарушить взаимодействие с пользователем.
Если iframe, скорее всего, повлияет только на взаимодействие с пользователем, кажется, что риск невелик, тогда, если доменное имя в iframe занято злоумышленниками из-за истечения срока действия или третья сторона взломана хакерами, содержимое в iframe будет заменено.Чтобы использовать дыры в безопасности в браузере пользователя для загрузки и установки троянов, вредоносных программ-вымогателей и т. д., эта проблема большая.
как защитить
К счастью, в HTML5 у iframe есть атрибут безопасности, называемый песочницей, с помощью которого можно накладывать различные ограничения на поведение iframe и полностью реализовать принцип «наименьших привилегий». Самый простой способ использовать песочницу — просто добавить это ключевое слово в элемент iframe, например:
<iframe sandbox src="..."> ... </iframe>
Песочница также добросовестно реализует принцип «Безопасность по умолчанию», то есть, если вы просто добавите этот атрибут и оставите значение атрибута пустым, тогда браузер наложит самые строгие ограничения на управление фреймами в истории, в основном говоря, Can' не делать ничего, кроме разрешения отображения статических ресурсов. Например, ни отправки формы, ни всплывающего окна, ни выполнения скрипта и т. д., даже Origin будет вынужден переназначить уникальное значение, другими словами, страницы в iframe, обращающиеся к собственному серверу, будут считаться перекрестными. - домен спросить.
Кроме того, песочница также предоставляет множество параметров конфигурации, которые мы можем контролировать более детально. Вот некоторые типичные параметры:
- allow-forms: Разрешить отправку форм в фреймах.
- allow-popups: разрешить появление новых окон или вкладок в iframe (например, window.open(), showModalDialog(), target="_blank" и т. д.)
- allow-scripts: Разрешить выполнение JavaScript в фреймах.
- Allow-Same-Origin: позволяет веб-страницам в IFRAME открывать гомологичные стратегии.
Для получения более подробной информации см.Введение в песочницу в iframe.
Не попасться на кликджекинг
Существует слово «защищенный».Когда мы используем контент, предоставленный другими через iframe, наши собственные страницы также могут быть помещены в их тщательно сконструированные iframe или фреймы преступниками для атак перехвата кликов.
Это мошенническая атака, для завершения которой требуется активное участие пользователя. Обычные шаги атаки следующие:
- Злоумышленник тщательно создает содержимое, побуждающее пользователей щелкнуть мышью, например небольшую игру на веб-странице.
- Наши страницы, чтобы поместить их iframe
- Используйте стили CSS, такие как z-index, чтобы наложить этот iframe прямо над вертикальным направлением мини-игры.
- Установите для iframe прозрачность 100%.
- После того, как жертва заходит на эту страницу, невооруженным глазом видна небольшая игра: если ее заставить кликнуть, то она на самом деле кликнет на нашу страницу в iframe.
Опасность кликджекинга заключается в том, что атака использует личность пользователя жертвы и делает что-то без ее ведома. Если вы просто заставляете пользователей подписываться на определенную учетную запись Weibo, это кажется терпимым, но если вы удаляете важную запись файла или украдете конфиденциальную информацию, причиненный вред может быть невыносимым.
как защитить
Существуют различные средства защиты от кликджекинга, такие как схемы взлома фреймов. Рекомендуемой защитой является использование X-Frame-Options: DENY HTTP Header, чтобы явно указать браузеру не отображать содержимое текущего HTTP-ответа в HTML-фрейме.
Дополнительные сведения о кликджекинге см.OWASP Clickjacking Defense Cheat Sheet.
неверный вывод о содержании
Представьте себе такой сценарий атаки: веб-сайт позволяет пользователям загружать изображения в комментариях, когда злоумышленник загружает изображения, создается впечатление, что он отправляет файл изображения, но на самом деле это файл сценария, содержащий JavaScript. Файл избежал проверки типа файла (это связано с общей проблемой безопасности загрузки вредоносного файла, но, поскольку он не имеет тесного отношения к внешнему интерфейсу, он пока не будет подробно описываться) и хранится в сервер. Затем, когда жертва получает доступ к этому комментарию, браузер запрашивает сценарий JavaScript, замаскированный под изображение, и, если браузер неправильно определяет тип содержимого (тип MIME) ответа, он будет Файл изображения выполняется как сценарий JavaScript, и атака удалась.
Суть проблемы заключается в том, что заголовок Content-Type, установленный внутренним сервером в возвращаемом ответе, предоставляет браузеру только предположение о типе содержимого текущего ответа, и браузер может вывести его на основе фактического содержимого. ответа самостоятельно Тип содержания.
В приведенном выше примере серверная часть предложила браузеру отобразить ответ HTTP в соответствии с изображением через заголовок Content-Type, но браузер обнаружил, что ответ на самом деле был JavaScript, поэтому он взял на себя инициативу интерпретировать и выполнить ответ как JS скрипт, возникают проблемы с безопасностью.
как защитить
Браузер делает вывод о типе ответа на основе содержания ответа.Изначально это очень «умная» функция.Это воплощение мощной отказоустойчивости браузера, но она несет риски безопасности. Чтобы избежать таких проблем с безопасностью, нужно явно запретить браузерам определять тип ответа, установив HTTP-заголовок X-Content-Type-Options.
В том же сценарии атаки, что и выше, Content-Type, возвращаемый внутренним сервером, предполагает, что браузер отображает содержимое в соответствии с изображением.Браузер обнаруживает наличие HTTP-заголовка X-Content-Type-Options и его параметра. Значение nosniff, поэтому оно больше не будет использоваться.Чтобы сделать вывод о типе содержимого, но принудительно отобразить его в соответствии с изображением, то, поскольку это на самом деле сценарий JS, а не реальное изображение, этот сценарий будет рассматриваться браузером как поврежденный или неправильно отформатированный образ процесса, а не как JS-скрипт, что в итоге предотвращает возникновение проблем с безопасностью.
Дополнительные сведения о X-Content-Type-Options см.здесь.
резюме
В этой статье рассматриваются проблемы безопасности внешнего интерфейса и представлены четыре типичных проблемы безопасности внешнего интерфейса, включая их причины и методы защиты. В следующей статье мы рассмотрим несколько других вопросов безопасности внешнего интерфейса, так что следите за обновлениями.
Для получения более замечательных идей, пожалуйста, обратите внимание на публичный аккаунт WeChat: ThoughtWorks Business Insights