小迪（40day）
第40天：安全开发-JavaEE应用&SpringBoot框架&JWT身份鉴权&打包部署JAR&WAR
#SpringBoot-身份鉴权-JWT 技术
JWT(JSON Web Token)是由服务端用加密算法对信息签名来保证其完整性和不可伪
造；
Token 里可以包含所有必要信息，这样服务端就无需保存任何关于用户或会话的信息； JWT 用于身份认证、会话维持等。由三部分组成，header、payload 与 signature。 参考：https://cloud.tencent.com/developer/article/2101634
1、引入依赖
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>3.4.0</version>
</dependency>
2、创建 JWT
JWT.create()
3、配置 JWT
JWT.create()
//header
.withHeader(map)
//payload
.withClaim("userid",id)
.withClaim("username",user)
.withClaim("password",pass)
//signature
.sign(Algorithm.HMAC256("xiaodisec"));
4、解析 JWT
//构建解密注册
JWTVerifier jwt =
JWT.require(Algorithm.HMAC256("xiaodisec")).build();
//解密注册数据
DecodedJWT verify = jwt.verify(jwtdata);
//提取解密数据
Integer userid = verify.getClaim("userid").asInt();
5、安全问题
参考：https://cloud.tencent.com/developer/article/2101634
#SpringBoot-打包部署-JAR&WAR
参考：https://mp.weixin.qq.com/s/HyqVt7EMFcuKXfiejtfleg
SpringBoot 项目打包在 linux 服务器中运行:
①jar 类型项目
jar 类型项目使用 SpringBoot 打包插件打包时，会在打成的 jar 中内置 tomcat 的 jar，所以使用jdk直接运行iar即可，jar项目中功能将代码放到其内置的tomeat中运行。
②war类型项目
在打包时需要将内置的tomcat插件排除，配置servlet的依赖和修改pom.xm1，然后将war文件放到tomcat安装目录webapps下，启动运行tomcat自动解析即可。
SpringBoot-身份鉴权-JWT 技术
JWT的验证过程：
新建项目
导入依赖：
<!-- https://mvnrepository.com/artifact/com.auth0/java-jwt -->
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>3.18.0</version>
</dependency>
JWT生成
运行：
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 header部分
eyJwYXNzd29yZCI6ImExMjM0NTYiLCJ1c2VyaWQiOjEsInVzZXJuYW1lIjoiYWRtaW4ifQ payload部分
igPZejKdcc0gK8wMWSjxQgSOI4cKdPBJaHMCG3iNcV0 sign部分
可以拿去jwt解密
这里的secret很重要，如果想着去修改解密后的数据然后再次加密发送加密的数据是不可行的，还需要知道密钥才可以生成合法签名
JWT解密
运行
第一行是加密部分，第二行是解密部分
web
改成web来触发
静态表单提交页面
运行
creat：
跳转到了jwtcreat并且创建了jwt
直接用if语句来判断admin
运行，admin提交
得到的数据解密
如果输入的不是admin解密就不通过
安全问题
攻击者要模拟用户去登录，一般逻辑就是先抓包得到jwt数据之后解密，然后修改要登录的用户名，比如：
得到的jwt数据：
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyaWQiOjEsInVzZXJuYW1lIjoiYWRtaW4ifQ.lTpcRd_DBqTUYz7tCHJ5hHs4A_baKcm2cdGalkv6YoY
解密，把admin改成xiaodi
然后把修改后的数据拿去
报错了
显示就是签名不通过，所以解密是需要密钥的，也就是代码中的
总结
🔹 1. JWT 的基本结构
JWT 由三部分组成，用 . 分隔：
header.payload.signature
- header：说明签名算法（如
HS256、RS256） - payload：存放业务数据（如用户ID、过期时间）
- signature：签名（保证前两部分没被篡改）
🔹 2. 开发角度：JWT 验证流程
一个典型的验证过程：
- 接收 JWT
客户端发送请求时会在Authorization: Bearer <jwt>头里带上 token。 - 解析 JWT
服务器把header.payload.signature拆出来。 - 验证签名
- 如果是 HS256（对称加密）：用同一个密钥（server持有）去校验签名。
- 如果是 RS256（非对称加密）：用 私钥签发，公钥验证。
- 检查声明
exp（过期时间）iat（签发时间）aud（受众）iss（签发方）
→ 确保 token 没过期、没越权。
- 信任 payload
验证通过后，才会认为里面的user_id等信息可信。
🔹 3. 常见漏洞利用点
JWT 的漏洞一般出在 验证环节，主要几种：
🕳️ (1) 不验证签名
有些开发者直接用 JWT.decode() 解析 payload，没校验签名。
👉 攻击者可以伪造 token，随意改 user_id。
🕳️ (2) alg=none 漏洞
早期 JWT 库支持 alg: none，表示“不签名”。
👉 攻击者修改 header：
{ "alg": "none", "typ": "JWT" }
再生成：
header.payload.
很多旧的库会直接通过验证，造成绕过。
🕳️ (3) HS256 vs RS256 混淆
- RS256：私钥签发，公钥验证。
- HS256：对称加密，双方用同一密钥。
如果服务器错误地允许 两种算法：
- 攻击者把 header 改成
HS256，再用 公钥 当作 secret 去生成签名。 - 由于 server 会拿“公钥”当 secret 去校验，结果就能伪造 token。
🕳️ (4) 弱密钥/泄露
如果用 短弱密钥（比如 123456），攻击者可以暴力破解签名。
或是代码泄露、配置文件泄露了 secret。
🕳️ (5) 没校验 exp / aud
有的开发者只校验签名，但不校验 exp。
👉 攻击者拿一个早就过期的 token，仍能登录。
🔹 4. 开发防护要点
- 必须验证签名（不能只 decode）
- 禁用 alg=none
- 强密钥（>=256 bits，随机）
- 指定算法（只允许 RS256 或 HS256，不能混用）
- 校验 claims：
exp、iat、aud、iss等 - token 生命周期要短，敏感操作最好再加二次验证（MFA）
- 刷新机制：配合 refresh token，避免长期有效的 access token 被盗用。
🔹 5. 攻击者利用流程（举个例子）
- 拿到正常用户的 JWT。
- 修改 payload，比如
{"role":"admin"}。 - 如果服务器没验证签名或存在
alg=none，直接就能伪造管理员 token。 - 请求后台 → 以管理员身份成功进入。
👉 总结一句：
JWT 本身很安全，问题大多是开发者“验证不严谨”。
文章：JWT安全漏洞以及常见攻击方式_jwt漏洞利用-CSDN博客
SpringBoot-打包部署-JAR&WAR
JAR
idea的maven
下clean再package，再新出现的target目录下就会有jar包了
然后打开会发现报错了
确保这两个是这样的
再次打包运行
访问8080端口
WAR
pom.xml文件修改
加一个war，主导类加一些
清除之后打包得到war，拿到tomcat的webapps目录下，启动tomcat得到对应的war的目录，访问目录
浙公网安备 33010602011771号