系统登录页面,为防止明文传输用户密码,开发者做了安全加固。
服务端暴露一个 loginEncryptKey 的API,用来根据登录名 username 获取 加密秘钥 encryptKey。 前端页面 获取到 encryptKey 后,在请求login登录接口时,会对 用户密码 进行加密传输。
这个 loginEncryptKey 接口的服务端怎么写的呢?下面是完整代码,其中SysLoginModel
中定义了 username 属性。程序利用redis缓存,来存储RSA公私钥。
点击查看代码
@PostMapping(value = "/loginEncryptKey")
public Result<String> loginEncryptKey(@RequestBody SysLoginModel sysLoginModel) {
String cacheKey = LOGIN_ENCRYPT_KEY_CACHE + sysLoginModel.getUserName();
//缓存获取
String cache = redisUtil.get(cacheKey, "");
if ("" != cache) {
String publicKeyStr = JSON.parseObject(cache).getString("public");
return Result.successWithMsg(publicKeyStr);
}
KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
// 初始化密钥对生成器,密钥大小为96-1024位
keyPairGen.initialize(1024, new SecureRandom());
// 生成一个密钥对,保存在keyPair中
KeyPair keyPair = keyPairGen.generateKeyPair();
// 得到公钥字符串
String publicKeyString = Base64.encode(keyPair.getPublic().getEncoded());
// 得到私钥字符串
String privateKeyString = Base64.encode(keyPair.getPrivate().getEncoded());
//缓存写入
JSONObject cacheMap = new JSONObject();
cacheMap.put("public", publicKeyString);
cacheMap.put("private", privateKeyString);
redisUtil.set(cacheKey, cacheMap.toJSONString(), 7 * 24 * 60 * 60);
return Result.successWithMsg(publicKeyString);
}
在进行API测试中发现,这个接口相当肉鸡!给username传任意值,包括空值,都可以获取到一个秘钥。
显然,这为恶意攻击开辟了绿道。当流量攻击像疯狗一样呼啸而来,就会发生redis缓存穿透,这里虽然不是穿透到数据库,但是不停地生成RSA密钥对,这个程序开销也不小。
我们来看看怎么修复、完善这个接口的生成加密key的逻辑。
首先,接口要校验请求参数,这是对程序员的底线要求。
判空吗?
光判空,显然是不够的。那怎么办?
除了判空,还要判断参数的合法性。对于明显错误的传值,如username是一段1024的大文本,直接pass掉。再如,username不符合系统的用户名设置规则,诸如包含了符号(如果允许@符号,那排除@符号),也直接pass掉。
其次,我们可以判断username在系统里是否存在。不存在,则中止程序,直接响应”非法请求“。当然,这里不能每次都查库,用本地缓存为上。
其次,再来说如何更好地生成、获取encryptKey(加密key)
打开脑洞,直接说重点。---->如果不用redis,岂不妙哉!
统一用一个encryptKey?显然,不够安全。
因此,程序可以预先生成一批 encryptKey。 然后,当接口收到请求时,根据username的哈希值,然后做取模运算,从这批encryptKey里命中一个返回。
随机从这一批encryptKey里直接取一个返回,不香吗?当然不行了,因为后面的login接口里,得用同样的encryptKey来解密用户密码。就是说,login接口也要使用上面的根据username获取encryptKey的方法。
既然涉及到复用,在程序设计上,我们没理由不进行封装。如下是一个示例:
private static int customHash(String username) {
int hash = 0;
// hash=username.hashCode(); // 默认的哈希算法
// 自定义哈希算法,防止被破解
for (int i = 0; i < username.length(); i++) {
hash = hash * 17 + username.charAt(i);
}
int mod = hash % 10;
return mod;
}
上面的封装OK吗? - - 不OK(不彻底)!
要封装的,应该是↓
private static String getEncryptKeyByUserName(String username) {
int hash = 0;
// hash=username.hashCode(); // 默认的哈希算法
// 自定义哈希算法,防止被破解
for (int i = 0; i < username.length(); i++) {
hash = hash * 17 + username.charAt(i);
}
int mod = hash % 10;
return encryptKeys[mod];
}
有了这种不依赖redis缓存的方案,上面判断username是否在系统里存在的校验,似乎也可以省掉了。
至此,本文结束。本文重点阐释生成、获取加密key的优化办法。接口限流、接口增加签名机制等技术,不在讨论范围内。
标签:username,hash,围攻,int,接口,肉鸡,encryptKey,String From: https://www.cnblogs.com/buguge/p/18539460