Всем 👋! Это Bagley
💬Логичным продолжением поста про XSS будет рассказ про CSP (как один из методов защиты от XSS).
💬Content Security Policy, или CSP (политика безопасности контента) - механизм, который помогает обеспечить безопасность веб-приложений путём управления источниками загрузки внешних ресурсов, таких как JavaScript, CSS, шрифты и изображения.
#️⃣CSP реализуется через заголовок HTTP-ответа, позволяя веб-приложениям определять, какие ресурсы могут быть загружены на их страницах. Это помогает не только от XSS-атак, но и от атак «нарушение данных» (Data Injection) и «внедрение кода» (Code Injection). CSP состоит из нескольких директив.
Content-Security-Policy: script-src 'self' https://example.com
❓ Эта запись означает, что загрузка скриптов разрешена с домена example.com и с самого себя (self)
✅ Эти скрипты подгрузятся и выполнятся:
❌ А вот эти уже не отработают:
alert(1);
click
#️⃣Вот еще несколько директив:
style-src: разрешенные источники для stylesheets
img-src: разрешенные источники для images
object-src: разрешенные источники для объектов (типа , )
connect-src: разрешенные источники для HTTP-запросов из скриптов (использование XMLHttpRequest, или fetch(), например)
default-src: дефолтное значение для тех директив, которые явно не указаны
frame-ancestors: источники, которым разрешено создание фреймов страницы ()
form-action: источники, разрешенные для отправки форм
➡️ (полный список тут)
#️⃣Вот некоторые значения директив:
*: разрешает любой URL, кроме data: blob: filesystem: schemes.
none: предотвращает загрузку ресурсов из любого источника.
self: позволяет загружать ресурсы из одного источника (с одинаковой схемой, хостом и портом).
*.example.com: позволяет загружать ресурсы из любого поддомена в example.com
unsafe-inline: позволяет использовать встроенные исходные элементы, такие как атрибут style, onclick или тела тегов script
unsafe-eval: позволяет выполнять небезопасный динамический код, например JavaScript eval()
➡️ (полный список тут)
#️⃣Рассмотрим некоторые примеры CSP, и способы bypass'a
Content-Security-Policy: default-src 'none'; img-src 'self'; style-src *; font-src *; script-src 'self' https://*.google.com;
💬 Этот CSP позволяет загружать изображения с самого сайта, шрифты и стили - откуда угодно, скрипты - с сайта или с любого поддомена google.com. Всё остальное улетает в значение 'none' из-за директивы default-src
Выглядит как-будто безопасно: скрипты с самого сайта или поддомена google.com. Сможем ли мы зарегать поддомен *.google.com - нет. НО, тут в игру вступает такая штука, как JSONP;
💬JSONP (JSON with Padding) - это метод, который позволяет без пробелам получать данные из разных источников, несмотря на Same-Origin Policy (SOP - которая запрещает одному домену делать AJAX-запросы к другому домену). Исследователь может внедрять вредоносный JavaScript в конечные точки JSONP через параметры GET («обратные вызовы»).
У accounts.google.com есть вот такой path, который принимает user-input (мы контролируем) параметр callback:
Что тут происходит? Браузер загружает ответ от Google. который формирует ответ:
alert(document.cookie);//({"result": "success"})
Браузер выполняет код. Вызывается alert(document.cookie), так как остальная часть отсекается // (комментарием)
➡️ (больше прикольных нагрузок ищем тут)
💬 Еще один момент касается script-src 'self'. Если self, значит безопасно - ошибка.
А вдруг у веб-приложения имеется возможность загрузки файлов? Например, обновление аватарки (которое еще не очень хорошо контролируется и обрабатывается)
Можно попробовать загрузить, что-то типа avatar.jpg.js, с JS кодом внутри, а после, использовать это в нагрузке:
❔ Основные посты канала
#learning
💬Логичным продолжением поста про XSS будет рассказ про CSP (как один из методов защиты от XSS).
💬Content Security Policy, или CSP (политика безопасности контента) - механизм, который помогает обеспечить безопасность веб-приложений путём управления источниками загрузки внешних ресурсов, таких как JavaScript, CSS, шрифты и изображения.
#️⃣CSP реализуется через заголовок HTTP-ответа, позволяя веб-приложениям определять, какие ресурсы могут быть загружены на их страницах. Это помогает не только от XSS-атак, но и от атак «нарушение данных» (Data Injection) и «внедрение кода» (Code Injection). CSP состоит из нескольких директив.
Content-Security-Policy: script-src 'self' https://example.com
❓ Эта запись означает, что загрузка скриптов разрешена с домена example.com и с самого себя (self)
✅ Эти скрипты подгрузятся и выполнятся:
❌ А вот эти уже не отработают:
alert(1);
click
#️⃣Вот еще несколько директив:
style-src: разрешенные источники для stylesheets
img-src: разрешенные источники для images
object-src: разрешенные источники для объектов (типа , )
connect-src: разрешенные источники для HTTP-запросов из скриптов (использование XMLHttpRequest, или fetch(), например)
default-src: дефолтное значение для тех директив, которые явно не указаны
frame-ancestors: источники, которым разрешено создание фреймов страницы ()
form-action: источники, разрешенные для отправки форм
➡️ (полный список тут)
#️⃣Вот некоторые значения директив:
*: разрешает любой URL, кроме data: blob: filesystem: schemes.
none: предотвращает загрузку ресурсов из любого источника.
self: позволяет загружать ресурсы из одного источника (с одинаковой схемой, хостом и портом).
*.example.com: позволяет загружать ресурсы из любого поддомена в example.com
unsafe-inline: позволяет использовать встроенные исходные элементы, такие как атрибут style, onclick или тела тегов script
unsafe-eval: позволяет выполнять небезопасный динамический код, например JavaScript eval()
➡️ (полный список тут)
#️⃣Рассмотрим некоторые примеры CSP, и способы bypass'a
Content-Security-Policy: default-src 'none'; img-src 'self'; style-src *; font-src *; script-src 'self' https://*.google.com;
💬 Этот CSP позволяет загружать изображения с самого сайта, шрифты и стили - откуда угодно, скрипты - с сайта или с любого поддомена google.com. Всё остальное улетает в значение 'none' из-за директивы default-src
Выглядит как-будто безопасно: скрипты с самого сайта или поддомена google.com. Сможем ли мы зарегать поддомен *.google.com - нет. НО, тут в игру вступает такая штука, как JSONP;
💬JSONP (JSON with Padding) - это метод, который позволяет без пробелам получать данные из разных источников, несмотря на Same-Origin Policy (SOP - которая запрещает одному домену делать AJAX-запросы к другому домену). Исследователь может внедрять вредоносный JavaScript в конечные точки JSONP через параметры GET («обратные вызовы»).
У accounts.google.com есть вот такой path, который принимает user-input (мы контролируем) параметр callback:
Что тут происходит? Браузер загружает ответ от Google. который формирует ответ:
alert(document.cookie);//({"result": "success"})
Браузер выполняет код. Вызывается alert(document.cookie), так как остальная часть отсекается // (комментарием)
➡️ (больше прикольных нагрузок ищем тут)
💬 Еще один момент касается script-src 'self'. Если self, значит безопасно - ошибка.
А вдруг у веб-приложения имеется возможность загрузки файлов? Например, обновление аватарки (которое еще не очень хорошо контролируется и обрабатывается)
Можно попробовать загрузить, что-то типа avatar.jpg.js, с JS кодом внутри, а после, использовать это в нагрузке:
❔ Основные посты канала
#learning