常见的Web密码学攻击方式汇总
分组密码的模式
分组密码每次只能处理加密固定长度的分组，但是我们加密的明文可能会超过分组密码处理的长度。
这时便需要对所有分组进行迭代，而迭代的方式被称为分组密码的模式。常见的为针对ECB、CBC模式攻击(L-ctf提到其中一种)。
ECB
ECB模式的全称是Electronic CodeBook模式，将明文分组加密后直接成为密文分组，而密文则是由明文分组直接拼接而成，如图所示：
Features：
ECB模式是所有模式中最简单的一种。明文分组和密文分组是一一对应的，如果明文分组有相同的那么最后的密文中也会有相同的密文分组。
因为每个分组都独自进行加密解密，所以无需破解密文就能操纵部分明文，或者改变明文，在不知道加密算法的情况下得到密文，从而达到攻击效果，如图所示（翻转密文分组，那么明文分组也会被翻转）
Example：
某次CTF遇到的题目
思路：以administrator权限登陆就就能获得Flag。判断权限则是根据cookie里面的uid参数，cookie包含username和uid两个参数，均为使用ECB加密的密文，然而username的密文是根据注册时的明文生成的。
因此我们可以根据username的明文操纵生成我们想要的uid的密文。经过fuzz发现明文分组块为16个字节，那么我们注册17字节的用户，多出的那一个字节就可以是我们我们希望的UID的值，而此时我们查看username的密文增加部分就是UID的密文，即可伪造UID。
注册aaaaaaaaaaaaaaaa1获得1的密文分组,注册aaaaaaaaaaaaaaaa2获得2的密文分组，以此类推
源码没找到，好像弄丢了，自己写了个差不多的,有兴趣可以练习
ebc.php：
ecb.py：
CBC
CBC模式的全称是Cipher Block Chaining模式,在此模式中，先将明文分组与前一个密文分组(或为初始化向量IV)进行XOR运算，然后再进行加密。
解密则为密文分组先进行解密，然后再进行xor运算得到明文分组，解密过程如图所示(加密则相反)
Features：
因为CBC模式是将前一个密文分组和明文分组进行混合加密所以，是可以避免ECB模式的弱点。
但正因为如此，导致了解密时修改前一个密文分组就可以操纵后一个的解密后的明文分组，可以将前一个密文中的任意比特进行修改（0,1进行互换，也可以叫翻转）
因此CBC模式有两个攻击点：①vi向量，影响第一个明文分组 ②第n个密文分组，影响第n+1个明文分组
Example：
在比赛中遇到过很多次，基本上属于对一个密文分组进行翻转之后能够提升权限或者绕过验证的作用，自己写了一个差不多的，攻击密文的，大家可以看看
大概就是这样，要获得FLAG需要让ID=0，而我们是可以从URL中知道密文的
http://127.0.0.1/cbc2.php?a=89b52bac0331cb0b393c1ac828b4ee0f07861f030a8a3dc4b6e786f473b52182000a0d4ce2145994573a92d257a514d1
我们现在要对密文进行翻转攻击，但是并不清楚哪部分对应的是ID的上一个密文，可以直接脚本进行FUZZ，也可是使用burp(intruder)进行测试（选择攻击的密文）
选择攻击模式
攻击结果
burp的翻转并不是遍历所有翻转的可能每一位变动一次，比如101101的第一次为101100，那么的二次就是101110，第三次是101000，依次类推。
所以burp可能无法完全翻转出需要的payload，但是可以帮我确定需要翻转的位置，我们经过简单的计算就能得到自己需要的值
比如这里进过对比，我们轻松的找到了需要翻转的位置，但是却没有得到为0的翻转，数学不及格的我来算算。xor运算的特点:a xor b =c abc三个数任意两个运算可得到第三个，所以
0b的10进制是11
11xor5=14
14xor0=14
14的十进制为0e
FUZZ反转成功。
最后在提醒下：AES128位一组，换成16进制其实我们反转的的是第一组。但影响的却是第二组
我们这个演示的是攻击密文的，攻击iv的，基本相似，有兴趣的可以去看看OWASP里面的，那个是攻击iv的
cbc.php：
Hash-Length-Extension-Attack
许多算法都使用的Merkle–Damgård construction,比如MD5，和SHA-1等，因此这些算法都受到Length-Extension-Attack。
要说清这个攻击原理，我们还是简单说说SHA-1
Features：
SHA-1处理消息前会先对消息进行填充，使整个消息成为512比特的整数倍，每个分组均为512比特
①填充(Padding)，方式为将多余的消息后面加一位，且为1，然后后面全部使用0填充使整个分组变为448比特，而最后的64比特会记录原始消息的长度，填充后每个分组均为512比特。
②然后就是复杂的数学计算~_~我也看的不是特别懂，但是并不影响我们理解。简单说说就行，首先会定义5个32比特的值（缓冲区初始值，是不是加起来刚好160比特~~，可以理解为iv）。
然后大概就是每个分组会经过了80步的处理，然后会输出新的5个32比特的值，这个时候我们可以理解原始消息已经充分混入这160比特里面，再用这5个数作为初始值去去处理下一个分组,依次类推，最后得到的hash其实就是这5个数，可以看看我画的便于理解的草图：
Example：
Hash-Length-Extension-Attack ，可以在知道MD5(message)的hash值得情况下，算出MD5(message+padding+a)的hash值，就是根据短的消息的hash算出更长的消息的hash。
为什么呢，其实看了上面的图就会觉得很简单了。我们把hash反排序一下不久又得到5个新的32个比特值吗（此处是可以逆向MD5的算法的），我们可以用这5个数继续消息混合，而我们之前padding的数据就会成为整个消息的一部分说以能够算出MD5(message+padding+a)，a就是我们要继续混合的消息。
这类漏洞一般出现在CTF中比较多，类型都是费否等于MAC == hash(message+test) message未知或者只知晓一部分，不过都不重要，重要是的message的长度，因为会影响到拓展后的消息，不知道的话就需要爆破，然后test位置可控，这样才能拓展，MAC一般也是可控，校验通过就能下一步哈哈，或者拿flag。
之前我们都是看的CTF(L-ctf也有一部分，拓展后可以下载压缩包)，我们就来看看phpwind的MD5 padding 漏洞
其实是windidserver接口验证缺陷，用扩展攻击绕过验证就可以执行接口中的其他控制器中的其他方法~~
这个函数会在执行控制其方法之前执行，进行验证，然而我们发现$_windidkey可以自己输入，只要是appkey的结果相等就能通过验证
既然都已经说了是这类型的漏洞，那我们肯定就要找能找到的hash
showFlash这里满足要求（打印出了hash 822382cb79f915c779943a1dc131f00c）
我们再跟踪appkey
经过各种排序，我们可以得出这个hash的值和消息的结构
822382cb79f915c779943a1dc131f00c = md5（md5().$time.$str）
822382cb79f915c779943a1dc131f00c= md5 +1475841959 + adoAvatarcavatarmapitypeflashuid2uidundefined
里面的md5值不知道，但是是32位，$time.$str都是可控，那么我们就可以拓展这个消息，得到新的hash,而调用这个函数进行验证的得地方自然也就绕过了验证 $_windidkey我们只要传入拓展后的hash即可绕过。因为我们拓展时必须保持md5 +1475841959 + adoAvatarcavatarmapitypeflashuid2uidundefined的结构，然而排序的时候回因为传入的a(action)参数导致打乱循序，无法扩展，但是因为phpwind的路由支持post,所以post一下控制器(c)，模块(m)，动作(a)这三个参数
$_windidkey（我们拓展的hash）== md5 +1475841959 + adoAvatarcavatarmapitypeflashuid2uidundefined +padding +alistcappmapi(post排序的)正好绕过验证
填写一下cookie和url就可以获得secretkey（调用的list方法，要实现其他action自行修改，getshell就暂不讨论，这不是我们这里的重点
后记
如果有错误的地方欢迎指正！
本文转自“安全客”
请输入标题 bcdef
实践操作
实践是检验真理的唯一标准！
请输入标题
点击“阅读原文”，学习实验！