如何保护网页按钮不被XSS自动点击

媒介

XSS 主动点按糯竽暌剐什愦伤害?

在社交收集里，很多操作都是经由过程点击按钮提议的，例如揭橥留言。假如留言体系有 XSS 马脚，用户中招后 XSS 除了进击之外，还能进行传播 —— 它能主动填入留言内容，并点击揭橥按钮，即可发出带有恶意代码的留言。石友看了中招后，又传播给他们的石友。。。大年夜而形成蠕虫扩散。

别的，经由过程第三方办事器揭橥是不算的。这里为简单，省略了登录态;真实场合下，会话 Cookie 是 HttpOnly 的，无法被 JS 获取到，也就无法让第三方办事器代替揭橥。

那么，有没有一种机制，让「揭橥留言」必须经由过程用户的「真实点击」按钮才能完成，而无法经由过程脚本主动实现?如许就能减缓蠕虫传播速度了。

实现

这个设法主意听起来似乎弗成行。如不雅揭橥留言须要带上用户行动信息，那么 XSS 完全可以捏造一份行动数据，后端根本无法辨认。

结尾

除非，用户在点击按钮时会产生一个「特别数据」，让后端校验它。

然则，XSS 也可以直接调用按钮元素的 click 办法，如许效不雅和用户点击仍然一样。后端仍无法辨认，是脚本点的，照样用户点的。

这么看来，我们只能保护好这个「按钮元素」，让它没法被 XSS 拜访到。例如，放在一个不合源的 iframe 里，如许就和 XSS 地点的情况隔离了!

不过，如许还不敷。假如 XSS 破解了这个「特别数据」的生陈规矩，那么即可本身捏造一个，然后直接调用 HTTP 接口揭橥留言。所以，我们得找一个弗成捏造的硬标识。

当然，安然防御有胜于无。并且该筹划的改革成本也不是很大年夜，后端只是增长一个 referer 断定罢了;前端也只需改革个别按钮，例如发帖按钮，像

事实上，有个很简单的办法：我们干脆让 HTTP 请求也经由过程 iframe 发送。如许，后端经由过程 referer 即可检测请求是否为 iframe 提议的。毕竟，XSS 是无法捏造 referer 的!

演示

Demo: http://www.etherdream.com/FunnyScript/anti-xssworm/

留意：这个案例不是看能不克不及注入 XSS，而是看能不克不及经由过程当前页面的 JS 主动发留言!

细节：