Skip to content

Latest commit

 

History

History
65 lines (39 loc) · 11.3 KB

Securing_Cascading_Style_Sheets_Cheat_Sheet.md

File metadata and controls

65 lines (39 loc) · 11.3 KB

Шпаргалка для защиты каскадных таблиц стилей (CSS)

Introduction

Цель этого CSS (не XSS, а Каскадная таблица стилей) Шпаргалка предназначена для информирования программистов, тестировщиков, аналитиков безопасности, front-end разработчиков и всех, кто интересуется безопасностью веб-приложений, о необходимости использования этих рекомендаций или требований для повышения безопасности при разработке каскадных таблиц стилей.

Давайте продемонстрируем этот риск на примере:

Сантош - программист, который работает в компании под названием X и является автором каскадной таблицы стилей для реализации стиля веб-приложения. Приложение, для которого он пишет CSS-код, имеет различные роли, такие как Студент, Учитель, Суперпользователь и Администратор, и эти роли имеют разные разрешения (PBAC - Управление доступом на основе разрешений) и роли (RBAC - Управление доступом на основе ролей). Эти роли не только имеют разные элементы управления доступом, но и могут иметь различный стиль оформления веб-страниц, который может быть специфичен для отдельного человека или группы ролей.

Сантош считает, что было бы отличной оптимизированной идеей создать CSS-файл "глобального стиля", который содержит все стили/селекторы CSS для всех ролей. В соответствии с их ролью будет отображаться определенная функция или элемент пользовательского интерфейса. Например, функции Администратора будут отличаться от функций Студента, Преподавателя или Суперпользователя. Однако некоторые права доступа или функции могут быть общими для некоторых ролей.

Пример: Настройки профиля будут применимы ко всем присутствующим здесь пользователям, в то время как Добавление пользователей или Удаление пользователей применимо только к Администратору.

Пример:

  • .login
  • .profileStudent
  • .changePassword
  • .addUsers
  • .deleteUsers
  • .addNewAdmin
  • .deleteAdmin
  • .exportUserData
  • .exportProfileData
  • ...

Теперь давайте рассмотрим, какие риски связаны с таким стилем программирования.

Риск #1

Мотивированные злоумышленники всегда просматривают файлы *.CSS, чтобы ознакомиться с функциями приложения, даже не входя в систему.

Например: Джим - целеустремленный злоумышленник и всегда пытается заглянуть в CSS-файлы из View-Source даже перед другими атаками. Когда Джим просматривает файл CSS, он видит, что существуют разные функции и разные роли, основанные на селекторах CSS, таких как .profileSettings, .editUser, .addUser, .deleteUser и так далее. Джим может использовать CSS для сбора информации, чтобы помочь получить доступ к конфиденциальным ролям. Это одна из форм должной осмотрительности злоумышленника еще до того, как он попытается выполнить опасные атаки для получения доступа к веб-приложению.

В двух словах, использование глобального стиля может привести к раскрытию конфиденциальной информации, которая может быть полезна злоумышленнику.

Риск #2

Допустим, у Сантоша есть привычка писать описательные имена селекторов, такие как .profileSettings, exportUserData, .changePassword, .oldPassword, .newPassword, .confirmNewPassword и т.д. Хорошие программисты любят, чтобы код оставался читаемым и пригодным для использования другими рецензентами команды. Риск заключается в том, что злоумышленники могут сопоставить эти средства выбора с реальными функциями веб-приложения.

Защитные механизмы для смягчения мотивации нападающего

Защитный механизм #1

Как CSS-кодер / программист, всегда разделяйте CSS по уровню контроля доступа. Это означает, что у Студента будет другой CSS-файл с именем Student Styling.CSS, в то время как у Администратора файл AdministratorStyling.CSS и так далее. Убедитесь, что доступ к этим файлам *.CSS доступен только для пользователя с соответствующим уровнем контроля доступа. Только пользователи с соответствующим уровнем контроля доступа должны иметь доступ к своему файлу *.CSS.

Если аутентифицированный пользователь с ролью Студент попытается получить доступ к AdministratorStyling.CSS с помощью принудительного просмотра, должно быть записано предупреждение о вторжении.

Защитный механизм #2

Другой вариант - изменить ваши CSS-файлы, чтобы удалить любую идентифицирующую информацию. Как правило, рекомендуется, чтобы стиль вашего веб-сайта был согласован между страницами, и лучше всего прописать общие правила CSS таким образом, чтобы они применялись на нескольких страницах. Это, в первую очередь, уменьшает необходимость в специальных селекторах. Кроме того, часто можно создавать CSS-селекторы, нацеленные на определенные HTML-элементы, без использования идентификаторов или имен классов. Например, #UserPage .Toolbar .addUserButton можно было бы переписать на что-то более непонятное, например #page_u header button:first-of-type.

Также существуют инструменты для сборки и выполнения, которые могут быть интегрированы для маскировки имен ваших классов. Это может снизить вероятность того, что злоумышленник угадает функции вашего приложения. Несколько примеров:

  • JSS (CSS в JS) имеет опцию minify, которая генерирует имена классов, такие как .c001, .c002.
  • CSS модули имеют опции modules и localIdentName, которые функционируют аналогично JSS, но позволяют импортировать любой CSS-файл без серьезных структурных изменений в вашем приложении.
  • .Net Blazor CSS Isolation может использоваться для привязки вашего CSS к компоненту, в котором он используется, и приводит к появлению таких селекторов, как button.add[b-3xxtam6d07].
  • Библиотеки CSS, такие как Bootstrap и Tailwind, могут уменьшить необходимость в специальных CSS-селекторах, поскольку они обеспечивают надежную базовую тему для работы.

Защитный механизм #3

Веб-приложения, которые позволяют пользователям создавать контент с помощью HTML-ввода, могут быть уязвимы для вредоносного использования CSS. Загруженный HTML-код может содержать стили, разрешенные веб-приложением, но может использоваться не по назначению, что может привести к угрозам безопасности.

Пример: Вы можете прочитать о том, как LinkedIn имел уязвимость, которая позволяла злоумышленникам использовать CSS для выполнения атаки перехвата кликов. Это привело к тому, что документ перешел в состояние, при котором нажатие в любом месте страницы привело бы к загрузке потенциально вредоносного веб-сайта. Вы можете прочитать больше о том, как предотвратить атаки с перехватом кликов здесь.