发表时间：2009-09-21
最后修改：2009-10-19
一直对漏洞、骇客、攻击之类的东西没敢深入，甚至肤浅的了解都算不上。但做程序，安全问题却是头等大事。随着学习，自己以后肯定得要去深入、了解了。
关于 XSS 跨站攻击，断断续续看过些介绍，但却一直连基本概念都没搞懂——汗死！ 今天，终于看明白了，原来就是对 Html 内容的入侵，让浏览器去执行侵入的代码——不晓得是自己笨，还是网上的技术文章本身的问题——讲解好像是给作者自己看的，基本会省掉前提知识、基本概念，差不多要懂的人才看得懂——既然人家都懂了，干吗还要再看呢？写的东西不是给懂的人看的，而是给不懂的人看的。唉……咱技术人员的文学修养……
废话不说了，看不懂总比没得看要好。书归正传，总结一下自己的看法吧，权且当作学习笔记，也不敢期望不懂的人看得懂，呵呵。
XSS 概念的基本要点：
1、 入侵者通过 Web 程序的“漏洞”（一般是对用户输入的数据没有严格的检查过滤），输入特别构造的包含 Html 标签的文本，使得某 Web 脚本的 Html 输出中包含了不该有的“可执行”代码，如包含在<script>标签中的 javascript、标签中的可执行属性（onLoad、onerror 等各种事件、href="javascript:xxx”、src="提权脚本" 等）。
2、 当具有高级权限的用户请求这个 Web 脚本时，其输出的 Html 中就包含了非法代码，而这非法代码可能执行另一个安全相关的脚本——这个脚本需要该高级用户的权限。这样，就相当于该高级用户不知不觉地做了一件安全相关的事，比如给侵入者注册的帐户提权。
3、 侵入者用那个被提权的帐户，干提高权限之后可以干的任何事……
预防 XSS 攻击的观点：
1、 目前预防 XSS 攻击的一般措施是：对由外部输入的数据（如普通用户的可编辑数据、任何人都可构造的 URL 请求串、非只读的外部配置文件等）进行严格的检查过滤，使得只有符合规格的数据才会通过，被程序内部使用。 有些过滤函数采用排除大量非法关键字的方式来过滤外部数据，但这样预防存在问题，一是计算量大了，二是非法关键字可能会随着技术发展而增加。所以应该采取“合法才进入”的原则，而不是“非法则排除”的原则——非法的情况是不固定的，合法情况则是固定的。
2、 个人认为，XSS 攻击的本质，其实不应该是数据输入的问题。数据输入是千变万化的，不论是输入方式还是输入的数据本身。XSS 攻击之所以存在，是数据输出造成的！如此思考，我们会得到全新的程序设计思路：
a、 输出数据应该是什么样的？如果把输出数据不简单的等同于数据库里的相关条目，比如一个经过严格验证的“合法”的 URL 条目，那我们又应该如何来构造一条合法 URL 输出呢？明显地，这时就需要在程序设计阶段，考虑某些基本元素如何划分了。一条合法的 URL 可能就不是一条数据，而是由不同部分组成：比如脚本路径、脚本文件名、查询串里的 ID 值、其它某个名称/值对等。——这些都是可知的，也是可控的。这时数据表中就不是只设计一个“存储 URL”的字段，而是更细致的东西。
b、 因之而来的思考是，输入的数据应该是什么样的？用户输入的数据需要是一条完整的 URL 吗？——不需要，也不应该！因为不可能让用户输入完整的 URL，然后还要程序对 URL 进行分解以提取需要的子项数据。自然而然的做法是让用户直接提供 URL 中各个“子项”数据，而这些子项数据应该都已经是基本的元数据类型了。这样，就不需要对输入数据进行复杂的检查过滤了，只需要最基本也是很通用的验证即可。
——于是，XSS 被杜绝了！不存在 XSS 的攻击了。以静制动，以不变应万变。
不当之处，欢迎拍砖，我不是一个资深的程序人，简单思路仅供参考。
后记：
对于必须要 Html 代码输入的场合，比如在线编辑器提供的内容，就很难处理了，大概也只能用过滤的方式——还没想到更好的办法（除了限制标签的使用外）。呵呵
