因为存在很多页面，都是将富文本内容展示到网页上的，没有进行过滤（哪怕时至今日，仍然有不少页面），这样只要富文本中有注入脚本，基本就中招了。。。
结论：
只要最终能向页面输出可执行的脚本语句，那么就是有漏洞，XSS攻击都有可能发生。
而且，基本上xss漏洞是很广泛的，虽然攻击类型很被动，也需要大量时间分析，但胜在大量的网站上都存在（特别是那种长期不更新的）
再提一点。上述的介绍更多的是从造成的后果来看，但其实如果从攻击手动来看的话可以分为几大类型：反射型XSS攻击（直接通过URL注入，而且很多浏览器都自带防御），存储型XSS攻击（存储到DB后读取时注入），还有一个DOM-Based型。
上述示例中都是存储型，具体更多内容网上已经有很详细的资料，这里不再继续深入，放一张图巩固下。
如何预防XSS：
输入过滤，不信任用户的任何输入，过滤其中的“<”、“>”、“/”等可能导致脚本注入的特殊字符，
或者过滤“script”、“javascript”等脚本关键字，或者对输入数据的长度进行限制等等，还得考虑攻击者使用十六进制编码来输入脚本的方式。
输出进行编码，和输入过滤类似，不过是从输出上着手，数据输出到页面时，经过HtmlEncoder等工具编码，这样就不会存在直接输出可执行的脚本了
cookie设置http-only，这样用脚本就无法获取cookie了
（这样只有浏览器向Web服务器发起请求的时才会带上cookie字段，避免了XSS攻击利用JavaScript的document.cookie获取cookie）
Cookie防盗，尽可能地避免在Cookie中泄露隐私，如用户名、密码等；
或者，为了防止重放攻击，可以将Cookie和IP进行绑定，这样也可以阻止攻击者冒充正常用户的身份。
注意，特别是后台，一定不能信任前端的输入，需要过滤与校验
XSS与AJAX的关系
以上分析了XSS造成一些影响与问题，仍然发现：与AJAX关系不大，因为这些问题不管用不用AJAX都会发生。
看看这种情况，譬如上述的富文本注入中：
1. 某个接口采用AJAX交互
2. AJAX请求完后将对应富文本字段显示到了页面上-譬如innerHTML
但是，这真的与AJAX无关，这是前后端没有进行输入输出过滤而造成的后果。
所以，还是那句话：如果某个Web应用具备良好的安全性，那么再怎么用“不安全的AJAX”也削弱不了它的安全性，反之如果应用本身存在漏洞，不管用何种技术请求，它都是不安全的
SQL注入简介
sql注入展开将也是一门很大的学问，很早以前更是大行其道（当然，现在...），这里仅仅举几个最极端的示例。
前提是后台没有过滤前端的输入数据，否则根本无法生效
假设页面A中有一个登陆查询存在拙劣的sql注入漏洞，这样子的：（最极端，最傻的情况）
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <form action="login.jsp" method="post"> 请输入用户名与密码：<BR> <input type="text"> <input type="text"> <input type="submit" value="登陆"> </form>
在接收到登陆请求后，服务端的实际执行代码时是：
String sql = "SELECT * FROM users WHERE name = '" + name + "' AND password = '" + password + "'";
然而有攻击者分析出后台可能存在漏洞，尝试sql注入攻击，输入
name = ' or 1=1 password = anything
那么这样，后台接收到数据后，实际上查询的结果是
SELECT * FROM users WHERE name = ' ' or 1=1 AND password = 'anything'
故而，攻击者成功的绕过的用户名，利用后台漏洞登陆了。
当然了，像这类这么低级的漏洞，现象几乎已经不存在了，往往这类型漏洞需要仔细分析，耗时。（又或者是有内奸。。。）
SQL注入与AJAX的关系
额，从上述的示例中看不出和AJAX有什么关系。但是我们可以这样假设：
1. 有一个接口，接收AJAX post的数据
2. 数据中有一个字段 'name'，后台接收到后没有进行过滤，直接如上面的演示一样，执行sql语句了