本文记录了在Pikachu靶场的打靶经历，涉及到Web安全中的SQL注入问题。文章通过示例代码展示了如何防范未正确处理的用户输入导致的安全风险，如SQL注入，同时提到了网络安全面试中可能遇到的相关知识点。
我们对“alert(‘123’ )”进行URL编码，结果为alert(%E2%80%98123%E2%80%99%20)
但是这样依旧不行，因为这些编码不会被正常解码。
1. 在xss过滤的输入框中输入代码:`<script>12..`提交后查看网页源代码，如下图：
2. 我们发现，我们输入的`<script>`字样并没有被输入在源代码中，也就是说，该字样被过滤了，
我们现在尝试用大小写去过滤：`<scRIpt>alert('123')</sCRIpt>`提交之后成功弹窗。查看源代码，scipt也确实输出来在了其中。
3. 尝试拼凑，发现依旧被过滤，而注释干扰也同样不成功，这说明有些干扰能绕过过滤而有些不能，这取决于该网站的过滤措施。过滤干扰的方法千奇百怪，这一节只是简单阐述了这三种。
#### 2x08 xss之htmlspecialchars
在完成此节的攻击前，我们先来了解一下htmlspecialchars()函数
htmlspecialchars()函数把预定义的字符转换为HTML实体。
预定义的字符是:
>
> &(和号)成为&
> “(双引号)成为”
> ‘(单引号)成为’
> <(小于)成为<
> ‘>’(大于)成为>
>
>
>
可用的引号类型:
>
> ENT\_ COMPAT -默认。仅编码双引号。
> ENT QUOTES -编码双引号和单引号。
> ENT NOQUOTES -不编码任何引号。
>
>
>
**语法：htmlspecialchars(string,flags,character-set,double\_encode)**
| 参数 | 描述 |
| --- | --- |
| string | 必需。规定要转换的字符串。 |
| flags | 可选。规定如何处理引号、无效的编码以及使用哪种文档类型。可用的引号类型： ENT\_COMPAT - 默认。仅编码双引号。 ENT\_QUOTES - 编码双引号和单引号。 ENT\_NOQUOTES - 不编码任何引号。 |
| character-set | 可选。一个规定了要使用的字符集的字符串。 |
| double\_encode | 可选。布尔值，规定了是否编码已存在的 HTML 实体。 |
提示：如需把特殊的 HTML 实体转换回字符，请使用 htmlspecialchars\_decode() 函数。
1. 我们还是先输入一段字符串去尝试一下123abc’“<>#$%，提交后查看网页源代码。
2. 我们发现，除了单引号外，其他的特殊字符都被进行了编码。所以我们输入`q' onclick='alert(123)'`第一个单引号是对前面进行闭合。输入后点击发现成功弹窗。
这是因为此处的htmlspecialchars()函数的第二个参数“可用的引号类型”并没有正确选择，若选择成“ENT QUOTES -编码双引号和单引号”情况应该会好很多。
#### 2x09 xss之href输出
1. 打开xss之herf输出，输入Javascript:alert(123)，不含有特殊字符。
2. 我们看一看网页源代码，如图
3. 发现我们的代码嵌入了源代码中，点击后会被执行，出现弹窗。
>
> 查资料得：在这里我们可以做出相应防范，只允许http,https，其次在进行htmlspecialchars处理。
>
>
>
#### 2x10 xss之js输出
1. 我们在网页内随便输入一些东西，然后进源代码里看一看，这里以abc为例。
2. 同样，我们尝试去构造闭合，输入`x'</script><script>alert('xss')</script>`，发现成功弹窗
### 3 CSRF
**CSRF(跨站请求伪造)概述**
Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
这里列举一个场景解释一下，希望能够帮助你理解。
场景需求：
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。先看下大白是如何修改自己的密码的：**登录—修改会员信息，提交请求—修改成功**。
所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。
但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】
于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做： 欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
* 对敏感信息的操作增加安全的token；
* 对敏感信息的操作增加安全的验证码；
* 对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。
#### 3x01 CSRF(get)
1. 先以Vince的身份登录网站
2. 登陆好后尝试修改个人信息，这里我们把住址改为“abc”
1. 查看Burp中抓到的数据包，数据为`GET /pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=abc&email=vince%40pikachu.com&submit=submit`
2. 我们发现，关键数据容易被修改，所以我们将其改为URL，并将地址修改为123，`http://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=123&email=vince%40pikachu.com&submit=submit`
将此URL发送给Vince，现在我们模拟Vince的操作，我们在浏览器中打开此链接，发现地址被修改为了123
3. 当然，如果此时Vince退出了登录，则点击链接后个人信息也不会被修改。这也验证了CSRF的两个条件：
1 网站对敏感信息的修改没有做限制，也没有token等元素存在(请求可以被伪造)
2 被攻击者在此网站为登陆状态
>
> 查资料后发现还有一点：确认凭证的有效期（这个问题会提高CSRF被利用的概率）虽然退出或者关闭了浏览器，但cookie仍然有效，或者session并没有过期，导致CSRF攻击变得简单。
>
>
>
#### 3x02 CSRF(post)
1. 与上一小节，我们先登录，并将地址修改为abc
2. 在Burp中进行抓包，因为此时为post请求，我们无法用URL去提交请求，所以我们应该用抓包信息修改后伪造一个表单
3. 在此数据包上右键，选择“Engagement tools”–“Generate CSRF PoC”，并修改地址为12345（表单）
4. 此处我们也可以修改表单后自己弄成url，但是这里就直接用Burp的工具了。点击“Test in browser”，点击“copy”
5. 将此网址发送给Vince，Vince点击后个人信息会被修改。
#### 3x03 CSRF Token
1. 我们依旧是先用Vince的身份登录，并且依旧是将其地址修改为“qwe”
2. 我们用Burp抓包，发现抓到的数据包中存在token,响应回来的数据包也存在token。
3. 因此，我们将此数据包发送至重放器，并将第2步中响应回来的token复制给此数据包，并将地址改为usa，发送。
4. 可以看到，Vince的地址被修改
>
> 在CSRF，我们发现在get请求提交的基础上增加了Token，当我们刷新页面时Token值会发生变化，这样也就完全防止了GRSF漏洞的产生。
>
>
>
>
> CSRF与XSS的区别
> CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS可以通过盗取cookie来直接获取用户权限来实施攻击。
>
>
>
### 4 SQL-Inject
在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。
一个严重的SQL注入漏洞，可能会直接导致一家公司破产！
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。 从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。
在构建代码时，一般会从如下几个方面的策略来防止SQL注入漏洞：
1.对传进SQL语句里面的变量进行过滤，不允许危险字符传入；
2.使用参数化（Parameterized Query 或 Parameterized Statement）；
3.还有就是,目前有很多ORM框架会自动使用参数化解决注入问题,但其也提供了"拼接"的方式,所以使用时需要慎重!
SQL Inject 漏洞攻击流程
**01：注入点探测**
自动方式：使用web漏洞扫描工具，自动进行注入点发现
手动方式：手工构造sql inject测试语句进行注入点发现
**02：信息收集**
通过注入点取期望得到的数据
（1） 环境信息：数据库类型，数据库版本，操作系统版本，用户信息等
（2）数据库信息：数据库名称，数据库表，表字段，字段内容，甚至加密的内容也可能会被破解
**03：获取权限**
获取操作系统权限：通过数据库执行shell，上传木马
常见的注入点类型
数字型：
user_ id= $id
字符型：
user. id= ‘$id’
搜索型：
text LIKE ‘%{$_ GET[‘search’]}%’"
#### 4x01 数字型注入（post）
1. 我们随便选择一个数字并提交，发现url中并没有传参，说明我们的请求是以表单的形式发送。
2. 我们可以看到，返回来的数据是由姓名和邮箱两部分组成，我们在Burp里面抓包，如图：
3. 我们将此数据包发送至Repeater模块，并在输入点构造payload：1 or 1=1，因为任何id取1=1都为真，所以这样会把所有信息都罗列出来
#### 4x02 字符型注入（get）
1. 我们随便输入一段字符，此处以“qwer”为例，发现我们的请求是在url中提交的，，而若我们以vince为例，发现正确返回了数据，而且仍是由姓名和邮箱两部分构成
2. 字符型注入，我们猜测sql语句如下：
select 字段1，字段2 from 表名 where username = ‘111’;
后台接收应该是：`$uname=$_GET['username']`
（其实这部分我看不懂，都是复制粘贴的）
与xss一样，我们要去构造合法闭合，前面的单引号我们也以单引号闭合，后面的单引号我们用#注释掉，所以我们输入的代码为`a' or 1=1#`
提交后发现所有的数据都列了出来：
#### 4x03 搜索型注入
1. 我们尝试输入a进行搜索，发现请在在url里发送，且返回了所有带a的用户
2. 由于提示为%%，所以我们猜测
select from 表名 where username like ’ %k% ';
我们依旧是尝试去构造闭合：
我们输入`abc%'or 1=1 #`，用%’去与前面的%‘构造闭合，而后面的内容用#注释掉
此时完整语句为：
select from 表名 where username like ’ %abc%'or 1=1 #% ';
输入后发现所有数据都被列出
由此发现，关键在于猜测后台是如何进行拼接的并尝试去构造闭合。
#### 4x04 xx型注入
1. 我们进入后端，访问\WWW\pikachu\vul\sqli\sqli\_x.php，其中代码如下：
if(isset($_GET[‘submit’]) && $_GET[‘name’]!=null){
//这里没有做任何处理，直接拼到select里面去了
最低0.47元/天 解锁文章
扫一扫
1101
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
