bWAPP——A6(Sensitive Data Exposure)
这个是bWAPP的第六节，Sensitive Data Exposure(暴露敏感数据 )
1.Base64 Encoding(Secret)
顾名思义，就是密码被加密了。
Low
很明显，在cookie里，有secret这个参数，而且就是很明显的base64编码secret=QW55IGJ1Z3M%2F,%2F是被url编码了的，实际上是/，这里放上url编码表。
| backspace | 8% | A | 41% | a | 61% | § | %A7 | Õ | %D5 |
|---|---|---|---|---|---|---|---|---|---|
| tab | 9% | B | 42% | b | 62% | « | %AB | Ö | %D6 |
| linefeed | %0A | C | 43% | c | 63% | ¬ | %AC | Ø | %D8 |
| creturn | %0D | D | 44% | d | 64% | ¯ | %AD | Ù | %D9 |
| space | 20% | E | 45% | e | 65% | º | %B0 | Ú | %DA |
| ! | 21% | F | 46% | f | 66% | ± | %B1 | Û | %DB |
| " | 22% | G | 47% | g | 67% | ª | %B2 | Ü | %DC |
| # | 23% | H | 48% | h | 68% | , | %B4 | Ý | %DD |
| $ | 24% | I | 49% | i | 69% | µ | %B5 | Þ | %DE |
| % | 25% | J | %4A | j | %6A | » | %BB | ß | %DF |
| & | 26% | K | %4B | k | %6B | ¼ | %BC | à | %E0 |
| ’ | 27% | L | %4C | l | %6C | ½ | %BD | á | %E1 |
| ( | 28% | M | %4D | m | %6D | ¿ | %BF | â | %E2 |
| ) | 29% | N | %4E | n | %6E | À | %C0 | ã | %E3 |
| ***** | %2A | O | %4F | o | %6F | Á | %C1 | ä | %E4 |
| + | %2B | P | 50% | p | 70% | Â | %C2 | å | %E5 |
| , | %2C | Q | 51% | q | 71% | Ã | %C3 | æ | %E6 |
| - | %2D | R | 52% | r | 72% | Ä | %C4 | ç | %E7 |
| . | %2E | S | 53% | s | 73% | Å | %C5 | è | %E8 |
| / | %2F | T | 54% | t | 74% | Æ | %C6 | é | %E9 |
| 0 | 30% | U | 55% | u | 75% | Ç | %C7 | ê | %EA |
| 1 | 31% | V | 56% | v | 76% | È | %C8 | ë | %EB |
| 2 | 32% | W | 57% | w | 77% | É | %C9 | ì | %EC |
| 3 | 33% | X | 58% | x | 78% | Ê | %CA | í | %ED |
| 4 | 34% | Y | 59% | y | 79% | Ë | %CB | î | %EE |
| 5 | 35% | Z | %5A | z | %7A | Ì | %CC | ï | %EF |
| 6 | 36% | ð | %F0 | ||||||
| 7 | 37% | ? | %3F | { | %7B | Í | %CD | ñ | %F1 |
| 8 | 38% | @ | 40% | | | %7C | Î | %CE | ò | %F2 |
| 9 | 39% | [ | %5B | } | %7D | Ï | %CF | ó | %F3 |
| : | %3A | / | %5C | ~ | %7E | Ð | %D0 | ô | %F4 |
| ; | %3B | ] | %5D | ¢ | %A2 | Ñ | %D1 | õ | %F5 |
| < | %3C | ^ | %5E | £ | %A3 | Ò | %D2 | ö | %F6 |
| = | %3D | _ | %5F | ¥ | %A5 | Ó | %D3 | ÷ | %F7 |
| > | %3E | ` | 60% | | | %A6 | Ô | %D4 | ø | %F8 |
| ù | %F9 |
所以secret=QW55IGJ1Z3M/然后base64解密就可以得到密码。
Medium and High
查看源码
很明显从源码就可以看出，当security_level=1或者security_level=2时，secret是被sha1加密，security_level=0就是普通的base64加密。
BEAST/CRIME/BREACH Attacks
The Lighttpd web server is vulnerable to the BEAST, CRIME and BREACH attacks. (bee-box only)
Configure TLS 1.1 or above, disable SSL and HTTP compression!
HINT: test the SSL connection on port 9443 with the O-Saft tool…（使用O-Saft工具在端口9443上测试SSL连接…）
Clear Text HTTP (Credentials)
明文传输用户凭证 。
Low
登录界面抓包
低级别用的是http，账户密码都是明文传输的。
Medium and High
查看源码
很明显看到中高级就是用https的，是加密传输数据。
Heartbleed Vulnerability
The Nginx web server is using a vulnerable OpenSSL version! ([bee-box]only)
HINT: login on port 8443 and launch the attack script…(登录端口8443并启动攻击脚本…)
Heartbleed Bug是流行的OpenSSL加密软件库中的一个严重漏洞。这种弱点允许在正常情况下通过用于保护Internet的SSL / TLS加密来窃取受保护的信息。SSL / TLS通过Internet为Web，电子邮件，即时消息（IM）和一些虚拟专用网络（VPN）等应用程序提供通信安全性和隐私。
Heartbleed错误允许Internet上的任何人读取受OpenSSL软件易受攻击版本保护的系统的内存。这会破坏用于识别服务提供商的密钥，并加密流量，用户的名称和密码以及实际内容。这允许攻击者窃听通信，直接从服务和用户窃取数据并模仿服务和用户。
Host Header Attack (Reset Poisoning)
主机标头攻击
PS:https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/
通常的做法是，同一Web服务器在同一IP地址上托管多个网站或Web应用程序。这就是主机头存在的原因。主机头指定应处理传入HTTP请求的网站或Web应用程序。Web服务器使用此标头的值将请求分派给指定的网站或Web应用程序。托管在同一IP地址上的每个Web应用程序通常称为虚拟主机。什么构成主机头攻击？
如果我们指定无效的主机标头会发生什么？大多数Web服务器都配置为将无法识别的主机头传递给列表中的第一个虚拟主机。因此，可以将具有任意主机头的请求发送到第一个虚拟主机。
传递任意主机头的另一种方法是使用X-Forwarded-Host头。在某些配置中，此标头将重写Host标头的值。因此，可以提出以下请求。
GET / HTTP/1.1
Host: www.example.com
X-Forwarded-Host: www.attacker.com
许多Web应用程序依赖于HTTP 主机头来理解“它们在哪里”。不幸的是，许多应用程序开发人员没有意识到HTTP主机头是由用户控制的。您可能已经知道，在应用程序安全性中，用户输入应始终被视为不安全，因此，如果没有先验证它，就永远不会信任。
主机头的使用在PHP Web应用程序中尤为常见，但是，它肯定不是PHP Web应用程序特有的问题。以下示例中的PHP脚本是主机头的典型且危险的用法。就bWAPP的这个例子而言
可以看到当低级别的时候，$server = $_SERVER["HTTP_HOST"]，这就很危险。主要的头部攻击启用的两个主要攻击媒介是网络缓存中毒，以及滥用其他渠道进行敏感操作，例如密码重置。
网络缓存中毒
Web缓存中毒是攻击者用来操纵Web缓存以向请求页面的任何人提供有毒内容的技术。
为此，攻击者需要毒害由站点本身或下游提供者，内容传递网络（CDN），聚合器或客户端与服务器之间的其他缓存机制运行的缓存代理。然后，缓存将向被请求它的任何人提供有毒内容，受害者无法控制向他们提供的恶意内容。
密码重置中毒
实现密码重置功能的常用方法是生成秘密令牌并发送包含此令牌的链接的电子邮件。如果攻击者通过攻击者控制的主机头请求密码重置，会发生什么？
如果Web应用程序在编写重置链接时使用主机头值，则攻击者可能会中毒发送给受害者的密码重置链接。如果受害者点击电子邮件中的中毒重置链接，攻击者将获得密码重置令牌并可以继续并重置受害者的密码。
HTML5 Web Storage (Secret)
WebStorage
WebStorage是HTML新增的本地存储解决方案之一，但并不是为了取代cookie而制定的标准，cookie作为HTTP协议的一部分用来处理客户端和服务器通信是不可或缺的，session正是依赖于实现的客户端状态保持。WebStorage的意图在于解决本来不应该cookie做，却不得不用cookie的本地存储。
但是该例中不应该将secret这种重要的信息用WebStorage存储在本地。
POODLE Vulnerability
PS:https://blog.csdn.net/zhaihaifei/article/details/47278041
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，用户隐私暴露无遗。
解决方案
目前解决该问题可以禁用SSL3.0，或者SSL3.0中使用的CBC模式加密，但是有可能造成兼容性问题。建议支持TLS_FALLBACK_SCSV，这可以解决重试连接失败的问题，从而防止攻击者强制浏览器使用SSL3.0。 它还可以防止降级到TLS1.2至1.1或1.0，可能有助于防止未来的攻击。
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。
Text Files (Accounts)
查看源码
switch($_COOKIE["security_level"])
{
case "0" :
$line = "'" . $username . "', '" . $password . "'" . "\r\n";
break;
case "1" :
$username = xss_check_3($username);
$password = sha1($password, false);
$line = "'" . $username . "', '" . $password . "'" . "\r\n";
break;
case "2" :
$username = xss_check_3($username);
$salt = md5(uniqid());
// $password = sha1($salt . $password, false);
//$password = hash("sha512", $salt . $password, false);
$password = hash("sha256", $salt . $password, false);
$line = "'" . $username . "', '" . $password . "', 'salt:" . $salt . "'" . "\r\n";
break;
default :
$line = "'" . $username . "', '" . $password . "'" . "\r\n";
break;
}
可以看得出来，Low级别的账号密码都是明文传输的，这是很不安全的。Medium级别的将密码进行了sha1加密，但是这还不是很安全，因为还是可以通过字典爆破或者暴力破解甚至可以通过查表的方式找出密码。而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'
如何加盐才是正确的姿势
- MD5(MD5(password)+salt)
- SHA512(SHA512(password)+salt)
- 引入慢哈希: bcrypt(SHA512(password), salt, cost)