引入：
最近在tech audit别的团队的实现，发现他们代码中存在着一些XSS(跨站脚本攻击）的问题。回想以前我们团队的代码也被IBM的AppScan扫描出一些类似问题，基于很多人对于XSS没有非常清晰的了解，今天下午，我专门做了点小例子来详细阐述什么是XSS。
实践：
其实XSS，定义不重要，大家都知道，js能力很强大，所以我如果发一段恶意的js代码给受害者，在受害者的环境去中执行的话，就会得到许多不可估量的后果。从宏观上分，大概分2类，一类是来自内部的XSS攻击，一种是来自外部的XSS攻击。我们这文章主要讲解来自内部的XSS攻击。
其实来自内部的XSS攻击很容易理解，假设我是攻击者，A是受害者，那么我要攻击A，怎么办呢？
因为根据同源策略，我就算写一段javascript,这段JS是没有办法去操作A环境的，这种情况下，我没办法让A受到伤害，这时候我会这么做：
首先，我给A 发送一个恶意的Web URL,但是为了吸引B去点击，我可能在这个URL的表面放一些有吸引力的内容（比如美女图片等）
果不其然，A上当了，他点击并且查看了这个URL
而我给A的URL其实包含了一段javascript,而A并不知道这件事情。
因为我的JS无法直接操作A的机器，但是因为A点击了那个链接，于是这段JS 成功的在A的本地域执行。
因为JS在本地域有很大的权利，因此我可以做很多可怕的操作，大家都知道。
为了模拟上述操作，我们有如下的代码：
攻击者页面（假设是心怀不轨的我写的）：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<
html
>
<
head
>
<
meta
http-equiv
=
"Content-Type"
content
=
"text/html; charset=UTF-8"
>
<
title
>恶意脚本发送方页面demo</
title
>
</
head
>
<
body
>
<
form
action
=
"xss_victim1.jsp"
method
=
"post"
>
<
p
align
=
"center"
><
strong
>恶意脚本发送方页面demo </
strong
></
p
>
<
div
align
=
"center"
>
<
table
width
=
"270"
border
=
"0"
>
<
tr
>
<
td
width
=
"130"
><
strong
>输入一段脚本:</
strong
></
td
>
<
td
width
=
"120"
><
input
name
=
"input"
type
=
"text"
id
=
"input"
/></
td
>
</
tr
>
<
tr
>
<
td
width
=
"100"
>
<
input
name
=
"submit"
type
=
"submit"
value
=
"点击触发恶意脚本"
/>
</
td
>
</
tr
>
</
table
>
</
div
>
</
form
>
</
body
>
</
html
>
|
然后这个页面提交到受害者页面，假如我就让他打出我们刚输入的脚本：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<
html
>
<
head
>
<
meta
http-equiv
=
"Content-Type"
content
=
"text/html; charset=UTF-8"
>
<
title
>恶意脚本结果展示页面</
title
>
</
head
>
<
body
>
你输入的内容是： <%=request.getParameter("input") %>
</
body
>
</
html
>
|
现在我们来演示：
比如，我现在在一个恶意页面上有一个文本输入框，用户可以输入任何内容进去，如果是输入一般字符串，那么没问题，假设我们输入一段脚本（或者说这段脚本不是让用户输入的，而且是页面的背面我们拼凑上去的）：
这时候在受害者页面xss_victom1.jsp中就会运行这段js.当然了，我们这里是善意的，只是弹出一个alert对话框，如果恶意的话，你懂的。。。
我刚测试了，非常幸运的是，Chrome在XSS的安全防范方面做的非常好，如果我吧刚才的例子运行在Chrome浏览器中，在受害者页面会显示：
拒绝执行这段脚本
总结：
所以从这里可以看出，对于来自内部的xss攻击，其本质是吧有毒的东西（比如一段恶意js脚本）送到受害者内部，让其在内部影响受害者的系统。因为同源策略，我没办法直接侵犯，所以采取这种方式，打个不恰当的比方，我（入侵者）要侵略某国家（受害者），我没办法让我的炸弹（恶意代码）直接炸那个国家（受害者），因为他们防护措施（同源策略）太好了，怎么办呢？我先买通他们国家某个官员（比如色情图片的链接），然后让这个官员携带了我要放的炸弹（恶意脚本代码） ，然后这个官员很轻松的通过外交通道免按键入境，然后这个官员到达他国家之后引爆这个炸弹（脚本代码执行在受害者本地机器上）
