Content Security Policy, для зла

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

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 до миллиона например (больше — займет много времени)

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

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

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

Автор: Chikey

Источник ^[4]