经常上网的朋友会发现， 有时候有些链接点击进去后， 防病毒软件会报警， 提示有病毒/木马存在。 某银行科技处处长Y女士， 正在为这样的一起客户投诉头疼不已：某网银用户接到收到一封网银活动通知邮件， 点击后居然发现被防病毒软件报出存在木马。
在经过Y女士一番道歉后， 客户的怒气似乎消退了一些， 并表示可以把那封“肇事”邮件转发给Y女士。 这封邮件内容是银行这段时间正在搞的一个小调查活动， 点击“参加活动”按钮后， 防病毒软件马上发出病毒报警。 经专业安全公司专家分析后得知， 这是一封伪造的活动邮件， 骇客伪造了“参加活动”按钮后的URL链接， 用户点击后， 虽然会进入活动页面， 但同时也会被链接到一个恶意站点下载木马， 这就是防病毒软件报警的原因。 而能造成这种现象的原因是：该银行的网站页面编码存在缺陷。 考虑到银行的业务连续性要求， Y女士按照安全专家的建议购买了安全防护产品， 并迅速部署上线， 用以屏蔽此类攻击行为。
为什么网页链接会带有病毒呢， 这有如下几种可能： a)网站所有者故意在页面嵌入恶意代码：常见于私人小站。 为了牟取私利， 有些站长故意在网站页面中嵌入恶意代码， 以窃取访问者的信息。 一般来说， 企业用户不会存在这种情况。 b)骇客攻击网站获取权限后， 在正常页面中添加恶意代码， 这也就是常提到的XSS（跨站脚本）※攻击。
※注：XSS攻击？ XSS是一种经常出现在web应用中的计算机安全漏洞， 它允许恶意web用户将代码植入到提供给其它用户使用的页面中。 比如这些代码包括HTML代码和客户端脚本。 攻击者利用XSS漏洞旁路掉访问控制——例如同源策略（same origin policy）。 这种类型的漏洞由于被骇客用来编写危害性更大的phishing攻击而变得广为人知。 跨站脚本漏洞主要是由于没有对所有用户的输入进行有效的验证所造成的， 它影响所有的Web应用程序框架。
在实际表现中， XSS攻击会有两种常见的形态， 存储式攻击和反射式攻击。
存储式XSS：最常见的类型， 骇客将攻击脚本上传到Web服务器上， 使得所有访问该页面的用户都面临信息泄漏的可能， 其中也包括了Web服务器的管理员。 其攻击过程如下：
Bob拥有一个Web站点， 该站点允许用户发布信息/浏览已发布的信息。 Charly注意到Bob的站点具有XXS漏洞。 Charly发布一个热点信息， 吸引其它用户纷纷阅读。
Bob或者是任何的其他人如Alice浏览该信息， 其会话cookies或者其它信息将被Charly盗走。 反射式XSS：Web客户端使用Server端脚本生成页面为用户提供数据时， 如果未经验证的用户数据被包含在页面中而未经HTML实体编码， 客户端代码便能够注入到动态页面中。 其攻击过程如下： Alice经常浏览某个网站， 此网站为Bob所拥有。 Bob的站点运行Alice使用用户名/密码进行登录， 并存储敏感信息（比如银行帐户信息）。
Charly发现Bob的站点包含反射性的XSS漏洞。 Charly编写一个利用漏洞的URL， 并将其冒充为来自Bob的邮件发送给Alice。 Alice在登录到Bob的站点后， 浏览Charly提供的URL。 嵌入到URL中的恶意脚本在Alice的浏览器中执行， 就像它直接来自Bob的服务器一样。 此脚本盗窃敏感信息（授权、信用卡、帐号信息等）然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。 上面的例子中， Y女士所遭遇到的就是这种反射式的XSS攻击。
如何判断自己已经遭受XSS攻击呢？和其他常见攻击行为一样， XSS攻击在网上也有许多免费工具（sessionIE， Webscan， XSS Inject Scanner ）， 利用这些软件的骇客很有可能并不知道该如何清理自己留下的系统日志， 从对日志的分析中可以很容易的看到是否有XSS攻击行为发生。 还有一种更直接的方法就是检查页面源代码， 看是否有不相干URL等字符串出现， 如某页面源文件中存在与页面功能无关的代码， 就很有可能是发生了XSS攻击。
由于XSS攻击的直接受害者往往并不是网站所有者， 而是访问受攻击网站的普通用户， 所以， 经常会出现普通用户发现网站已经被骇客攻击， 而网站的管理人员仍一无所知的情况。 对于一些依靠网站开展业务的机构来说（如金融机构等）， 做好前期检查服务※， 是一项非常重要的工作。
※注：网站的检查服务 一般来说， XSS攻击的后果很难直接发现， 比如上面案例中如果骇客加入的攻击字符串不是网页木马， 而是窃取cookie信息的话， 用户在遭受攻击时将会完全没有表现症状， 这种威胁将更加的危险。 一种常用的方法是， 购买专业安全公司的网页挂马监测服务， 定期检查网站页面是否含有恶意代码。
XSS攻击发生后， 该如何应对呢？和大部分的Web威胁行为一样， XSS攻击发生原因是由于页面文件编写的不完备， 所以最直接和有效的方法就是代码级的页面文件修改。 但一般来说代码级修改需要较长的检查和修补时间， 同时可能会涉及到在线试运行验证效果， 所以在实际应用中较少采用。 采用的较多的是检测+防护+响应的手段（PDR模型※）。
※注：PDR模型：一提到检测、防护， 很多人就会想起安全界著名的PDR模型（防护Prevention、检测：Detection和响应：Response）， 在Web威胁防护中， 我们也采用了这一模型作为指导思想， 通过检测发现问题， 通过防护解决问题， 通过响应避免扩散问题。 通俗一些说， 就是利用网站安全检查服务， 找出网站是否存在以及在哪出现问题， 通过部署安全产品， 实时封堵针对漏洞的攻击行为， 通过应急响应等安全服务， 对出现了的安全问题进行及时响应。
……