XSS攻击，通常指黑客通过“html注入” 篡改了网页，插入了恶意的脚本，从而在用户浏览网页的时候，控制用户浏览器的一种攻击。其原理是攻击者向有XSS漏洞的网站中输入(传入)一段恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。
l XSS攻击的生效方式（按危害大小排序）：
1）构造URL
XSS攻击者通过构造URL的方式构造了一个有问题的页面；当其他人点击了此页面后，会发现页面出错，或者被暗中执行了某些js脚本，这时，攻击行为才真正生效。
一般来说，动态页面中会将url中的部分内容回写在页面中。以百度的搜索为例：
http://www.baidu.com/s?wd=<script>alert("wrong")<%2Fscript>
参数<script>alert("wrong")<%2Fscript>是<script>alert("wrong")</script>转义后的结果，搜索结果页中，会在标题中中和搜索框中回写用户输入的内容。从页面的源代码中，我们看到，这两处本应该显示用户输入内容<script>alert("wrong")</script>的地方，实际也经过了转义处理，变成了<script>alert("wrong")</script>。如果这里没有经过转义处理，则页面中就嵌入了一段script，会执行，并弹出对话框提示用户。如果是其他恶意代码，则可能造成破坏。
然后攻击者将此URL广为传播——比如说，以报错的方式发给百度的管理员，管理员打开这个URL就中招了。
2）发布内容式
构造URL攻击方式传播范围有限，被攻击者只要有基本的安全意识就可以避免，因此这种手段的危险性比较小。相比之下，通过发表内容构造的XSS的危害就大了很多。
在可以发表内容的论坛、讨论区、吧、博客、微博等网站上，用户发表的内容会保存起来，允许其他用户浏览。这些保存的内容显示在页面上的时候，如果没有经过正确的处理，也会把攻击者精心构造的内容显示出来，访问该内容的用户就此中招。如果该页面流传广泛，则影响会更加深远。
一般来说，这种攻击都做得比较隐蔽，被攻击者并不知道自己什么时候踩中了地雷；网站也很难追查问题的来源。
3）蠕虫式
上述两种方式的流传范围都有一定限度；最彻底最暴力的方式是使用蠕虫——就是首先发一个有问题的文章，浏览者阅读时会被暗中执行恶意代码，发表一篇新的文章的，该文章也含有同样的恶意代码。这样有可能在最快时间内将攻击铺满整个网站。蠕虫式攻击将暗中偷偷摸摸的攻击行为变成了光明正大的攻城拔寨，极容易被发现和修复。
下面是6月28日新浪微博被蠕虫攻击的报告，其实质就是XSS攻击。
http://www.ijinshan.com/news/20110629001.shtml
l XSS攻击的防范方式：
防范XSS攻击的方式也十分简单：转义！但是你会面临两种抉择，是在入库前转义呢，还是在读取前转义呢？
这两种方式各有优劣，对于新手来说，一般会选择入库前转义，因为这种方法看起来可以一劳永逸，而且操作非常简单，只需要写一个filter或者interceptor拦截所有的写入请求，统一转义后交给controller处理入库即可。但是如果你的终端是多样化的，需要有多种展现形式的时候，这种方式就显得力不从心了。比如说你的终端要求以XML的形式显示数据，那么你就先得unescape回原始数据然后再按照xml的格式escape一次。假如终端要求更复杂的方式，转换起来就更复杂了。所以老手们慢慢会选择使用第二种方式。
我来终结一下这两种方式的优缺点：
转义方式 入库前转义
优点 一劳永逸
缺点 需要针对多端进行不同的输出，灵活性不足，无法应对后期数据格式的变化
转义方式 读取前转义
优点 简单，灵活，能应对各种数据格式的场景
缺点 需要对每个输出数据转义，人工处理容易遗漏
本人推荐第二种方式来防范xss攻击。虽然需要对每个输出数据都进行转义，但是如果你使用带自动转义的模版或者框架来处理的话，那么就可以极大的提高效率，又可以规避安全的问题。
下面介绍两种基础转义的方法：
1）使用Apache的commons-lang.jar
StringEscapeUtils.escapeHtml(str);// 汉字会转换成对应的ASCII码，空格不转换
2）自己实现转换，只转换部分字符
private static String htmlEncode(char c) {
switch(c) {
case '&':
return"&";
case '<':
return"<";
case '>':
return">";
case '"':
return""";
case ' ':
return" ";
default:
return c +"";
}
}
/** 对传入的字符串str进行Html encode转换*/
public static String htmlEncode(String str) {
if(str ==null || str.trim().equals("")) return str;
StringBuilder encodeStrBuilder = new StringBuilder();
for (int i = 0, len = str.length(); i < len; i++) {
encodeStrBuilder.append(htmlEncode(str.charAt(i)));
}
return encodeStrBuilder.toString();
}
l 另外介绍一种最常见的XSS攻击及其防范方法
最常见的XSS攻击就是通过读取浏览器的Cookie对象，从而发起“cookie劫持”，当前用户的登录凭证存储于服务器的session中，而在浏览器中是以cookie的形式进行存储的，cookie被劫持后，意味着攻击者可以不通过密码而直接登录系统。我们也可以直接在浏览器中输入脚本javascript:alert(document.cookie)来获取当前cookie值。
目前防止“cookie劫持”的方法大致有：a. 输入检查，使用filter来过滤敏感的关键字；b. 将cookie与用户ip地址进行绑定；c. 为cookie植入HttpOnly标识。
本系统采用的是第3种方式：为cookie植入HttpOnly标识。一旦这个HttpOnly被设置，你在浏览器的 document对象中就看不到Cookie了，而浏览器在浏览的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去(包括ajax的时 候)，应用程序也一般不会在js里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用js操作的cookie我们就不予设置，这样就保障了Cookie信息的安全也保证了应用。
具体代码实现：在web服务器tomcat的配置文件server.xml中添加：
<Context docBase="E:\tomcat\apache-tomcat-6.0.24/webapps/netcredit" path="/netcredit" reloadable="false" useHttpOnly="true"/>
或者在项目的web.xml 配置如下：
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>
浏览器cookie截图
PS：Cookie设置HttpOnly，Secure，Expire属性
http://blog.csdn.net/a19881029/article/details/27536917
---------------------
转载：https://blog.csdn.net/tanzhen1991910/article/details/52992726