前端aes加密_AES加密的安全问题

aes加密简介

AES算法全称Advanced Encryption Standard,是DES算法的替代者，旨在取代DES成为广泛使用的标准，于2001年11月26日发布于FIPS PUB 197，并在2002年5月26日成为有效的标准。2006年，高级加密标准已然成为对称密钥加密中最流行的算法之一。

AES是典型的对称加密算法，对称加密不同于md5 sha的哈希摘要算法，对称加密是可逆的，通常是明文+密钥，再利用算法来加密成密文，如果要还原也很简单，只要根据密钥+密文+生成算法的逆运算，即可解出，对称加密特点为可逆，并且加密解密都是使用同一个密钥，而非对称加密则是公钥私钥加解密模式这里不做讨论。

aes加密五种模式

aes加密的方式有五种工作体制。

1.电码本模式(Electronic Codebook Book (ECB))

这种模式主要是将明文划分为几个明文段，分块加密，但是加密密钥是相同的。

2.密码分组链接模式(Cipher Block Chaining (CBC))

这种模式是先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密。

3.计算器模式(Counter (CTR))

4.密码反馈模式(Cipher FeedBack (CFB))

5.输出反馈模式(Output FeedBack (OFB))

其中分组如，aes-128-ecb即为16字节为一组，16字节即为128位。

其他三种模式较为复杂，本文仅讨论前两种加密的安全性。

aes-ecb加密

aes-ecb加密是将一段明文，按照固定长度分组，然后对每一个分组，按照算法使用固定的密钥进行加密。假设123456加密。那么123为一组加密，456为一组加密，然后两段明文加密后的密文拼在一起，就算完整的密文。

注意：这里每一组的加密都是使用相同的密钥，相同的算法，所以在这种机制下，很可能出现安全问题。

比如：在身份认证中，查询用户是否是管理员还是普通用户，如果is_root=1则为管理员，如果不为1则为普通用户，如果采用aes-ecb加密，对原文进行分组加密。

明文：user_id:1.000000 is_root:0(其中is_root来判断是否为管理员。) 然后用一段密钥加算法进行加密。

这种提交的加密数据是在cookie中提交，明文不可控，但是密文是可控的，但由于是进行分组进行，所以我们可以推算出每一分组明文对应的密文，假设明文八个一组来进行加密，分组后变为 (提示：仅仅是假设理想情况八位，实际并不是)

第一组：is_user 第二组：1.000000 第三组: is_root: 第四组： 0(不够的八位自动填充)其中user_id 通常情况下我们前端可以修改，进行修改为1.000000，此时原文被加密之后为四组 每组为八个数字的密文假设加密后密文为 c4ca4238a0b923820dcc509a6f75849b 在cookie中被提交，将密文分为四组c4ca4238a0b923820dcc509a6f75849b

此时密文我们是可控的，如果正常提交，服务器解密之后为user_id:1.000000 is_root:0，很显然我们不是管理员，但是如果将第二组密文和第四组密文替换呢，那么user_id就是0，is_root就是1.000000。服务器就解析为user_id:0xxxxxxx(xx为填充字符) is_root:1.000000，显然我们不需要知道密钥，同样可以进行绕过。

还有一则在转账中，如果采用aes-128-ecb加密，在cookie中使用ecb分组加密，比如

付款人账户：

XXX //假设密文abc

收款人账户：

XXX //假设密文efg

试想一下，一旦这个分组是刚好分为四组，我们仅仅将abc与efg交换，那不就造成了支付收款反转，几乎不需要什么技术就可以造成严重的攻击。

ctf-案例

接下来以真实题目来进行详解。

ctf address：https://mixer-f3834380.challenges.bsidessf.net/(国外的一道ctf)

首先尝试输入admin admin 登陆。

返回内容重点为红色框内的东西，需要使得第三个参数 is_admin=1即可获得flag，但是session cookie并不是这个题关注的点，接下来就是抓包分析参数。修改参数。

经测试修改url，get cookie post传参都不能改变is_admin的值，所以只有一种可能，是在cookie里的user参数里加密了，然后传递给服务器，我们get参数传入的账号密码被服务器端加密，然后服务器返回来加密后的user信息。

接下来测试是何种加密，测试为aes-ecb加密，那么是如何确定的呢，由于ecb是分组加密，所以一旦一组的密文我们修改了，其他组的密文解密之后是正常的，而被我们修改了的密文解密会是乱码，所以我们随便修改下user参数。

可以看到报错，并且第一组的密文解密后是乱码，而其他组的加密解密后为正常，所以猜测这一定是aes-ecb的分组加密的方式，此时，我们应该先确定分组，几个为一组，先破坏第一组加密然后破坏第二组加密，然后确定解密后json数据为，

{"first_name":"admin