xss过滤
原理:编码后台不认识,前端输出点认识能正常执行
输入<script>'.666,查看页面源码,<script>被干掉了
尝试大小写绕过,输入<ScRiPT>alert(111)</ScRIPT>,提交
弹出弹窗,说明后台只是对小写的script进行了过滤
xss绕过 关于htmlspecialchars()函数
htmlspecialchars()函数把预定义的字符转换为HTML实体,默认不会对'进行编码
查看页面源码
此函数对>做了处理,未对'做处理
输入以下内容,提交,点击,弹出弹窗,因为疏忽未对'做处理,所以'里的内容可以被执行
xss之href输出
输入javascript:alert(111),提交,查看页面源码,关于href未做防范措施
点击,执行了输入的内容
xss之js输出
输入内容,查看页面源码
输入x'</script><script>alert('123')</script>将此js代码中前面的变量和<script>闭合掉
当输出到前端的js的代码里面就会被执行
CSRF
基本概念:在csrf的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接)然后欺骗目标用户进行点击,用户一旦点击了这个请求,(在目标用户的电脑上面,以目标用户的身份提交了这个请求,这个请求可能是一个修改或一个删除或一个新增这么样的一个操作)整个攻击也就完成了。所以csrf攻击也被称为“on click”攻击。
与xss的区别:CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而xss是直接盗取到了用户的权限,然后实施破坏。
csrf(get)
输入用户名和密码,修改一下地址
查看burp抓包内容,get请求
GET /pk/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=12345678922&add=jilin&email=lucy%40pikachu.com&submit=submit
在提交的参数里面没有看到csrf的token,后台这个时候应该是没有做防csrf的一些措施的
攻击者修改后的完整的url,将地址改为shanxi(攻击者伪造的链接):http://127.0.0.1/pk/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=12345678922&add=shanxi&email=lucy%40pikachu.com&submit=submit
访问此链接,该用户的地址信息就被改为了shanxi
csrf(post)
登录
看一下数据包,请求是通过post方式提交的,所有的参数是在请求体里面去传输的,也就是说无法通过url来伪造这个请求
在burpsuite生成PoC
将jilin改为hangzhou,点击右下角test in browser
粘贴并进入
点击submit request,修改成功
csrf token
token是如何防止csrf的
csrf的主要问题是敏感操作的链接容易被伪造,那么如何让这个链接不容易被伪造?:
每次请求时,都在这个请求里面增加一个随机码(长度足够,需要够随机,不容易伪造),后台每次对这个随机码(即一个token值)进行验证
登录,修改一下地址
抓包,查看一下get请求
GET /pk/vul/csrf/csrftoken/token_get_edit.php?sex=girl&phonenum=12345678922&add=shanghai&email=lucy%40pikachu.com&token=50233647efa6b7c10a943428144&submit=submit HTTP/1.1
多出了一个token值 ,用来防止csrf(每次请求token都会发生变化)
SQL注入
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。 从而导致数据库受损(被脱裤、被删除、甚至整个服务器权限沦陷)
数字型注入(post)
想像后台操作逻辑:提交一个id到后端,后端返回了一个名称跟邮箱
$id=$_POST['id'] select 字段1,字段2, from 表名 where id = 1 or 1 = 1;
选择一个id,抓包
发送到repeater,修改id为如下内容
发送,用户全部显示在页面上,所以id=这里存在一个数字型的sql注入,我们可以通过自己拼接一些sql进去,然后让数据库来执行它,得到一些我们预期的结果
字符型注入(get)
$uname=$_GET['username'] select 字段1,字段2 from 表名 where username='$uname';
输入kobe' or 1=1#' 即username='kobe' or 1=1#'
提交
搜索型注入:
后台源码:like '%$name%'
like '%xxxxx%' or 1=1#%'
输入%xxxxx%' or 1=1#
总结:猜测后台的sql语句是怎么拼接的,猜测变量是用的数字型的还是字符型的还是搜索型的等等,变量的拼接类型是多种多样的,然后去构造闭合,只要能成功的把这个闭合构造出来,然后后端如果没有做处理的话,用拼接的方式,就可以成功的去进行相关的payload的测试
不管是啥型,总而言之,就是对SQL中的各种类型的输入进行闭合测试,构造合法SQL,欺骗后台执行
xx型注入:
源码:username=('$name')
=('xx') or 1=1 #')
输入xx') or 1=1 #
"insert/update"注入
insert
输入如下内容
提交,显示报错,说明我们提交的内容在后台参与了sql的一个拼接,导致了MySQL的一个语法报错
输入基于insert做的payload:xiaohong' or updatexml(1,concat(0x7e,database()),0) or '
提交,看到对应的报错
update
与insert一样
"delete"注入
基于delete下的报错:
1 or updatexml(1,concat(0x7e,database()),0)
输入留言,删除,查看burp抓的数据包,发送到repeater
1 or updatexml(1,concat(0x7e,database()),0) 将这一串payload放到burp里面去跑一下
我们的参数是在url里面提交的,是get型提交的,所以我们要对它做一个url的编码,这一整段不是一个完整的url,用burp里面自带的转化工具,把相关的关键字进行一个对应的编码
发送,在返回数据的最下面看一下报错信息,按照预期把数据库的名称返回回来了
"http header"注入
根据提示登录,后端对http头里面的数据进行了获取
把burp抓的包发送到repeater
user-agent内容改为',发送,最下面报了一个MySQL的一个语法错误,可以看出来这个地方是存在sql注入漏洞的
firefox' or updatexml(1,concat(0x7e,database()),0) or '