Есть такой специальный хедер для безопасности вебсайтов 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 очень ограничена но они скоро это исправят.
Автор: Chikey
