XSS研究1-来自内部的XSS***

引入：

最近在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在本地域有很大的权利，因此我可以做很多可怕的操作，大家都知道。

为了模拟上述操作，我们有如下的代码：

***者页面（假设是心怀不轨的我写的）：

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>








恶意脚本发送方页面demo 

  

    

      
输入一段脚本:
        

      
    

      

        
      
      
  
  

然后这个页面提交到受害者页面，假如我就让他打出我们刚输入的脚本：

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>







你输入的内容是： <%=request.getParameter("input") %>

现在我们来演示：

比如，我现在在一个恶意页面上有一个文本输入框，用户可以输入任何内容进去，如果是输入一般字符串，那么没问题，假设我们输入一段脚本（或者说这段脚本不是让用户输入的，而且是页面的背面我们拼凑上去的）：

这时候在受害者页面xss_victom1.jsp中就会运行这段js.当然了，我们这里是善意的，只是弹出一个alert对话框，如果恶意的话，你懂的。。。

我刚测试了，非常幸运的是，Chrome在XSS的安全防范方面做的非常好，如果我吧刚才的例子运行在Chrome浏览器中，在受害者页面会显示：

拒绝执行这段脚本

总结：

所以从这里可以看出，对于来自内部的xss***，其本质是吧有毒的东西（比如一段恶意js脚本）送到受害者内部，让其在内部影响受害者的系统。因为同源策略，我没办法直接侵犯，所以采取这种方式，打个不恰当的比方，我（***者）要侵略某国家（受害者），我没办法让我的×××（恶意代码）直接炸那个国家（受害者），因为他们防护措施（同源策略）太好了，怎么办呢？我先买通他们国家某个官员（比如×××的链接），然后让这个官员携带了我要放的×××（恶意脚本代码） ，然后这个官员很轻松的通过外交通道免按键入境，然后这个官员到达他国家之后引爆这个×××（脚本代码执行在受害者本地机器上）