本文目录一览：
如何正确防御xss攻击
传统防御技术
2.1.1基于特征的防御
传统XSS防御多采用特征匹配方式，在所有提交的信息中都进行匹配检查。对于这种类型的XSS攻击，采用的模式匹配方法一般会需要对“javascript”这个关键字进行检索，一旦发现提交信息中包含“javascript”，就认定为XSS攻击。
2.1.2 基于代码修改的防御
和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种方法就是从Web应用开发的角度来避免：
1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。
2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag(没有javascript)，去掉任何对远程内容的引用(尤其是样式表和javascript)，使用HTTP only的cookie。
当然，如上方法将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。
并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。
扩展资料：
XSS攻击的危害包括
1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
受攻击事件
新浪微博XSS受攻击事件
2011年6月28日晚，新浪微博出现了一次比较大的XSS攻击事件。
大量用户自动发送诸如：
“郭美美事件的一些未注意到的细节”，“建党大业中穿帮地方”，“让女人心动的100句诗歌”，“这是传说中的神仙眷侣啊”等等微博和私信，并自动关注一位名为hellosamy的用户。
事件的经过线索如下：
20:14，开始有大量带V的认证用户中招转发蠕虫
20:30，某网站中的病毒页面无法访问
20:32，新浪微博中hellosamy用户无法访问
21:02，新浪漏洞修补完毕
百度贴吧xss攻击事件
2014年3月9晚，六安吧等几十个贴吧出现点击推广贴会自动转发等。并且吧友所关注的每个关注的贴吧都会转一遍，病毒循环发帖。并且导致吧务人员，和吧友被封禁。
参考资料：
XSS攻击-百度百科
XSS攻击的背景知识
1.1 什么是XSS攻击
XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型的漏洞由于被黑客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而JavaScript是新型的“ShellCode”。
数据来源：2007 OWASP Top 10的MITRE数据
注：OWASP是世界上最知名的Web安全与数据库安全研究组织
在2007年OWASP所统计的所有安全威胁中，跨站脚本攻击占到了22%，高居所有Web威胁之首。
XSS攻击的危害包括
1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
3、盗窃企业重要的具有商业价值的资料
4、非法转账
5、强制发送电子邮件
6、网站挂马
7、控制受害者机器向其它网站发起攻击
1.2 XSS漏洞的分类
XSS漏洞按照攻击利用手法的不同，有以下三种类型：
类型A，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。其攻击过程如下所示：
Alice给Bob发送一个恶意构造了Web的URL。
Bob点击并查看了这个URL。
恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。
具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。
Alice的恶意脚本可以在Bob的电脑上执行Bob所持有的权限下的命令。
类型B，反射式漏洞，这种漏洞和类型A有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。其攻击过程如下：
Alice经常浏览某个网站，此网站为Bob所拥有。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息(比如银行帐户信息)。
Charly发现Bob的站点包含反射性的XSS漏洞。
Charly编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice。
Alice在登录到Bob的站点后，浏览Charly提供的URL。
嵌入到URL中的恶意脚本在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。
类型C，存储式漏洞，该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。其攻击过程如下：
Bob拥有一个Web站点，该站点允许用户发布信息/浏览已发布的信息。
Charly注意到Bob的站点具有类型C的XSS漏洞。
Charly发布一个热点信息，吸引其它用户纷纷阅读。
Bob或者是任何的其他人如Alice浏览该信息，其会话cookies或者其它信息将被Charly盗走。
类型A直接威胁用户个体，而类型B和类型C所威胁的对象都是企业级Web应用。
浏览器为什么要设计同源策略
没有同源（同协议、同域名、同端口）策略，就天下大乱了。
如果没有同源策略，不同源的数据和资源（如HTTP头、Cookie、DOM、localStorage等）就能相互随意访问，根本没有隐私和安全可言。为了安全起见和资源的有效管理，浏览器当然要采用这种策略。
至于题主说的最后一个“绕开”，我没能理解是什么意思，大概是对同源的概念理解不透彻。
推荐看看cos的《Web前端黑客技术揭秘》，非常系统的解析了前端安全知识，这些知识都是要围绕着同源策略展开的，可想而知它是有多重要。
ajax 为什么需要 同源策略
如果把“需要”替换为“遵守”可能更好一些。
同源策略的本质是一种约定，可以说web的行为就是构建在这种约定之上的。就好比我们人类的行为必须受到法律的约束一样。同源策略的目的就是限制不同源的document或者脚本之间的相互访问，以免造成干扰和混乱。
ajax太灵活了，各种请求说法就发，如果没有同源策略的限制，发到哪里都行，只要你构造好参数和请求路径，那人人都是黑客了，这样会导致各种敏感数据的泄露。
另外呢，那些带src属性的scriptimgiframelink等标签是不需要遵守同源策略的，但是通过src加载的资源，浏览器限制了javascript的权限，不能进行各种的读写。从而，即使请求发了，敏感数据回来了，也是取不到的。
通过上对比，带有src的标签不被同源策略限制，因为javascript本身就做了读写的限制，而ajax本身就是js的，太灵活了，javascript读写方便，所以它必须遵守同源策略。
最后再补充一点，如果ajax非要跨越，可以使用cors。你可以百度“cors 跨域”来学习一下。