Web应用客户端木马战情景分析

核心提示： 当某人浏览我们的站点时，我们通常为用户生成一个web页面，Web应用客户端木马战情景分析(6)，其中包括一些提示用户可在本站点进行哪些活动的URLs和表单(下文将以“要约”这个词来加以指代)，客户端木马战之所以得逞，那么该字符串将被存为“delnote-

当某人浏览我们的站点时，我们通常为用户生成一个web页面，其中包括一些提示用户可在本站点进行哪些活动的URLs和表单(下文将以“要约”这个词来加以指代)。客户端木马战之所以得逞，就是因为攻击者有可能以我们的名义向被害者提供这些URLs和表单，这是问题的根本所在。为了消除这种威胁，我们必须保证用户是根据我们而绝非其他人所提供的URL和表单来采取行动的。

许多开发人员都认为Referer header是一个用来确保访问者来自我们的站点的法宝。一般情况下，Referer header不该用于安全，因为它毕竟来自于客户端：记住，客户端总能造假。但是，用它来对付客户端特洛伊木马还是管用的——但是，处于保护隐私的考虑，站点经常将Referer headers过滤掉，因此在完全合法的请求中，通常是找不到Referer headers的，所以我们必须寻找一个不用检测Referer headers的办法。

还有一个办法，就是每当用户执行修改某些东西的动作时，都对用户进行重新认证。这种解决方案需要对客户端提供的每个表单都增加一个口令字段。不幸的是，提供口令是一件非常烦人的事情，所以我们将尝试其它方案。

三、防御措施

为了预防客户端木马攻击，开发人员应该实现一个“检票系统”。这个系统的核心在于一些不可预测的随机数，我们称之为票据，它的工作机制如下所示：

web页面通常用一个或多个要约来完成一个有副作用的动作。对于每个这样的要约，都会为其生成一个随机字符串并与该要约相关联：如果该要约是一个表单的话，可以用一个隐藏的字段来存放该票据;如果该要约是一个链接，那么可以把票据附加到URL参数列表中。

对于产生的每一个票据，都为其添加一个字符串来为其所指动作命名，并将这个字符串存放于接收该要约的用户的session的“票据池”中。例如，对编号为1234的单据的删除进行确认这一动作，动作名为“delnote-1234”，其票据被表示为“c90624gHu”，那么该字符串将被存为“delnote-1234-c90624gHu”。如今，我们在客户端和服务器端都有了一个相同的票据。