由于Web应用程序中使用的应用程序内部URL由相同的代码库生成和分析，因此没有外部力量推动开发人员使用人类可读形式的序列化。当然，调试和开发更容易，但这就是我使用“外部”这个词的原因。许多框架使用自定义编码，但开发人员可以在这方面做的最极端的事情之一是完全加密请求参数。我们在最近一次网络应用安全评估中遇到过这样的设置，让我们看看它是如何实现的。
现在看到Base64编码的参数是非常标准的，但其中很多仅仅用于确保事物安全地通过各种形式的基于ASCII的容器（URL，JSON和XML编码以及类似的东西）。但是，当熵很高并且调用参数时enc，事情变得非常快速。
我的第一本能就是在Burp中调用Intruder，并蛮力使用最后2个Base64符号来查看是否有可能发生填充oracle的攻击。事实证明，该应用程序返回了所需的3种响应：一个用于理想的有效载荷，一个用于破碎的填充，另一个用于正确的填充但损坏有效载荷。我尝试过使用PadBuster，但是Web应用程序对请求的挑剔以及PadBuster中低级配置的缺乏能力是一个糟糕的组合。
快速回顾那些没有处理填充的人，或者过去的时间太长了,如果你用MAC唤醒并且与IVs一起睡，你可以跳过这三段。看看下面的图表，看看CBC解密如何在三个连续的块上工作，我们将在接下来的几句话中提到这一点。如果我们关注下面的最后（最右边）块上，我们将看到右侧的应用程序得到明文之前，它得到XOR“d与密文之前（中）块。由于我们可以完全控制密文，这意味着我们可以在前一个密文块上翻转明文中的任意位数-这当然意味着前一个块的明文将是垃圾，但是您会看到，我们将能够忽略这一点。
巧妙的是，由于分组密码要求将明文格式化为块，所以必须使用填充用于不是块长度倍数的消息。现在最常见的填充是PKCS7，它填充具有与填充长度相同的值的八位组（s）的消息。因此，如果最后一个块只有14个字节，并且块长度为16，则会附加两个0x02字节。具有内置填充支持的解密例程将读取最后一个字节，检查前面的所有字节是否都是相同的值，并在填充不正确时发出错误信号。因此，如果我们将最后一个字节的所有256种可能的组合翻转过来，理想情况下，我们将有三种不同的情况：
原来的填充字节数量未知-填充是完美的，有效载荷完好无损
填充不正确，处理暂停，应用程序给出错误消息的254个案例，以及最后但并非最不重要的
我们设法将明文的最后一个字节设置为字节0x01，这是一个有效的1字节填充-尽管有效负载可能（至少部分）是垃圾，但如果我们可以区分这个和以前的案件，我们赢了。
现在，通过XOR荷兰国际集团与被替换的值，我们得到上面的第三种情况，并（在上述情况下0×01）所产生的字节以前的（中间）块密文的原最后一个字节，我们可以计算出原始的最后一个字节。我们还可以计算一个字节，它将最后一个字节设置为0x02，并按照第（n-1）字节的过程进行处理，以此类推密文的其余部分，从而导致每个字节最多256个请求。
在我们的例子中，首先，我编写了一个基本的Python脚本来遍历下一个块的最后一个字节的所有可能的值。只有一个值导致填充是正确的，继续这种方法导致几乎所有的明文字节被发现。
唯一的问题是第一块和第四块-后者不是所有零或0xFF字节的通常块，并且第一块的明文与加密前相比是异或。因此，在第一个块之前放置一个全零块，并使用填充预言器显示IV第一块的明文。这变得非常有用，因为有效载荷是纯文本且具有容易识别的模式，这使得猜测第一个块更容易。
但是，由于IV没有明确地提出要求，所以伪造申请不是一种选择，因为第一个区块将被打破。因此我们进一步搜索了网页，希望找到关于这种方法的一些信息。当应用程序使用ASP.NET时，我们将其添加到搜索查询条件列表中，并发现了一个StackOverflow问题，该问题导致了2007年由MadsKristensen发布的博文（由于链接腐烂，我编辑了该URL）。
事实证明，开发者只是复制了这个代码，其中充满了关于密码学的有趣设计选择：
加密密钥是使用PasswordDeriveBytes类派生的，
根据密码堆栈交换问题，这实现了使用100轮SHA-1的PBKDF1，
用作输入的密码是字符串"key"
用作输入的盐是上述字符串长度的十进制表示，因此"3"，
密钥和IV始终分别是KDF输出的前32和后16个字节。
我们用一个简单的程序打包了源代码，并打印出密钥和IV，并确认这是我们实际使用的目标。
对于开发者来说幸运的是，他们并不真正依赖这种加密程序提供的“安全性”。不幸的是，现代网络堆栈中深入防御的许多方法都依赖于能够检查参数。在我们的例子中，这包括了
ASP.NET请求验证，通常会捕获简单的XSS有效负载和
浏览器强化措施（例如Chrome和Safari中的XSSAuditor）
，用于检测HTML响应中的输入参数，并拒绝评估这些表达式，当然
任何昂贵的WAF都可以在他/她宝贵的应用程序之前投入使用。
但是，在这种情况下，两种解决方案都只能看到加密值，因此在应用程序中利用XSS漏洞是非常微不足道的，否则就会造成滥用滥用的麻烦。