Во время recient аудита PCI аудитор сказал, что у нас были главные угрозы безопасности потому что
Лично я думаю, что это не угроза безопасности вообще. CSS изображений и JavaScript, где не динамично созданный и они не содержали данных по нашему бэкенду, нашим клиентским деталям и по механизмам.
Комментарии в рамках JavaScript просто объясняли, что сделали методы в файле JavaScript. Который любой, кто читает JS, возможно, узнал так или иначе.
Как это показывает "утечку информации"?
Являются комментарии в рамках JavaScript действительно угрозой безопасности?
В зависимости от того, насколько строгий аудит, загрузка изображений и т. Д. Без аутентификации МОЖЕТ рассматриваться как угроза безопасности (подумайте о схемах, диаграммах, графиках ...).
Удаление комментариев в javascript похоже на обфускацию кода: это немного усложняет задачу, но все же позволяет понять, что происходит. В любом случае JavaScript следует рассматривать только как улучшающий, вся ваша безопасность должна быть (продублирована) на стороне сервера. Когда кто-либо понимает, что делает JS, не следует рассматривать как риск .
Не вдаваясь в подробности, представляют ли они угрозу безопасности, минимизируйте свой JS в производственной среде, это предотвратит «утечку информации» и поможет (по крайней мере, некоторым образом) защитить информацию вашего сайта.
Что касается риска для безопасности, я не думаю, что комментарии JS представляют собой риск, любое содержимое веб-сайта (статическое) может быть загружено без аутентификации. (если не указано иное)
Нет, если они только покажут, как работает код. В любом случае это может выяснить любой достаточно решительный человек.
Тем не менее, вероятно, будет хорошей идеей минимизировать JavaScript; не из-за безопасности, а потому, что это сократит время загрузки и, следовательно, сделает ваш сайт более отзывчивым.
Это зависит от содержания комментария. Поскольку нет способа без вмешательства человека изучить содержание комментариев, чтобы определить, являются ли они рискованными, наиболее эффективный способ проверки - объявить все комментарии в исходном коде, обращенном к клиенту, рискованными.
Ниже приведены примеры потенциально рискованных комментариев.
// doesn't really authenticate, placeholder for when we implement it.
myServer.authenticate(user,pass);
или
// don't forget to include the length,
//the server complains if it gets NaN or undefined.
function send_stuff(stuff, length) {
...
}
или
function doSomething() {
querystring = ""
//querystring = "?TRACING_MODE=true&"
...
//print_server_trace();
}
Другой пример - если вы включите заголовок истории исходного кода, кто-то сможет найти слабые места в системе безопасности, изучив, какие ошибки были исправлены. По крайней мере, взломщик сможет лучше нацелить свои атаки, если будет знать, какие векторы атак уже закрыты.
Так или иначе, все эти примеры - плохая практика (и комментарии, и код), и лучший способ предотвратить это - наличие обзоров кода и хороших программистов. Первый пример особенно плох, но невинные предупреждения товарищам по команде, как во втором примере, или закомментированный отладочный код, как в третьем, - это те виды дыр в безопасности, которые могут проскользнуть сквозь сеть.
Комментарии JavaScript могут быть. зависит от вашей логики, но, безусловно, поскольку он общедоступен, вы придаете больше видимости работе вашего кода.
Есть и другие причины для удаления этого, например размер файла и, как следствие, размер загрузки.
Такие инструменты, как d JSMin , могут помочь вам удалить комментарии и выполнить грубую обфускацию кода.