「java重放攻击」java如何防重放
今天给各位分享java重放攻击的知识，其中也会对java如何防重放进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、关于JAVA时间戳
- 2、密码技术
- 3、开放平台API接口安全性设计——微信支付为例
- 4、漏洞和缺陷的区别
- 5、密码那些事
关于JAVA时间戳
Timestamp就是所谓的时间戳，这个主要用在数据库上，你可以再java.sql这个包内找到这个类，一般数据库里如果用Date这个类的话，那你取出来的时候只能到某一天，也就是日，但是Timestamp的话，就是到小时一直到纳秒，很精确的。但是你把时间存进去的时候也要用这个类。比如：mysql的话，你可以用setTimtstamp();这个方法，你可以到java的文档里去看看，里面都写的比较清楚
密码技术
密码算法的特性
1、是否需要事先配送私钥：对称密码需要考虑
2、是否会遭到中间人攻击：非对称密码分发公钥时需要考虑
3、不可抵赖（可被双方 和 第三方 用原理证明）：非对称密码分发公钥时需要考虑
4、能否保证消息的机密性：即不可破译
5、能否保证消息的完整性（一致性）：即不可篡改
6、不可冒充（伪造）
总结：对称密码（解决456）--非对称密码之单向通信-- 混合密码（解决1） --非对称密码之数字签名-- 公钥证书（解决23）
概念
密码算法：加密算法 + 密钥 + 解密算法，简称密码
密钥空间：密钥的所有取值
隐蔽式安全性：以密码算法不为人所知，来保证机密性
分组密码：对明文进行分组加密，而非以全文作为输入
流密码：不分组，整体加密
破解密文的方法
1、窃听 + 破译
2、社会工程学
破解密钥的方法
1、暴力破解（密钥穷举），例如破译凯撒密码
2、频率分析，例如破译简单替换密码
3、选择明文攻击（对分组进行明文穷举）
加密系统的可选技术
隐写术：将消息藏在更大的数据中，例如藏头诗
伪随机数生成器
散列值（摘要，哈希值，指纹）：原文经过散列函数（摘要函数，哈希函数，杂凑函数，单向加密）计算出来的值
对称密码（共享密钥密码）：加密和解密用同一个私钥
非对称密码（公钥密码）：公钥加密，私钥解密
消息认证码
数字签名
公钥证书
碰撞：两个消息的散列值相同
弱抗碰撞性：给定一条消息，很难找到另一条消息与其散列值相同。防止以下情形，Bob持有一个消息A，计算其摘要；Alice找到与A散列值相同的另一条消息B，用B将A调包；由于摘要不变，不被Bob发觉
强抗碰撞性：很难找到两条散列值相同的消息。防止以下情形，Alice拿两个摘要相同的消息A和B，将A发给Bob；Bob计算其摘要；Alice再用B将A调包；由于摘要不变，不被Bob发觉
MD5（Message Digest 5）
历史：1991年Ronald Rivest 设计出MD5
现状：2004年王小云提出了MD5碰撞攻击算法
SHA
历史：1993年NIST发布SHA，1995年发布SHA-1，2002年发布SHA-2
现状：2004年王小云提出了SHA-0的碰撞攻击算法；2005年王小云提出了SHA-1的碰撞攻击算法
SHA-3
历史：2007年NIST发起选拔SHA-3，2012年Joan Daemen等人设计的Keccak算法被选定为SHA-3
弱伪随机数：随机性
强伪随机数：不可预测性
真随机数：不可重现性
随机数生成器：硬件可以通过热噪声实现真随机数
伪随机数生成器：软件只能生成伪随机数，需要一种子seed来初始化
伪随机数算法：线性同余法、散列法、密码法等
好的对称密码解决：不可破译
缺点：需要事先配送密钥
凯撒密码
加密算法：字母平移
密钥：平移位数
解密算法：逆向平移
破解密钥：穷举可能的密钥
简单替换密码
加密算法：一个字母替换成另一个字母
密钥：替换表
解密算法：逆向替换
破解密钥：对密文的字母 和 字母组合进行频率分析，与通用频率表对比；用破译出来的明文字母，代入密文，循环分析
Enigma密码
发明者：德国人Arthur Sherbius
加密算法：双重加密，每日密钥作为密钥1，想一个密钥2；用密钥1加密密钥2，得到密钥2密文；用密钥2加密消息；将密钥2密文和消息密文一起发出
密钥：密钥册子记录的每天不同的密钥
解密算法：用每日密钥解密密钥2密文，得到密钥2；用密钥2解密消息密文
破译者：Alan Turing 图灵
DES密码（Data Encryption Standard）
历史：1974年IBM公司的Horst Feistel开发出了Lucifer密码，1977年被美国国家标准学会（American National Standards Institute，ANSI）确定为DES标准
加密算法：以64比特为一组，进行16轮运算。在一轮中，把一组分为左侧和右侧，并从密钥中提取子密钥；轮函数用一侧和子密钥生成一个比特序列，用这个比特序列对另一侧进行异或运算（XOR）
密钥：长度56位
破译：可在现实时间内被暴力破解
三重DES密码（triple-DES，TDEA，3DES）
加密算法：将DES重复三次
密钥：长度 56 * 3
AES密码（Advanced Encryption Standard）
历史：1997年，美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）公开募集AES，2000年比利时密码学家Joan Daemen 和 Vincent Rijmen提交的Rijndael方案，被选为标准
加密算法：以128比特为一组，进行多轮的替换、平移、矩阵运算
密钥：有128,192,256三种长度
分组密码的迭代模式
ECB模式：Electronic CodeBook mode，电子密码本模式；明文分组 和 密文分组 顺序对应。主动攻击者可以改变密文分组的顺序，复制 或 删除密文分组，使得接受者解密后得到错误的明文
CBC模式：Cipher Block Chaining mode，密码分组链接模式；将本组明文 和 上组密文 进行异或运算后，在进行加密；如果被篡改，则不能正常解密
CFB模式：Cipher Feedback mode，密文反馈模式；将本组明文 和 上组密文 进行异或运算后，就得到本组的密文
OFB模式：Output Feedback mode，输出反馈模式；用随机比特序列作为初始化组（初始化向量）；用初始化组的密文和 明文分组 异或运算，得到密文分组；再次对初始化组密文进行加密运算，得到新的初始化组密文，跟下组明文进行异或运算，以此类推
CTR模式：CounTeR mode，计数器模式；用随机比特序列作为计数器的初始值，加密后与明文分组进行异或操作，得到密文分组；计数器加一，对下组明文进行加密
对称密码中，发送方发送密文时，带上消息的MAC值A；接收方用相同方法计算出MAC值B；对比A和B，确保消息不被篡改
Encrypt-then-MAC：MAC值为消息密文的散列值
Encrypt-and-MAC：MAC值为消息明文的散列值
MAC-then-Encrypt：MAC值为明文散列值的密文
重放攻击：攻击者窃听到Alice给Bob发送的消息后，重复给Bob发送，Bob以为都是Alice发的
预防重放攻击：消息里带有一个id
比对称密码：不可篡改、不可伪造
缺点：需要实现配送私钥
基于口令的密码：Password Based Encryption，PBE
解决：密钥（会话密钥）保存问题
CEK：会话密钥
KEK：用来加密CEK的密钥
方案
1、随机数作为盐salt，口令 + 盐 的散列值作为KEK
2、用KEK加密CEK，得到CEK密文
3、只保存盐和CEK密文，人脑记住口令，丢弃KEK
字典攻击：如果没有盐参与生成KEK，那么口令决定了KEK，常用的口令对应一个常用KEK字典，攻击者直接拿常用KEK去解密CEK密文
盐的作用：KEK由盐参与形成，不可能有KEK字典包含这样的KEK
非对称密码单向通信，不能单独用于通信，只用在混合密码中
方案：Alice 给 Bob 分发加密密钥（公钥）；Bob用公钥加密消息，发送给Alice；Alice用解密密钥（私钥）解密
总结：消息接收者是密钥对主人，即私钥持有人；公钥用于加密，私钥用于解密
RSA密码
历史：1978年，Ron Rivest、Adi Shamir、Reonard Adleman共同发表了RSA
加密算法：密文 = 明文 E mode N
公钥：E 和 N的组合
解密算法：明文 = 密文 D mode N
私钥：D 和 N的组合
生成密钥对
生成质数：用伪随机数生成随机数，通过Miller-Rabin测试法测试它是不是质数，直到得到质数
求最大公约数：欧几里得的辗转相除法
1、求N
生成两个512位的质数p和q，N = p * q
2、求L
L是p-1 和 q-1 的最小公倍数
3、求E
用伪随机数生成(1,L)范围内的随机数，直到满足E和L的最大公约数为1
4、求D
用伪随机数生成(1,L)范围内的随机数，直到满足(E * D) mod L = 1
破解：对N进行质因数分解，得到p和q，从而求出D。但是对大数的质因数分解，未有快速有效的方法
首次通信为混合密码，后续通信为对称密码
比消息认证码：无需事先配送私钥
总体思路：Bob 用会话密钥加密消息，用Alice的公钥加密会话密钥，一起发给Alice；Alice用私钥解密会话密钥，用会话密钥解密消息
会话密钥：用来加密消息的 对称密码的密钥
1、Alice 给 Bob 发送公钥
2、Bob随机生成会话密钥，用会话密钥加密消息，得到消息密文
3、Bob用公钥加密会话密钥，得到会话密钥密文
4、Bob将会话密钥密文和消息密文一起发给Alice
5、Alice用私钥解密会话密钥，再用会话密钥解密消息
6、双方都有了会话密钥，从此以后，可以用对称密码通信了，带上消息认证码
缺点：分发公钥时，可能遭受中间人攻击；Alice可能对给Bob发送公钥这件事进行抵赖
中间人攻击：中间人从一开始Alice向Bob发放公钥时，就拦截了消息，得到Alice的公钥；然后伪装成Alice，向Bob发送自己的公钥；从而Bob打算发给Alice的消息，能被中间人解密
不能单独用于通信，只用在公钥证书中
明文签名：Alice用签名密钥（私钥）加密消息的摘要，把摘要密文和消息明文一起发给Bob；Bob解密摘要密文，得到摘要A；算出明文摘要B，对比A和B
总结：私钥用于加密，公钥用于解密，与 非对称加密之单向通信，刚好反过来
公钥证书：Public-Key Certificate，PKC，简称证书
认证机构：Certification Authority，CA
证书标准：国际电信联盟ITU 和 国际标准化组织ISO指定的X.509标准
流程：
1、Alice在CA登记
2、CA生成Alice的证书明文，包含Alice登记的信息、Alice的公钥、CA信息
3、CA用自己的私钥加密证书明文部分，得到数字签名
4、证书明文部分 和 数字签名 组成PKC，颁发给Alice
5、Bob向Alice获取这个PKC，拿本地已有的CA公钥去验证证书，就得到了可信的Alice的公钥
6、从此Alice 和 Bob之间可以进行混合密码通信
首次通信为从CA获取PKC，后续通信为混合密码
比混合密码：防止了中间人攻击；CA不能抵赖自己的证书
历史：1994年网景公司设计出SSL，2014年SSL 3.0被发现安全漏洞，1999年IEIF发布TLS
TLS（Transport Layer Security）是SSL（Secure Socket Layer）的后续版本，在tcp和http之间加一层TLS，就是https
OpenSSL：OpenSSL是实现SSL/TLS协议的工具包
以https为例
0、浏览器安装时，存有几个CA公钥；服务器在CA登记，拿到证书
1、浏览器访问一个https地址，服务器返回自己的证书
2、浏览器根据证书上的CA信息，拿对应的CA公钥验证证书，得到可信的服务器公钥
3、浏览器生成对称密码的密钥（会话密钥），用服务器公钥加密后发给服务器
4、服务器解密后得到会话密钥，从此用对称密码通信，带上消息认证码
1、生成JKS证书：keytool -genkeypair -alias "别名" -keyalg "RSA" -keystore "D:\app.jks"
2、将JKS转换成PKCS12：keytool -importkeystore -srckeystore D:\app.jks -destkeystore D:\app.p12 -deststoretype pkcs12
3、将PKCS12转成pem：openssl pkcs12 -in ./app.p12 -out app.pem
4、提取加密后的私钥：将pem中 “—–BEGIN ENCRYPTED PRIVATE KEY—–” 至 “—–END ENCRYPTED PRIVATE KEY—–” 的内容拷贝出来，保存为ciphertext.key
5、将密文私钥转成明文私钥：openssl rsa -in ciphertext.key -out plaintext.key
.jks（Java Key Storage）：二进制格式，包含证书和私钥，有密码保护
.pfx 或 .p12（Predecessor of PKCS#12）：二进制格式，包含证书和私钥，有密码保护
.pem（Privacy Enhanced Mail）：文本格式，包含证书，可包含私钥，私钥有密码保护
.der 或 .cer：二进制格式，只包含证书
.crt（Certificate）：可以是der格式，也可以是pem格式，只包含证书
SSL证书：SSL证书必须绑定域名，不能绑定IP
加密服务、密钥管理服务
开放平台API接口安全性设计——微信支付为例
API接口，类似 ;mch_id=123 ，这个请求我以商户mch_id=123的身份给订单号为order_id=123退款，如果服务器不辩别请求发起者的身份直接做相应的操作，那是及其危险的。
一般的，在PC端，我们是通过加密的cookie来做会员的辨识和维持会话的；但是cookie是属于浏览器的本地存储功能。APP端不能用，所以我们得通过token参数来辨识会员；而这个token该如何处理呢？
延伸开来，接口的安全性主要围绕Token、Timestamp和Sign三个机制展开设计，保证接口的数据不会被篡改和重复调用。
一般来说，在前端对数据做加密或者前面，是不现实的。前后端使用HTTP协议进行交互的时候，由于HTTP报文为明文，所以通常情况下对于比较敏感的信息可以通过在前端加密，然后在后端解密实现"混淆"的效果，避免在传输过程中敏感信息的泄露（如，密码，证件信息等）。不过前端加密只能保证传输过程中信息是‘混淆’过的，对于高手来说，打个debugger，照样可以获取到数据，并不安全，所谓的前端加密只是稍微增加了攻击者的成本，并不能保证真正的安全。即使你说在前端做了RSA公钥加密，也很有可能被高手获取到公钥，并使用该公钥加密数据后发给服务端，所以务必认为前端的数据是不可靠的，服务端要加以辩别。敏感信息建议上https。
所以一般建议上https，敏感信息md5混淆，前端不传输金额字段，而是传递商品id，后端取商品id对应的金额，将金额等参数加签名发送到支付系统。金额可以是明文的。
token授权机制 ：用户使用用户名密码登录后，后台给客户端返回一个token（通常是UUID），并将Token-UserId键值对存储在redis中，以后客户端每次请求带上token，服务端获取到对应的UserId进行操作。如果Token不存在，说明请求无效。
弊端 ：token可以被抓包获取，无法预防MITM中间人攻击
用户每次请求都带上当前时间的时间戳timestamp，服务器收到请求后对比时间差，超过一定时长（如5分钟），则认为请求失效。时间戳超时机制是防御DOS攻击的有效手段。
将token，timestamp等其他参数以字典序排序，再加上一个客户端私密的唯一id（这种一般做在服务端，前端无法安全保存这个id）或使用私钥签名，将前面的字符串做MD5等加密，作为sign参数传递给服务端。
地球上最重要的加密算法：非对称加密的RSA算法。公钥加密的数据，可以用私钥解密；私钥签名（加密）的数据，可以用公钥验签。
RSA原理是对极大整数做因数分解，以下摘自维基百科。
暂时比较忙没时间，将于7月29日晚更新。
来更新啦。
微信支付安全规范，可以查看官方文档
第1点中，其签名算法最重要的一步，是在最后拼接了商户私密的API密钥，然后通过md5生成签名，这时即使金额是明文也是安全的，如果有人获取并修改了金额，但是签名字段他是无法伪造的，因为他无法知道商户的API密钥。当然，除了微信支付的拼接API生成签名的方法，我们也可以通过java自带的security包进行私钥签名。其中nonce随机字符串，微信支付应该做了校验，可以防止重放攻击，保证一次请求有效，如果nonce在微信支付那边已经存在，说明该请求已执行过，拒绝执行该请求。
阮一峰老师的博客-RSA算法原理：
维基百科：
漏洞和缺陷的区别
漏洞
漏洞存在于软件代码(源代码或二进制)中。一个最经典的漏洞是缓冲区溢出漏洞，这个漏洞根本上涉及滥用C中某些字符串处理函数功能。其中最臭名昭著的函数功能是gets()，这是一个系统调用，它从用户获取输入直到用户决定点击回复。我们把一个固定大小的缓冲区想象成一个空水杯，然后想像一下，你设置了方法来从杯中取水以避免满杯(攻击者则在不断“倒水”)。如果倒太多水到杯子里，水溢出来，就回洒在台面上。在C中的缓冲区溢出的情况下，太多输入会覆盖堆，或者甚至覆盖堆栈，从而破坏程序的堆栈，造成程序崩溃或使程序转而执行其它指令以进行攻击。简单的漏洞，可怕的后果。面对gets()的问题，我们特别容易在源代码中找到漏洞。
C中有数以百计的系统调用，如果使用不当的话，它们可能会导致安全漏洞，包括从字符串处理功能到整数溢出和整数下溢等问题。当然，在Java和其他语言中也有一样多的错误。另外，在Web应用程序(例如跨站脚本或者跨站请求伪造)中也有常见漏洞以及与数据库相关的漏洞(例如SQL注入漏洞)。
面对这么多可能存在的漏洞，我们有必要部署和使用一些工具来查找它们。现在市面上有很多商业源代码审查工具，比如惠普的Fortify、IBM的AppScan Source、Coverity公司的Quality Advisor，以及Klocwork的Clocwork Insight。目前源代码审查的最新突破是直接整合漏洞查找到每个开发人员的集成开发环境(IDE)中，这样我们就能尽可能在最开始发现漏洞。比如，Cigital的SecureAssist就是这种原理。
缺陷
除了漏洞之外，我们还会看到缺陷问题。缺陷存在于软件架构和设计中。这里有一个非常简单的缺陷的例子：忘记验证用户。这种错误通常无法在代码审查中被发现，但这是一个极其严重的问题。你的进程是以root身份运行吗?最好确定谁在使用它!
其它关于缺陷的例子包括“中间攻击人”问题，它使得攻击者能在组件、网络层、机器或者网络之间进行篡改或者窃听;另外，还有与糟糕协议有关的“重放攻击”问题。
为了更好地说明缺陷，我们在这里列出了一些常见的与Java相关的缺陷问题：错误使用密码系统、设计中的分区问题、特权块保护故障(DoPrivilege())、灾难性安全故障(脆弱性)、类别安全混淆错误、不安全的审计、损坏或不合逻辑的访问控制(网络层上的RBAC)、方法覆盖问题(子类问题)、对不该信任的组件给予太多信任(客户端)。(关于这些问题的更多信息，请参阅McGraw的《保护Java》一书)。
缺陷问题与漏洞一样常见。事实上，大多数研究表明，漏洞和缺陷各占50%。当然，本文中我们讨论的是这二者的统一体。还有一些棘手的情况可能被同时归类为漏洞和缺陷，这就取决于你如何看待它。但是，在一般情况下，学习区分漏洞和缺陷对你很有意义。
密码那些事
之前在工作中经常用密钥，但是不知道其中的原因，现在闲下来就来看下，再看的过程发现这个随机数概念很模糊，于是就查了下，现总结如下：
0x01 随机数
概述
随机数在计算机应用中使用的比较广泛，最为熟知的便是在密码学中的应用。本文主要是讲解随机数使用导致的一些Web安全风。
我们先简单了解一下随机数
分类
随机数分为真随机数和伪随机数，我们程序使用的基本都是伪随机数，其中伪随机又分为强伪随机数和弱伪随机数。
真随机数，通过物理实验得出，比如掷钱币、骰子、转轮、使用电子元件的噪音、核裂变等
伪随机数，通过一定算法和种子得出。软件实现的是伪随机数
强伪随机数，难以预测的随机数
弱伪随机数，易于预测的随机数
特性
随机数有3个特性，具体如下：
随机性：不存在统计学偏差，是完全杂乱的数列
不可预测性：不能从过去的数列推测出下一个出现的数
不可重现性：除非将数列本身保存下来，否则不能重现相同的数列
随机数的特性和随机数的分类有一定的关系，比如，弱伪随机数只需要满足随机性即可，而强位随机数需要满足随机性和不可预测性，真随机数则需要同时满足3个特性。
引发安全问题的关键点在于不可预测性。
伪随机数的生成
我们平常软件和应用实现的都是伪随机数，所以本文的重点也就是伪随机数。
伪随机数的生成实现一般是算法+种子。
具体的伪随机数生成器PRNG一般有：
线性同余法
单向散列函数法
密码法
ANSI X9.17
比较常用的一般是线性同余法，比如我们熟知的C语言的rand库和Java的java.util.Random类，都采用了线性同余法生成随机数。
应用场景
随机数的应用场景比较广泛，以下是随机数常见的应用场景：
验证码生成
抽奖活动
UUID生成
SessionID生成
Token生成
CSRF Token
找回密码Token
游 戏 (随机元素的生成)
洗牌
俄罗斯方块出现特定形状的序列
游戏爆装备
密码应用场景
生成密钥：对称密码，消息认证
生成密钥对：公钥密码，数字签名
生成IV： 用于分组密码的CBC，CFB和OFB模式
生成nonce: 用于防御重放攻击; 分组密码的CTR模式
生成盐：用于基于口令的密码PBE等
0x02 随机数的安全性
相比其他密码技术，随机数很少受到关注，但随机数在密码技术和计算机应用中是非常重要的，不正确的使用随机数会导致一系列的安全问题。
随机数的安全风险
随机数导致的安全问题一般有两种
应该使用随机数，开发者并没有使用随机数;
应该使用强伪随机数，开发者使用了弱伪随机数。
第一种情况，简单来讲，就是我们需要一个随机数，但是开发者没有使用随机数，而是指定了一个常量。当然，很多人会义愤填膺的说，sb才会不用随机数。但是，请不要忽略我朝还是有很多的。主要有两个场景：
开发者缺乏基础常识不知道要用随机数;
一些应用场景和框架，接口文档不完善或者开发者没有仔细阅读等原因。
比如找回密码的token，需要一个伪随机数，很多业务直接根据用户名生成token;
比如OAuth2.0中需要第三方传递一个state参数作为CSRF Token防止CSRF攻击，很多开发者根本不使用这个参数，或者是传入一个固定的值。由于认证方无法对这个值进行业务层面有效性的校验，导致了 OAuth 的CSRF攻击。
第二种情况，主要区别就在于伪随机数的强弱了，大部分(所有?)语言的API文档中的基础库(常用库)中的random库都是弱伪随机，很多开发自然就直接使用。但是，最重要也最致命的是，弱伪随机数是不能用于密码技术的。
还是第一种情况中的找回密码场景，关于token的生成， 很多开发使用了时间戳作为随机数(md5(时间戳)，md5(时间戳+用户名))，但是由于时间戳是可以预测的，很容易就被猜解。不可预测性是区分弱伪随机数和强伪随机数的关键指标。
当然，除了以上两种情况，还有一些比较特别的情况，通常情况下比较少见，但是也不排除：
种子的泄露，算法很多时候是公开的，如果种子泄露了，相当于随机数已经泄露了;
随机数池不足。这个严格来说也属于弱伪随机数，因为随机数池不足其实也导致了随机数是可预测的，攻击者可以直接暴力破解。
漏洞实例
wooyun上有很多漏洞，还蛮有意思的，都是和随机数有关的。
1.应该使用随机数而未使用随机数
Oauth2.0的这个问题特别经典，除了wooyun实例列出来的，其实很多厂商都有这个问题。
Oauth2.0中state参数要求第三方应用的开发者传入一个CSRF Token(随机数)，如果没有传入或者传入的不是随机数，会导致CSRF登陆任意帐号：
唯品会账号相关漏洞可通过csrf登录任意账号
人人网 - 百度 OAuth 2.0 redirect_uir CSRF 漏洞
2.使用弱伪随机数
1) 密码取回
很多密码找回的场景，会发 送给 用户邮件一个url，中间包含一个token，这个token如果猜测，那么就可以找回其他用户的密码。
1. Shopex 4.8.5密码取回处新生成密码可预测漏洞
直接使用了时间函数microtime()作为随机数，然后获取MD5的前6位。
1. substr(md5(print_r(microtime(),true)),0,6);
PHP 中microtime()的值除了当前 服务器 的秒数外，还有微秒数，微妙数的变化范围在0.000000 -- 0.999999 之间，一般来说，服务器的时间可以通过HTTP返回头的DATE字段来获取，因此我们只需要遍历这1000000可能值即可。但我们要使用暴力破解的方式发起1000000次请求的话，网络请求数也会非常之大。可是shopex非常贴心的在生成密码前再次将microtime() 输出了一次：
1. $messenger = $this-system-loadModel('system/messenger');echo microtime()."
";
2.奇虎360任意用户密码修改
直接是MD5( unix 时间戳)
3.涂鸦王国弱随机数导致任意用户劫持漏洞，附测试POC
关于找回密码随机数的问题强烈建议大家参考拓哥的11年的文章《利用系统时间可预测破解java随机数| 空虚浪子心的灵魂》
2) 其他随机数验证场景
CmsEasy最新版暴力注入(加解密缺陷/绕过防注入)
弱伪随机数被绕过
Espcms v5.6 暴力注入
Espcms中一处SQL注入漏洞的利用，利用时发现espcms对传值有加密并且随机key,但是这是一个随机数池固定的弱伪随机数，可以被攻击者遍历绕过
Destoon B2B 2014-05-21最新版绕过全局防御暴力注入(官方Demo可重现)
使用了microtime()作为随机数，可以被预测暴力破解
Android 4.4之前版本的Java加密架构(JCA)中使用的Apache Harmony 6.0M3及其之前版本的SecureRandom实现存在安全漏洞，具体位于classlib/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1PRNG_SecureRandomImpl.java
类的engineNextBytes函数里，当用户没有提供用于产生随机数的种子时，程序不能正确调整偏移量，导致PRNG生成随机序列的过程可被预测。
Android SecureRandom漏洞详解
安全建议
上面讲的随机数基础和漏洞实例更偏重是给攻击者一些思路，这里更多的是一些防御和预防的建议。
业务场景需要使用随机数，一定要使用随机数，比如Token的生成;
随机数要足够长，避免暴力破解;
保证不同用处的随机数使用不同的种子
对安全性要求高的随机数(如密码技术相关)禁止使用的弱伪随机数：
不要使用时间函数作为随机数(很多程序员喜欢用时间戳) Java：system.currenttimemillis() php：microtime()
不要使用弱伪随机数生成器 Java: java.util.Random PHP: rand() 范围很小，32767 PHP: mt_rand() 存在缺陷
强伪随机数CSPRNG(安全可靠的伪随机数生成器(Cryptographically Secure Pseudo-Random Number Generator)的各种参考
6.强伪随机数生成(不建议开发自己实现)
产生高强度的随机数，有两个重要的因素：种子和算法。算法是可以有很多的，通常如何选择种子是非常关键的因素。 如Random，它的种子是System.currentTimeMillis()，所以它的随机数都是可预测的， 是弱伪随机数。
强伪随机数的生成思路：收集计算机的各种，键盘输入时间，内存使用状态，硬盘空闲空间，IO延时，进程数量，线程数量等信息，CPU时钟，来得到一个近似随机的种子，主要是达到不可预测性。
暂时先写到这里
java重放攻击的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java如何防重放、java重放攻击的信息别忘了在本站进行查找喔。
发布于：2022-12-03，除非注明，否则均为原创文章，转载请注明出处。