Pikachu 3

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 '