bWApp_play

 · 2020-5-7 · 次阅读


0x01、A1-Injuction(注入)

SQL injection (GET/Search)

1.low
加上’后直接报错:

Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%'' at line 1

那么sql语句就有可能是

SELECT * FROM movies WHERE title LIKE '%" . ($title) . "%'
上面的%是模糊,也可以说是匹配查询,注入的时候可以不用管它

这里闭合不需要使用%’的形式直接使用’闭合让前面的与%组成一个新参数,反正都不要紧的。
使用order by得到字段数量为7
接下来payload

123' union select 1,user(),3,database(),5,6,7 #

即可拿到user与database,low就做到着了,太基础了,其他查询类似。

2.medium

输入’后提示找不到,看样子引号被过滤了。猜测极有可能使用了addslashes函数转义了
因而考虑是否存在宽字节注入。测试1%df%27仍然no movies were found!因而,其编码不是GBK,所以不存在宽字节注入。
那么该怎么绕过呢,看一下服务器端代码吧:

function sqli_check_1($data)
{

    return addslashes($data);

}

可以看到的确使用了addslashes函数过滤。
再来看一下查询语句和low同样:

    $title = $_GET["title"];

    $sql = "SELECT * FROM movies WHERE title LIKE '%" . sqli($title) . "%'";

这里参考addslashes的过滤方式,
一:字符编码问题导致绕过

2.1、设置数据库字符为gbk导致宽字节注入
2.2、使用icon,mb_convert_encoding转换字符编码函数导致宽字节注入

二:编码解码导致的绕过

3.1、url解码导致绕过addslashes
3.2、base64解码导致绕过addslashes
3.3、json编码导致绕过addslashes

三:一些特殊情况导致的绕过

4.1、没有使用引号保护字符串,直接无视addslashes
4.2、使用了stripslashes
4.3、字符替换导致的绕过addslashes

很明显上面的都行不通,因为都不满足,因而BW的medium和high可能是无法绕过,作为防御机制。
addslashes返回在预定义字符(单引号,双引号,反斜杠,NULL)之前添加反斜杠的字符串。

3.high
同理high使用的是mysql_real_escape_string($data)
这个调用的实际也是addslashes函数,其在mysql未连接时会报错,但根据代码审计所说,其的确比addslashes更安全。
原因在于addslashes只针对字符串,而$_GET本身是个数组,因而某些情况也存在绕过机制。而mysql_real_escape_string可以根据当前字符集进行过滤,因而更安全。

当然最好的方式还是采用预编译的方式连接数据库,那么为什么预编译的数据库可以有效地防止SQL注入?

我们拿java的预编译来说,php同理:
PreparedStatement(java的预处理)会对SQL进行了预编译,在第一次执行SQL前数据库会进行分析、编译和优化,同时执行计划同样会被缓存起来,它允许数据库做参数化查询。在使用参数化查询的情况下,数据库不会将参数的内容视为SQL执行的一部分,而是作为一个字段的属性值来处理,这样就算参数中包含破环性语句(or ‘1=1’)也不会被执行。

也就是说用户输入的参数不会被拼接到SQL语句中然后被数据库解析执行导致SQL注入,而是在参数输入前,就已经进行过SQL预处理,也就是预查询。预编译的查询已经变成了参数化,也就是只会进行参数的查询(作为一个字段的属性值处理),而语句不会,这样就避免了SQL注入。

##HTML injection - Reflected(GET) ##

这个hack有两个输入框,low等级的把用户输入的直接就输出了。
因而测试

<script>alert('XSS')</script>

即可成功弹框,挖掘这类XSS漏洞,主要寻找输出函数,echo,print,fprint,printf等
然后注入的实质就是把用户输入的参数加载到服务器上并且执行了,因而成功注入。
所以在用户参数进入表单时必须对其进行充分的过滤,然后才允许其加载到服务器进行处理。
看一下靶机代码:

<?php
    if(isset($_GET["firstname"]) && isset($_GET["lastname"]))
    {   
        $firstname = $_GET["firstname"];
        $lastname = $_GET["lastname"];    

        if($firstname == "" or $lastname == "")
        {

            echo "<font color=\"red\">Please enter both fields...</font>";       

        }
        else            
        { 

            echo "Welcome " . xss($firstname) . " " . xss($lastname);   
        }

    }
    ?>

可以看到上面直接把get传入的firstname与lastname显示,导致alert函数执行。
然后看一下medium的

function xss_check_4($data)
{

    // addslashes - returns a string with backslashes before characters that need to be quoted in database queries etc.
    // These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).
    // Do NOT use this for XSS or HTML validations!!! 
    return addslashes($data);

}

又是addslashes。上次说到会对单引号,双引号,反斜杠,NULL自动转义加上
利用不了了。这里就很奇怪,因为没有被转义的东西
但使用Url编码即可绕过:

%3cscript%3ealert(%2fxss%2f)%3c%2fscript%3e

这里涉及到解析的顺序了,很明显Url的解码在过了addslashes后才解码,因而绕过了过滤。

HTML injection-Reflected(url)-low

刚开始没理解什么意思,只知道页面显示了当前的url:

1

我还准备插入XSS但是很快就失败了。这里应该是对url的一种处理。

抓包修改host: localhost ->host: 8.8.8.8

发现页面变成:

2

很明显这里获取url的方法采用了

全局变量$_SERVER[HTTP_HOST]

我们单独写一个php看一下这两个

$_SERVER[HTTP_HOST]和$_SERVER[REQUEST_URI]

3

可以看到这两个变量分别获取了网站的域名以及它的目录。

所以上面的current的代码也能猜到了应该是

echo '$_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"]'

那么这样会有什么危害呢?

大概会被伪造为localhost而未授权访问到某些东西吧,网上都没有说危害。以后再来深究。

看一下他的medium和high

HTML injection-Reflected(url)-medium

这次执行low同样的操作已经无法修改localhost为8然而其在cookie中设置了安全级改为0就又回到了low,这里就不做没有意义的事了。探究一下这里url的抓取方式。

使用ctrl+u查看源代码发现前端获取代码:case “2” :

    $url = "http://" . $_SERVER["HTTP_HOST"] . xss_check_3($_SERVER["REQUEST_URI"]);可以看到现在使用的是js直接获取url。

HTML injection-Reflected(url)-high

high直接查看源代码:

case "2" :

        $url = "http://" . $_SERVER["HTTP_HOST"] . xss_check_3($_SERVER["REQUEST_URI"]);
跟进xss_check_3:
    function xss_check_3($data, $encoding = "UTF-8")
{

    // htmlspecialchars - converts special characters to HTML entities    
    // '&' (ampersand) becomes '&amp;' 
    // '"' (double quote) becomes '&quot;' when ENT_NOQUOTES is not set
    // "'" (single quote) becomes '&#039;' (or &apos;) only when ENT_QUOTES is set
    // '<' (less than) becomes '&lt;'
    // '>' (greater than) becomes '&gt;'  

    return htmlspecialchars($data, ENT_QUOTES, $encoding);

}

其实就是把request_url部分进行了输出编码,这里注意第二个参数连单引号也转义了。

其实我明白了这个是说明什么了。有的时候服务器需要判断用户IP,而当没有对request_uri部分进行过滤那么极有可能可以采用X-F-F,client等绕过限制。

HTML Injection - Stored (Blog)-low

low的很简单最基本的XSS直接弹窗,直接看medium

HTML Injection - Stored (Blog)-medium

插入XSS:

4

很明显这里采用了htmlspecialchars进行过滤。

但查看源码发现使用的addslashes进行过滤

High采用的

return htmlspecialchars($data, ENT_QUOTES, $encoding);

但我总感觉按理说addslashes对于XSS应该是不能达到方法作用:

 // addslashes - returns a string with backslashes before characters that need to be quoted in database queries etc.
    // These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).
    // Do NOT use this for XSS or HTML validations!!!
在这个函数中也说明了这一点

仔细看代码发现这三个level最开始就是用了:

mysqli_real_escape_string

呃。。。这里不懂medium为啥大小括号被编码了。

iFrame injection

5

仔细查看复现ParamUrl的值会被直接页面加载出来比如robot.txt就直接被加载了出来

那我尝试一下目录跳转:

6

同样可以设置其还可以跳转到百度页面去。

7

仔细看是插入到了iframe标签中的src中所以导致任意URL跳转并在页面中加载出来。

接下来尝试medium:

但发现无论输入什么都不行了。尝试闭合iframe标签。

发现width和height也是可控的所以对后面参数尝试XSS:

8

成功弹窗

payload:ParamWidth=250"></iframe><script>alert(123)</script>

仔细看会发现medium是采用的addslashes而high采用的htmlspecialchars

因而用过滤sql的来防止xss是愚蠢的因而即使”被\转义也能成功闭合双引号最后成功XSS。

PHP Code injection

这个很容易理解,message后面的内容会被直接代入eval中输出出来。

9

Mail Header Injection (SMTP)

首先做题之前需要了解几个邮件相关的概念:

电子邮件中的CC英文名称是Carbon Copy(抄送)

BCC英文名称是Blind Carbon Copy(暗抄送)

利用这两个字段有时候即可进行mail hearder的注入。

10

可以看到都是明文传输的,一旦数据包被攻击者拦下,直接将其变成:

11

其中\n是换行一般最好采用url编码的%0d%0a在数据包中更好被识别。然后bcc就是暗抄送邮件就也会送到攻击者手上了。

Evil 666 Fuzzing Page

这个就是目录文件的fuzz跟dirsearch的原理类似,这里我们用BP跑:

12

可以看到成功fuzz出了666页面

0x02、A2-Broken Auth&Session Mgmt(失效的身份认证和会话管理)