поскольку использование HTTP-заголовка Origin / X-Frame-Options не очень популярно, и я не думаю, что новый CSP в Firefox будет лучше (накладные расходы, усложнение и т. д.). Я хочу сделать предложение для нового JavaScript / Версия ECMA.
Но сначала я публикую идею, чтобы вы могли сказать, плоха ли она. Я называю это простым jsPolicy:
Каждый, кто использует JavaScript, поместил скрипты в свою html-голову. Так почему бы нам не использовать их, чтобы добавить туда наши политики для управления всеми последующими сценариями. пример:
<html>
<head>
<title>Example</title>
<script>
window.policy.inner = ["\nfunction foo(bar) {\n return bar;\n}\n", "foo(this);"];
</script>
</head>
<body>
<script>
function foo(bar) {
return bar;
}
</script>
<a href="#" onclick="foo(this);">Click Me</a>
<script>
alert('XSS');
</script>
</body>
</html>
Теперь браузер сравнивает ‹scripts>.innerHTML и onclick.value с теми, что указаны в политике, поэтому последний блок элемента скрипта не выполняется (игнорируется).
Конечно, дублировать весь встроенный код будет нецелесообразно, поэтому вместо этого мы используем контрольные суммы. пример:
crc32("\nfunction foo(bar) {\n return bar;\n}\n");
результаты "1077388790"
А теперь полный пример:
if (typeof window.policy != 'undefined') {
window.policy.inner = ["1077388790", "2501246156"];
window.policy.url = ["http://code.jquery.com/jquery*.js","http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"];
window.policy.relative = ["js/*.js"];
window.policy.report = ["api/xssreport.php"];
}
Браузеру нужно только сравнить, установлена ли контрольная сумма встроенного скрипта в policy.inner или если URL-адрес script.src соответствует policy.url.
Примечание. Идея policy.relative заключается в том, чтобы разрешать только локальные скрипты:
window.policy.url = false;
window.policy.relative = ["js/*.js"];
Примечание: policy.report должен быть почти таким же, как с CSP (отправляет заблокированные скрипты и URL-адреса в API):
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-unofficial-draft-20110315.html#violation-report-syntax
Важный:
- Политика не может быть установлена дважды (иначе выдается предупреждение) = константа
- Для размышления: политика может быть установлена только в голове (иначе выдается предупреждение)
- Политика используется только для проверки скриптов, которые являются частью исходного html-кода, а не тех, которые размещаются на лету. пример:
document.write('‹script src="http://code.jquery.com/jquery-1.5.2.min.js">‹/scr' + 'ipt>');
Вам не нужно определение policy.url для "http://code.jquery.com...", так как контрольная сумма policy.inner подтвердила полный исходный код скрипта. Это означает, что источник загружается, даже если для policy.url установлено значение false (да, это все еще безопасно!). Это гарантирует простоту использования политики. - если одна из политик отсутствует, ограничений нет. Это означает, что пустое значение policy.relative означает, что разрешены все локальные файлы. Это гарантирует обратную совместимость
- если для одной из политик установлено значение «false», использование не разрешено (по умолчанию — true). пример:
policy.inner = false;
Это запрещает любой встроенный скрипт - Политика игнорирует только запрещенные сценарии и выдает предупреждение на консоль (ошибка остановит выполнение разрешенных сценариев, а это не требуется)
Я думаю, что это сделало бы XSS невозможным, и вместо CSP он также избежал бы постоянного XSS (пока никто не перезаписывает политику), и его было бы намного проще обновлять.
Что вы думаете?
EDIT:
Вот пример, сделанный в Javascript:
http://www.programmierer-forum.de/php/js-policy-against-xss.php
Конечно, мы не можем контролировать выполнение скрипта, но он показывает, как он мог бы работать, если бы браузер, совместимый с jsPolicy, работал.
EDIT2:
Не думайте, что я говорю о кодировании небольшой функции javascript для обнаружения xss!! Моя идея jsPolicy должна стать частью нового движка JavaScript. Вы можете сравнить это с php-настройкой, помещенной в файл .htaccess. Вы не можете изменить этот параметр во время выполнения. Те же требования применяются к jsPolicy. Вы можете назвать это global setting.
jsPolicy вкратце:
Парсер HTML -> отправить скрипты в JavaScript Engine -> сравнить с jsPolicy -> разрешено?
А) да, выполнение через JavaScript Engine
B) нет, проигнорировать и отправить отчет веб-мастеру
EDIT3:
Ссылка на комментарий Майка это тоже возможная настройка:
window.policy.eval = false;
--><script>alert('xss')</script><!--или внутри входных данных с помощью" /><script>alert('xss')</script><input type="text" value=", результатом будет в любом случае абсолютно правильный внутренний скрипт. И это должно передать jsPolicy до того, как оно будет выполнено, поскольку jsPolicy является частью программного обеспечения браузера, где сценарий передается JSengine (это также покрывает ошибки парсера браузера html!). Коротко: парсер HTML -> обнаружен сценарий -> отправить в jsEngine -> jsPolicy -> выполнить, если он действителен - person mgutt schedule 30.04.2011policy.inner? - person Rudie schedule 30.04.2011alert('xss')(CRC32=3414049779) полностью отличается отalert('XSS')(CRC32=2462090537). Если crc32 недостаточно безопасен, мы можем использовать md5. - person mgutt schedule 30.04.2011