在PCI审核期间,审核员表示我们存在重大安全风险,因为
我个人认为这根本不是安全风险。图像css和javascript不是动态创建的,它们不包含我们后端的数据,我们的客户详细信息和机制。
javascript中的注释只是简单地解释了javascript文件中的方法。哪个读JS的人都可以找到。
如何显示“information leakage”?
javascript中的评论是否真的存在安全风险?
答案 0 :(得分:16)
根据审核的严格程度,下载图像等而无需身份验证可能会被视为安全风险(想想图表,图表,图表......)。
删除javascript中的注释就像混淆代码一样:它使得它变得更难,但仍然不是不可能理解正在发生的事情。 JavaScript应被视为仅增强 - 无论如何,所有安全性应该在服务器端(重复)。 让任何人了解JS所做的事情不应被视为风险。
答案 1 :(得分:15)
这取决于评论的内容。因为在没有人为干预的情况下,没有办法检查评论的内容以确定它们是否有风险,所以审核这个问题的最有效方法是在面向客户的源代码中声明所有评论都是有风险的。
以下是潜在风险评论的示例。
// 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();
}
另一个例子可能是,如果您包含源代码历史记录标头,有人可能会通过检查已修复的错误类型找到一些安全漏洞。至少,如果一个破解者知道哪些攻击媒介已被关闭,他或许可以更好地攻击他的攻击。</ p>
现在,所有这些示例都是不好的做法(评论和代码),防止它的最佳方法是通过代码审查和优秀的程序员。第一个例子特别糟糕,但是对你的团队成员的无辜警告,比如第二个例子,或者注释掉的调试代码,比如第三个例子,都是可能漏网的安全漏洞。
答案 2 :(得分:4)
如果他们存在安全风险,请不要进入,在生产环境中缩小您的JS,这将防止“信息泄露”并帮助(至少在某种程度上)保护您网站的信息。
关于安全风险,我认为JS评论根本不存在风险,每个网站内容(静态)都可以在没有认证的情况下下载。 (除非另有定义)
答案 3 :(得分:4)
如果它们只显示代码的工作原理,那就不行了。无论如何,任何有足够坚定的人都能找到答案。
也就是说,缩小JavaScript可能是一个好主意;不是因为安全性,而是因为它会缩短下载时间,从而使您的网站响应更快。
答案 4 :(得分:3)
JavaScript评论可以。取决于你的逻辑,但当然,因为它是公开可用的,你可以更好地了解你的代码的工作。
还有其他原因可以删除它,例如文件大小,以及结果下载大小。
诸如JSMin之类的工具可以帮助您删除评论并对代码进行粗略的混淆。