假设有一个www.badjs.com
不受信任且可能包含错误脚本的 URL。
直观地说,到该 URL 的视图源导航不会执行任何脚本,因此它应该是安全的。它至少可以让我安全地检查源头。
但是直觉是在安全问题上得出结论的糟糕方法,所以我的问题是:
从 js 脚本注入的角度来看,查看源代码是一种安全的方式吗?
假设有一个www.badjs.com
不受信任且可能包含错误脚本的 URL。
直观地说,到该 URL 的视图源导航不会执行任何脚本,因此它应该是安全的。它至少可以让我安全地检查源头。
但是直觉是在安全问题上得出结论的糟糕方法,所以我的问题是:
从 js 脚本注入的角度来看,查看源代码是一种安全的方式吗?
view-source
是的,在模式下打开不受信任的网站是绝对安全的(在 Google Chrome 中) 。这里要注意的关键点是你应该在view-source
模式下“打开”页面,这意味着你不应该通过正常加载网页然后查看源代码来进行任何渲染。
谷歌浏览器中的一个例子是 view-source:http://www.badjs.com/
按照设计,谷歌浏览器会在模式下向服务器发起一个新的 GET 请求,并为客户端浏览器提供未呈现的网页版本view-source
。
您还可以为您的特定浏览器使用 No-Script 扩展程序或附加组件,以防止任何脚本攻击。
虽然它目前在 Chrome 上是安全的,但您不应该以此为基础进行未来的检查。事情随时可能发生变化,我还没有看到缺乏渲染是一个专门记录的功能。
如果您想查看代码,最好通过命令行工具(例如curl)下载页面并分析加载并保存在文件中的内容。这还具有轻松测试可能响应不同用户代理而提供的各种页面的附加价值。
虽然其他答案说它目前是安全的并没有错,但存在潜在的误解。你说你想用它来检查一个网站是否安全,所以想必你在查看源代码没有发现恶意内容后会正常加载页面。如果这是真的,那么您必须知道网站能够检测(或至少推断)您正在使用view-source:
. 至少在 Firefox 上,它不仅不使用缓存,导致它再次加载页面,而且不加载其他资源。如果站点看到有人使用常规浏览器用户代理连接但没有加载其他资源,他们可以推断用户正在检查源。自动化这种检测很简单,并且仅在资源与页面的所有其余部分一起加载的情况下才从资源中提供恶意 JavaScript。尽管该网站仍在向您提供恶意 JavaScript,但这会在您检查源代码时隐藏它的存在。
一个潜在的解决方案是使用 Inspect Element,它查看当前打开的页面并允许读取源代码。这更难检测(尽管并非不可能,因为 CSS 可以确定浏览器窗口的大小,当检查元素打开时,它会缩小特定的量)。Inspect Element更复杂,并且可能比 更容易被利用view-source:
,因此您必须在这种情况下应用威胁建模。