Content Security Policy, для зла

от автора

Есть такой специальный хедер для безопасности вебсайтов CSP.

CSP ограничивает загрузку каких либо ресурсов если они не были пре-одобрены в хедере, то есть отличная защита от XSS. Атакующий не сможет загрузить сторонний скрипт, inline-скрипты тоже отключены…

На уровне браузера вы можете разрешить только конкретные урлы для загрузки а другие будут запрещены. Помимо пользы этот механизм может принести и вред — ведь факт блокировки и есть детекция! Осталось только придумать как ее применить.

function does_redirect(url, cb){ var allowed = url.split('?')[0]; var frame = document.getElementById('playground'); window.cb = cb; window.tm = setTimeout(function(){ window.cb(false); },3000); frame.src = 'data:text/html,<meta http-equiv="Content-Security-Policy" content="img-src '+allowed+';"><img src="'+url+'" onerror=parent.postMessage(1,"*") onload=parent.postMessage(2,"*")>' }

Мы можем узнать редиректит ли конкретный URL на другой, а в некоторых случаях даже посчитать конкретный URL путем брутофорса от 1 до миллиона например (больше — займет много времени)

Попробуйте демо страницу.

Самое крутое в этом баге что его невозможно «правильно» исправить. Он основан на детекции загрузился ли ресурс или нет, а задача CSP блокировать ресурс, что не дает ему загрузиться. Единственным решением я вижу «эмуляцию» onload события, можно попробывать редиректить на data:, URL как это сделали с похожим моим багом в XSS Auditor.

В данный момент никаких защит не введено, значит мы еще долгое время сможем детектить ID пользователя на многих ресурсах и является ли он пользователем SomeSite. Работает в Firefox, Safari и Chrome, поддержка в IE очень ограничена но они скоро это исправят.

ссылка на оригинал статьи http://habrahabr.ru/post/211370/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *