额,这两天看到这个词,于是去搜了搜,简单了解了下,分享分享,大神求轻喷~
重放攻击的概念
根据百科的解释:
重放攻击(Replay Attacks)又称重播攻击、回放攻击或新鲜性攻击(Freshness Attacks),是指攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程,破坏认证的正确性。 它是一种攻击类型,这种攻击会不断恶意或欺诈性地重复一个有效的数据传输,重放攻击可以由发起者,也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据,之后再把它重新发给认证服务器。从这个解释上理解,加密可以有效防止会话劫持,但是却防止不了重放攻击。重放攻击任何网络通讯过程中都可能发生。重放攻击是计算机世界黑客常用的攻击方式之一,它的书面定义对不了解密码学的人来说比较抽象。
概念性的几个防御手段
时间戳
“时戳”──代表当前时刻的数 基本思想──A接收一个消息当且仅当其包含一个对A而言足够接近当前时刻的时戳 原理──重放的时戳将相对远离当前时刻 时钟要求──通信各方的计算机时钟保持同步 处理方式──设置大小适当的时间窗(间隔),越大越能包容网络传输延时,越小越能防重放攻击 适用性──用于非连接性的对话(在连接情形下双方时钟若偶然出现不同步,则正确的信息可能会被误判为重放信息而丢弃,而错误的重放信息可能会当作最新信息而接收)
序号
通信双方通过消息中的序列号来判断消息的新鲜性 要求通信双方必须事先协商一个初始序列号,并协商递增方法
提问与应答
“现时”──与当前事件有关的一次性随机数N(互不重复即可) 基本做法──期望从B获得消息的A 事先发给B一个现时N,并要求B应答的消息中包含N或f(N),f是A、B预先约定的简单函数 原理──A通过B回复的N或f(N)与自己发出是否一致来判定本次消息是不是重放的 时钟要求──无 适用性──用于连接性的对话 重放攻击是对协议的攻击中危害最大、最常见的一种攻击形式。
以登陆为例看具体的例子
常规流程
- 前端web页面用户输入账号、密码,点击登录。
- 请求提交之前,web端首先通过客户端脚本如javascript对密码原文进行md5加密。
- 提交账号、md5之后的密码
- 请求提交至后端,验证账号与密码是否与数据库中的一致,一致则认为登录成功,反之失败。
有什么问题呢?
上述流程看似安全,认为传输过程中的密码是md5之后的,即使被监听截取到,由于md5的不可逆性,密码明文也不会泄露。其实不然!监听者无需解密出密码明文即可登录!监听者只需将监听到的url(如:http://****/login.do?method=login&password=md5之后的密码&userid=登录账号)重放一下,即可冒充你的身份登录系统。
稍微安全点的方式
- 进入登陆页面时,生成一个随机码(称之为盐值),在客户端页面和session中各保存一份。
- 客户端提交登录请求时,将md5之后的密码与该随机码拼接后,再次执行md5,然后提交(提交的密码=md5(md5(密码明文)+随机码))。
- 后端接收到登录请求后,将从数据库中查询出的密码与session中的随机码拼接后,md5运算,然后与前端传递的结果进行比较。
为何要这样?
该登录方式,即使登录请求被监听到,回放登录URL,由于随机码不匹配(监听者的session中的随机码与被监听者的session中的随机码相同概率可忽略),无法登录成功。 该登录方式,由于传输的密码是原密码md5之后与随机码再次md5之后的结果,即使监听者采用暴力破解的方式,也很难解密出密码明文。
更进一步
考虑到密码输入的方便性,好多用户的密码都设置的很短,并且不够复杂,往往是6位数字字母组合,这样的密码md5之后保存到数据库,一旦数据库数据泄露,简单密码的md5结果很容易通过暴力破解的方式给解密出来,何况md5出现了这么多年,可能已经有不少字典了!同时为了方便用户登录的方便性,我们的系统一般不可能要求用户设置很长、很复杂的密码!怎么办?加固定盐值。
- 系统设置一个固定的盐值,该盐值最好足够复杂,如:1qaz2wsx3edc4rfv!@#$%^&qqtrtRTWDFHAJBFHAGFUAHKJFHAJHFJHAJWRFA
- 用户注册、修改密码时,将用户的原始密码与我们的固定盐值拼接,然后做md5运算。
- 传递至后端,保存进数据库(数据库中保存的密码是用户的原始密码拼接固定盐值后,md5运算后的结果)。
- 登录时,将用户的原始密码与我们的固定盐值进行拼接,然后做md5运算,运算后的结果再拼接上我们的随机码,再次md5运算,然后提交。
- 后端接收到登录请求后,将从数据库中查询出的密码与session中的随机码拼接后,md5运算,然后与前端传递的结果进行比较。
再再进一步
- 加登录验证码,可预防人为地暴力登录破解
- 账户锁定,如果用户密码输入错误次数达到一定量后(如6次),则可以锁定该账号
嗯,还有就是重复提交表单也和重放攻击的道理一样吧, 那个稍微安全的方法其实原理和token机制原理一样一样的吧
@msdlisper 重放的话可能侧重于劫持方面讲吧,重复提交表单通常也不一定是攻击
学习了
主要是假设攻击者不知道这个方法吧"md5(md5(密码明文)+随机码)",不然session里面的随机值被监听到了也能伪造了。
看得我晕忽忽的, 谁用前端JS md5加密? 谁会把密码放url里? session是服务器端的,客户端那叫cookies.
有点意思,学习了!
@hezedu url参数那个只是打比方,post请求和get请求不处理其实也差不多,都能拿到明文
@hezedu 不管你放哪里,你一提交,浏览器就会把你的表单内容和cookie以及客户端信息通过HTTP协议传输到服务器,劫持者不需要关心内容,只需要拿到内容重放一次就行了,不要太天真……
写得很清晰,收藏了!
csrf 就能解决吧
@chita csrf只是对请求源进行限制了吧,并不能阻止别人拿到明文。 你想象一下当路由不是路由而是一个充当路由的劫持者的时候,他可以完整转发你的请求到目标地址,并返回结果给你,但是在传输过程中明文不就泄露了么。
总的来说 需要加密的思路没问题 但是就像大家说的用户真的要是被劫持,貌似还真的很难说有方法破 正要安全验证嘛,至少得后端获取一个客户端的值进行加密才行
@yuk320 没有绝对的安全,只能一定程度上解决
@luoyjx 的确 只是增加敌方成本 自豪地采用 CNodeJS ionic
我知道,相比明文传输,这可以提高破解成本,不希望一个菜鸟通过抓包获取明密码;不过 session 劫持的话,好像还是可以登录
请教大牛, 如果是无状态api应用程序不使用session, 没有办法在客户端和服务端保存同样一份随机码, 那有什么比较安全的token校验方案?
@techmango 不管是session还是其他,都是http返回,我建议你好好看一看http,session体系是返回头里带一个 setCookie命令,浏览器就会记录一些东西。 同理你不用cookie,直接从接口返回这个随机码也是一样的,对于看透了http的人来说,没有任何区别
请问一下楼主,就算加一些随机码,还是序号之类的,但凡是通过网络接收这个随机码,攻击者还是能充分伪造这样的请求, 拿到合法可用的随机码,目前有切实可行的防重放手段吗?