【声明】
1. 只是技术研究，没有攻击哪家公司之意 2. 本文不涉及漏洞公布，不影响以上公司的任何应用安全之相关事宜 3. 本人没兴趣炒作，举这三大公司为例表明本人认为它们是中国互相网企业当中的佼佼者，也容易被更多的人读懂 4. 如果您觉得我的文章影响了你的公司的某个方面，请以邮件的形式告知我，我将修改本文 5. 本文未经本人以书面形式同意，禁止其它网站转载，本文格式，诚请编辑修订，以增加可读性。
好，我们进入正题，在本人过去的经验及现实工作当中总结来看，解决XSS问题需要遵循的最基本的原则是：
1. 避免用户输入的脚本再次展示于客户端之时非设计预期的执行
2. 任何时候不应该改变用户的输入
3. 何时展示何时解决
【解释一下】对于上述原则不是本人编造的，而是业界的共识（未必是我们伟大祖国的业界共识，但这确实是业界的共识），以下将分别以例证的方式说明以上三条XSS解决方案的基本原则。今天就来个倒序吧，一个一个看：
【上述原则之3】 比较容易理解，许多公司已经解决了XSS问题，但是解决的不完整，或者说不完美,有后患，以实例来看以下：
步骤：
1) 打开www.soso.com
2) 输入字符串：159753125521<script>alert(“‘”)</script>
3) 打开资源文件，如下图：
图中的部分代码:
<script>var __kw = '159753125521%3A%3Cscript%3Ealert%28%22%27%22%29%3C%2Fscript%3E',__kw8 =encodeURIComponent("159753125521:<script>alert(\"'\")<\/script>")...
可以看出，代码片段中的编码(此处的编码是指：Encoding或者叫转义)从解决问题的原则角度来说，有点早，毕竟：变量__kw将在何时使用，何处使用，你可能在编码(此处的编码是指：写代码)的时候可以预料，但是随着时间的推移，可能会被其它的开发人员使用，使用的语法环境是否适合使用URL+Javascript编码(此处的编码是指：Encoding或者叫转义)就很难说了。
【上述原则之2】 我们提供的应用平台应该是这样的：
1. 允许用户输入任何值而不影响本应用的正常运行，也不改变输入的输入，至少不应该让用户感觉到你改变了用户的输入
2. 出于对应用设计的考虑，禁止用户输入特定的保留字符，对于此种情况，应用平台理应以友好的方式告知用户以提示用户不要输入不可以接受的字符，而不是直接改变用户的输入而用户觉得莫名其妙,比如淘宝网,打开淘宝首页，按以下步骤进行：
1) 打开www.taobao.com
2) 字符串：159753125521<script>alert(“‘”)</script>
3) 在淘宝的输入框里输入以上2)字符串（此类例子，我一般使用Google Chrome浏览，不同浏览器有可能在处理URL时有不同的方式），你也可以在Chrome里直接运行以下URL：
http://s.taobao.com/search?q=159753125521<script>alert("'")</script>
得到的结果是搜索框的搜索值变成了：159753125521 script alert( ) /script，截图如下：
其资源文件里也同样如此，截图如下：
以上表明，淘宝在处理XSS问题时，因为方法不当而改变了用户的输入。
【上述原则之1】 意思也不难理解，这个问题比较敏感，如果我举出一个例子似乎就意味着这地方有漏洞，有没有办法举出一个例子却是一个几乎不能被利用的漏洞呢？ 貌似有，步骤：
1） 打开www.baidu.com
2）输入字符串 <script>alert(“‘”)</script>//<!–159753159753
3）点击搜索，观察现象，细节我就不分析了，现象上看，貌似某处的被字符串 // 或者<!– 起了作用而导致后续代码被注释，我只是猜测啊，不负责的，仅供交流。
结果是这样的:
正确的提示页应该是：
相关内容：
各种吐槽：
葙守 (5级) 90后安全爱好者 2013-05-28 1楼
来看看！！
anlfi (1级) ??????????????????????????... 2013-05-28 2楼
昨天Freebuf 掉线是怎么回事
wp 重置了又木有 我还玩了一下
FB客服 (3级) FreebuF官方客服 2013-05-28
@anlfi 昨天晚上由于freebuf某SA误操作，修改了网站的文件宿主权限，导致wp-config.php文件无法读取，对此造成的不便表示道歉，经过管理团队的一番教育，该SA泪流满面表示痛改前非，深刻忏悔，并表示下次不会再犯同类错误。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-06-05
@FB客服 昨天发现我荣升为四级，今天早上一看，掉级了，哈哈哈，这系统好智能啊。
test 2013-05-28 3楼
该评论已被和谐，如有反对意见，请提出相应数据证明。 by FB客服
诚实弟 2013-05-28 4楼
估计被日了
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-28
@诚实弟 无论如何，咱们都不要说脏话或者攻击类的话，在我们GFW的环境下，你我都是在裸奔。互相尊重利大于弊。
dig my girl 2013-05-28 5楼
业务规模 和 不安全指数成正比.
除非从“头”开始就遵循安全标准。 否则这些技术上的弥补。 只能饮鸩止渴. 而且个人经验，lz说的这些“大头”。 没一家聘请了足够的“苦力”替他们扫地。很多重要业务上都存在很明显的问题。安全与否，那些底层的娃娃最了解。当然这也没法，天高皇帝远，况且还是“土皇帝”， 能做到这样也算庆幸了。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-28
@dig my girl 嗯，确实是这样，许多问题从一开始遵循安全标准并实施到开发流程当中当然是理想的。如果已经用老方法做了，补救的办法也不是没有，工作量之大可以想象，但是这个工作量的付出是必需必要且值得的。个人觉得“安全意识”是根本问题，许多公司注重问题的挖掘而往往忽略了解决方案的系统性研究，这是高层需要改变的观念问题，与员工技术水平无关，员工只能做老总觉得应该做的事儿。
global_hacker (3级) 2013-05-28 6楼
哈哈哈 不错 思路 是有的但是你说的不一定 存在 xss 这个要测试才知道了
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-28
@global_hacker 你可千万别以此钻研出个漏洞出来，与我无关呦！呵呵
robert 2013-05-29 7楼
这文章写的貌似有点太监了，看的不是特明白。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-29
@robert 嗯，我是假设您是一个企业的应用安全工作者（有人俗称甲方应用安全工程师），有一定XSS问题的发掘及解决经验的才容易理解。有问题可以讨论，我一有空会给你。
netbutless (1级) 2013-05-29 8楼
xss应该是在model而非view解决的事
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-29
@netbutless 不完全同意，XSS的问题应该在Model考虑，解决上是一定要在View层完成的，否则后患无穷的。我计划会写几篇系列文章来逐步阐述我个人观点，供参考。
kussa 2013-05-30
@netbutless 还真是要在view完成。咱不玩那虚头巴脑的，直接说我的看法：一来如果在model层做过滤或转义，有可能影响正常逻辑，这个是没必要的损失；二来从管理上，把规范设定成要求在view做转移，更容易定位问题和查找责任人，哪个页面出问题就找哪个view的维护者，特别是对存储型XSS的控制更是这样；三来，在view上做控制更容易把控制措施统一抽象，然后集成在框架中解决，对具体开发同学的依赖小，而在model中的话实现起来更容易五花八门，可能需要要求每个开发都要理解。
sabu 2013-05-30
@jiayzhan @kussa 赞同，不过如果真正过滤xss，何不自己建立安全框架，各业务统一调用？最佳实践是一方面，但是一定要强制开发在设计时就要有引入安全框架的概念。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-30
@kussa 嗯，需要统一的解决方案来供view层实现者调用。能遇到在解决方案方面的内行真是快事儿，呵呵呵
kussa 2013-05-30
@kussa @jiayzhan 额，楼上客气了，据我所知至少在阿里这些所谓的解决方案都是很成熟的，应届生干上个半年SDL支持也完全能达到这样的认识，所以我还真不敢说是内行。内行是能把这些认识去push到实践中的人，很多时候开会讨论包括开发在内都认可的东西，到了实践层面就多了很多麻烦，所以能够把安全解决方案和开发的习惯、流程、制度融在一起的才是高手，那要对问题有很深的认识才行，我就是个门外汉。而百度腾讯在这方面也丝毫不差。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-30
@kussa 呵呵，我没想说哪家公司做的不好，关于SDL的实施是个系统工程，细节问题较多，知识与知识运用就如牛郎星与织女星，相隔甚远。而硅谷的许多公司却用的极其成熟，但硅谷的那套拿到中国来，却难以被中高层接受,所以，国内的大企业在应用安全方面没有不合格的员工，只有不合格的体制。
Ecore (1级) 2013-05-29 9楼
1、验证用户输入，如长度限制、格式限制、字符白名单
2、设置正确的 content-type与编码，如 返回json格式数据的接口
3、在输出的时候做转义处理，使用白名单的机制做转义，像ESAPI的方式
4、对富文本可以考虑 anti-samy ,HTMLPurify
还有些特殊情况，特殊对待..
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-29
@Ecore 您好， 您所述的1、4是解决输入验证的，，2、3是解决XSS问题的。我之前有文章说到输入验证，输入验证可以解决许多潜在的安全攻击，但它不是解决XSS问题的终极解决方案。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-29 10楼
百度解决问题的速度真是快，也不知道谢我一下，不大度呀。呵呵
kussa 2013-05-30 11楼
这样的方式并非淘宝编码规范中的防XSS解决方案，应该是开发在修复漏洞时case by case的随意修复，不具备普遍性，所以用我认为这个来评论公司层面的解决方案并不合适。
另外根据我的感受，soso的研发和腾讯整体风格也有些不一样，所以我不负责任的认为用soso的case来在公司层面评论腾讯的解决方案也不太合适。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-30
@kussa @kussa 嗯，赞成您的观点，以点代面是不正确的，本文只是为举例而举例，举知名公司的例子容易被所有的人读懂，仅此而已。本文由于涉及到公司，所以声明：禁止转载，我也看了，除了本站，无其它网站转载。
kussa 2013-05-30
@jiayzhan 如果像你所说这样，建议举典型例子，比如淘宝商品、店铺、交易等页面的。腾讯的也最好选择个qq.com的，这样让大家看起来更加有代表性，也更加严谨。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-05-30
@kussa 如果这样会有法律问题，见谅。
kussa 2013-05-30
@jiayzhan 哈哈，有意思。
hackwz 2013-05-31 12楼
请问下大牛，sql注入能否也在view层进行控制？
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-06-01
@hackwz 不敢称牛。单纯考虑SQL注入问题，在数据访问层解决，只要我们使用绑定变量方式进行数据访问，基本不会导致SQL注入问题。如果一定要使用非绑定变量方式，你需要使用白名单方式固定可接受无风险的来自于用户输入的SQL语句子句。之所以说单纯考虑SQL注入问题是因为我有前文提到输入验证，通过输入验证可以一定程度上避免SQL注入攻击。在解决安全问题上，通常要考虑系统性风险，从而有选择的采取多个辅助措施，输入验证就是其中一种。
Dante (1级) archer & 讨厌复杂的东西 2013-05-31 13楼
这个文章应该有下文，感觉像太监一样。。。
意犹未尽。
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-06-01
@Dante 是的，目前是铺垫，关于XSS问题之所以数年来经久不衰，就是因为缺乏对她的系统性认识，没有从根本上了解她，后续关于XSS问题的博文可能比较晦涩能看懂却较难理解运用，但解决复杂问题本身就得对问题有深入理解，然后才可以简单解决。个人见解，如有冒昧见谅。
hackwz 2013-06-01 14楼
@jiayzhan 受益非浅，感谢前辈指点，希望能有更多精彩的文章！
jiayzhan (5级) 硅谷某知名IT企业中国区高级应用安全工程师 2013-06-02
@hackwz 真正技术文章从下篇文章开始，到目前为止说的都是理念多于技术。谢谢关注。