对于应用程序来说，它是无法区分上面的这些差别的。特别是第三种可能是非常危险的。有许多技术(和漏洞)可以隐藏一个链接的真实属性。链接可以嵌入电子邮件消息中，也可以出现在存心不良的Web站点，然后引诱用户浏览该站点，例如链接出现在位于其他主机上(其它Web 站点、HTML格式的电子邮件消息，等等)的内容中，并且指向应用程序的资源。如果用户单击了该链接，由于他已经通过了站点上Web 应用程序的认证，所以浏览器会发出一个GET请求给该Web 应用程序，同时将验证信息(包含会话id的cookie)一并发过去。这样会导致在Web 应用程序上执行一个有效操作——该操作可能不是该用户所想要的，例如一个引起在网络银行上进行转帐恶意的链接，等等。

　　如前所述，通过使用诸如img之类的标签，甚至不需要用户点击具体的链接能发动攻势。假设攻击者向用户发送了一封电子邮件，诱骗用户访问一个URL，而该URL则指向一个包含下列HTML内容(注意，内容已作精简)的页面：

　　[html][body]

　　...

　　(img src=”https://www.company.example/action” width=”0” height=”0”)

　　...

　　[/body][/html]

　　用时将[]换成<>

　　当浏览器显示该页面时，它也将设法显示这个指定宽度为0的图像，即该图像是不可见的——这会导致自动向站点中的Web 应用程序发送一个请求。要紧的是，浏览器不管该图像URL实际是否指向一个图片，只要src字段中规定了URL，会按照该地址触发一个请求。当然，这里有一个前提，那是浏览器没有禁止下载图像——实际上浏览器都配置成允许下载图像，因为禁用图像后大多数Web应用程序的可用性会大打折扣。与跨站请求伪造有关的HTML标签问题是总结如下：

　　页面中有许多标签会导致自动发出HTTP请求(img标签便是其中之一);

　　浏览器无法断定img标签所引用的资源到底是不是图像以及是否是有害的;

　　当加载图像时，根本不考虑所涉及的图像所在的位置，即表单和图像不必位于同一个主机上，甚至可以不再同一个域内。虽然这是一个非常便利的特性，但是却给应用程序的隔离制造的障碍。正是由于与Web 应用程序无关的HTML内容可以引用应用程序中的各种组件，以及浏览器可以自动为该应用程序构造一个有效的请求这两个事实才导致了这种攻击的出现。这意味着，正确的URL必须包含用户会话有关的信息，而攻击者却无法得知这些信息，因此不可能识别这样的URL。

　　对于集成了邮件/浏览器功能的工作平台，跨站请求伪造问题可能更为严重，因为，仅仅显示一封包含该图像的电子邮件会导致请求及有关浏览器cookie一起向Web应用程序发去。

　　另外，攻击者还可以对这些东西进行伪装，例如引用貌似合法的图像URLs，例如

　　(img src=”https://[attacker]/picture.gif” width=”0” height=”0”)

　　用时将()换成<>

　　这里，[attacker]是攻击者控制下的站点，并通过重定向机制将http://[attacker ]/picture. gif转向http://[thirdparty ]/action。

　　如果Web应用程序的会话信息完全靠浏览器来提供的话，那么这样的Web应用程序也都易于受到攻击，其中包括那些仅依赖于HTTP身份验证机制的那些应用程序，因为浏览器知道这些验证信息，并会在发送每个请求的时候自动附带这些验证信息。当然，这不包括基于表单的认证，它只发出一次，并且生成了有关会话信息的表单——当然，如果这样的信息像cookie那样进行简单的传递的话，这有回到了之前的情形。

　　三、跨站请求伪造情景分析

　　假如受害者已经登录到一个防火墙的Web管理应用程序上。我们知道，当用户登录时，Web应用会进行身份验证，通常是要求用户提供其用户名和密码，如果用户名和密码正确则会通过身份认证;随后，Web应用会在客户端存放一个小文本文件，即cookie来存放会话信息。

　　假设防火墙有一个基于Web的管理接口，我们称之为防火墙Web管理程序，其中具有一个这样功能或者说一个页面，即允许认证的用户通过规则编号删除指定的规则，或者通过输入“*”删除全部已配置的规则——这的确是一个非常危险的功能。该删除页面显示如下。假如该表单(我们已经对其进行了简化)引起一个GET请求，那么该请求将如下所示

　　https://[target]/fwmgt/delete?rule=1

　　(删除一号规则)

　　https://[target]/fwmgt/delete?rule=*

　　(删除全部规则)。

　　该范例是故意十分天真的，这是为了便于说明CSRF的危险性。删除防火墙规则的页面如下所示：

图2 防火墙管理页面