UI欺骗攻击的另一种形式是攻击者修改数据，使其表现为与实际不相符的其他内容，然后将其展示给用户。经过修改的URL和文件名特别容易令人产生混淆。伪造URL和文件名的几种方法包括同形异义字攻击（homograph attacks）、URL重定向攻击（URL redirection）和username@URL语法攻击。
同形异义字攻击
如果单击链接[url]http://www.microsoft.com[/url]，你期望看到哪个Web站点呢？你或许期望看到微软的官方Web站点，但是你将无法实现这个愿望。Evgeniy Gabrilovich和Alex Gontmakher注册了域名mi?ros?ft.com，使用俄语的西里尔字母（Russian Cyrillic）表示‘c’和‘o’。尽管这些字符看起来与拉丁文的‘c’和‘o’相似，但是它们并不一样，含有Cyrillic字符的URL会引领你访问与预期完全不同的网站。
更多信息：关于同形异义字攻击的更多信息，可以访问Gabrilovich和Gontmakher撰写的题为“The Homograph Attack”的文章，在[url]http://www.cs.technion.ac.il/~gabr[/url] /papers/homograph_full.pdf可以查阅到。
把合法站点的URL与经过同形异义字处理后的URL区别开是非常困难的。如果URL含有类似Russian Cyrilic字符的Unicode字符，有些程序，比如FireFox，会显示与当前URL相当的Punycode 版本。与Microsoft.com相似的Punycode版本是[url]http://www.xn--mirsft-yqfbx.com[/url]。
！提示：Punycode在RFC 3492中被定义为“一种简单高效的转换编码语法，被设计用来与应用程序域名的国际化（Internationalized Domain Names in Applications ，IDNA）一起使用。它可以唯一地、可逆地把Unicode字符串转换为ASCII字符串。Unicode字符串中的ASCII字符会被逐个字符地表示，并且非ASCII字符会通过主机名标签中允许出现的ASCII字符（字母、数字和连字符）来表示”。
当对使用同形异义字处理后的URL进行测试时，观察目标应用程序的行为表现是非常有用的。通常，通过以Punycode的方式向用户显示那些可能被同形异义字处理的URL对应用程序而言是非常有帮助的。
！提示：有时程序员调用SHGetFileInfo函数（Shell32.dll的一个函数）来判断应该如何给用户显示文件名。如果使用SHGFI_DISPLAYNAME标记，并且激活隐藏已知文件类型的目录选项，那么API函数将推荐把诸如test.txt.bat的文件名简单地显示为text.txt。默认情况下，隐藏已知文件类型是被激活的。这样一来，如果程序员更改了机器的这项设置，他们也许相信SHGetFileInfo会返回完整的文件名。为了发现类似的问题，你可以查看引用SHGetFileInfo的源代码，或者在激活隐藏已知文件类型的选项的情况下，你可以使用诸如text.txt.bat的文件名进行测试，以查看是否显示text.txt。
URL重定向攻击
当你在浏览器中输入[url]http://www.fourthcoffee.com[/url]时，期望看到哪个Web页面呢？你也许期望看到与咖啡相关的Web站点。但是，你注意到浏览器地址栏中显示的却是[url]http://www.microsoft.com[/url]。这是如何发生的呢？这被称为URL重定向。当你请求第一个URL时，服务器返回的HTTP响应码是302，这将告诉浏览器加载另一个不同的URL，在本例中是[url]http://www.microsoft.com[/url]。
用户本来不希望在某个特定域中加载某个URL，但是如果执行了HTTP重定向，也许会在其不知情的情况就加载了该URL。受害者往往更倾向于信任一个认识的或者众所周知的URL。通常知名的Web站点页面会通过查询字符串接受一个URL，然后重定向到它。例如：[url]http://www.msn.com/redir.asp?URL=http://www.example.com[/url]。
重要提示：某些允许任意重定向的知名站点的页面通常会被用来实施钓鱼攻击。如果你所测试的Web应用程序允许攻击者指定任意一个URL，并强迫HTTP重定向到该URL，你应该通知程序员删除此功能，或者对此功能进行限制。为了减少此问题导致的危害，Web程序员可以限制使用那些允许HTTP重定向的URL。
如果用户看到了长的URL的开始部分，也许认为将要访问MSN网站，但是其浏览器却被重定向至example.com网站。攻击者通过使用本章以及第12章“规范化问题”所讨论的其他技巧，进一步模糊处理重定向URL，可以产生更加逼真的欺骗效果。
重要提示：HTTP重定向对于测试第10章 “HTML脚本攻击”中的跨域（cross-domain）和区域问题也是非常重要的。许多读取URL的API函数都会在不提示调用者的情况下直接进行重定向。正是因为这个原因，程序可能认为它正在接收来自某个域的数据，而实际上它却接收了来自另一个域的数据。
许多程序询问用户是否想从某个特定的URL加载Web页面。通常，程序仅针对原始URL提示用户，但是如果执行了重定向操作，它将不会提示用户。
使用以下代码，对执行HTTP重定向操作的ASP（Active Server Pages）页面，可以创建一个测试用例：
<% Server.Redirect "http://www.example.com" %>。
重要提示：HTTP重定向不同于HTML meta标记的刷新机制以及HTML脚本重定向（使用客户端脚本改变浏览器的URL）。HTTP重定向是在协议层次上实现的，并且系统API都支持它。正是因为这个原因，应用程序通常不需要包含额外的代码（有时根本没有意识到）就可以实现HTTP重定向的行为。HTML meta标记刷新和HTML脚本重定向通常包含在HTML文件的内容中，而不是在协议层次上。在应用程序解析HTML的内容之后，才执行这些类型的重定向，并且它们需要应用程序支持刷新和脚本重定向。
重要提示：信任的Web站点允许通过攻击者提交的数据重定向至任意的URL，与此类似的情况是有些Web站点接受攻击者提交的数据并且把它作为某个HTML页面的源URL。当发生这种情况时，用户（受害者）很难认识到攻击者控制了其中的某个HTML页面。
Username@URL语法攻击
RFC 2396（[url]http://www.ietf.org/rfc/rfc2396.txt[/url]）定义了URL可以采用以下语法来包含一个用户名：<userinfo>@<host>:<port>。
该语法使攻击者可以在URL中的服务器名（host）前面插入任意文本。例如：[url]http://www.microsoft.com@www.example.com[/url]将访问[url]www.example.com[/url]，并且把[url]www.microsoft.com[/url]作为用户名。但是，因为[url]www.example.com[/url]不需要密码，这个URL的用户名部分将不会被用到。更多的模糊处理可以被应用于真实的服务器名，从而产生更加逼真的欺骗效果。例如，如果使用example.com的IP地址，该URL看起来可能是[url]http://www.microsoft.com@192.0.34.166[/url]或者 [url]http://www.microsoft.com@[/url] 3221234342（使用了第12章中讨论的无点IP地址）。这两个URL看起来好像是用户要访问微软的Web站点，但实际上访问的却是example.com。
许多攻击者使用这种语法欺骗他们的受害者。正是出于这个原因，Internet Explorer在安全更新MS04-04中，在默认情况下针对http和https禁用了该语法。如果你所测试的应用程序支持URL，应该考虑禁用这种语法，以防止类似攻击的发生。
本文节选自电子工业出版社2008年10月出版的《安全漏洞追踪》一书。
