40 JAVA安全-JWT安全及预编译CASE注入等

jwt加解密：https://jwt.io/#debugger-io

通过前期的WEB漏洞的学习，掌握了大部分的安全漏洞的原理及利用，但在各种脚本语言开发环境的差异下，会存在新的安全问题，其中脚本语言类型PHP、Java、Python等主流开发框架会有所差异。

每个脚本程序语言在开发它web程序这块的时候，不管是它的结构还是它开发语言的特性，这些差异条件会造成一些新的问题，如果说php容易产生那些漏洞，java容易产生那些漏洞，就是因为语言的特性和开发的情况，差异造成的，其中大部分漏洞是围绕php和java两块的，当然在python主流开发框架上，它也有，基本上把php和java讲完之后，是差不多的
java网站上面出现的问题不一定就会在php网站上面产生，同理php的也不可能在java上面产生，但是有些漏洞它是同理，比如说像xss漏洞，它这个在php里面也会产生，在java里面也会产生，而且产生的利用和原理基本上是等同，因为有些漏洞的特性和环境没有直接关系
我们讲这个java web安全就是讲它和其它脚本，例如php有些什么不一样的漏洞，主要是在说这个事情

访问控制是java特有，php很少；身份验证这块，jwt令牌的安全问题也是java特有，php里面很少看到，php有这个功能，但是不会出现问题；组件安全也是不一样的，有些漏洞是特有，不会像其它脚本一样通用的漏洞

SQL Injection(mitigation)

防御sql注入，其实就是session，参数绑定，存储过程这样的注入
// 利用session防御，session内容正常情况下是用户无法修改的

select * from users where user = "'" + session.getAttribute("UserID") + "'";
1

sql语句取数据不是按你发送什么数据就接收什么数据，它是取session里面的，就是登录cookie的数据，这里面的值做为登录的情况，一般session是储存到对方服务器的，他不像cookie，对方服务器上面session的数据，相当于不去操作服务器里面的数据，他是不会有可以伪造的，这种方式能够防御sql注入，其实就是从服务器上面去取固定值，不是让你去网站上面发送数据，他就接收什么数据，这个数据相当于不可控制，这个注入就无法达到我们攻击的目标
// 参数绑定方式，利用了sql的预编译技术

String query = "SELECT * FROM users WHERE last_name = ?";

PreparedStatement statement = connection.prepareStatement(query);

statement.setString(1, accountName);

ResultSet results = statement.executeQuery();
1
2
3
4
5
6
7

我们发送注入、发送代码过去的话，他会把你的参数内容不当做sql命令去执行，等同于就是个字符串，没有任何意义
预编译在java里面是一种很常见的情况，在php里面也可以使用，它里面有一个拓展，有的php版本是支持预编译的

上面说的方式也不是能够绝对的进行sql注入防御，只是减轻。
如参数绑定方式可以使用下面方式绕过。
通过使用case when语句可以将order by后的orderExpression表达式中添加select语句。
java预编译机制里面的安全问题，可以利用到case when，它有一个前提条件，得是order by插入才行，就是涉及到排序功能这里，对方即使使用预编译也能够注入，如果没有order by ，那只能找网上的鸡肋方法，大部分都用不了
java应用注入少，原因就是里面有预制的预编译，能够防护大部分的sql注入攻击，这也就是为什么大家搞src挖漏洞的时候，因为很多src目标是java的应用，那么你找注入肯定是很难的，原因就是因为他的一个语言特性比这个php要更加安全
order by的sql注入功能，他的sql注入指令的功能是排序，也就是说对方操作的一个应用，涉及到排序操作的话，从黑盒这个攻击测试来讲的话，就可以断定对方sql语句中是有order by的一个操作的，那么这个时候就可以采用它来绕过预编译，如果确认对方没有order by的话就GG

演示案例:

Javaweb-SQL注入攻击-预编译机制绕过

#了解预编译机制
https://www.cnblogs.com/klyjb/p/11473857.html
https://www.zhihu.com/guestion/43581628
#参考参数绑定绕过方式 case when 注入

Javaweb-身份验证攻击-JWT修改伪造攻击

#了解JWT传输过程，验证机制
#了解JWT结构，加解密过程及注意事项

注意：
问题来了，因为JWT的声明内容变了，因此签名需要重新生成，生成签名又需要密码，我们没有密码呀？不要慌，我们直接去掉签名就好~修改头部为None

更改完声明是要重新签名，签名需要密匙，none不加密，不加密就可以忽略签名
签名是采用密匙加密的，没有密匙，签名是无法推算出来的，头部和声明可以通过base64的加解密来反逆向

在HTTP传输过程中，Base64编码中的"=“，”+“，”/"等特殊符号通过URL解码通常容易产生歧义，因此产生了与URL兼容的Base64 URL编码

什么是JWT?
JSON web Token （JSON Web令牌）是一种跨域验证身份的方案。JWT不加密传输的数据，但能够通过数宇签名来验证数据未被篡改(但是做完下面的WebGoat练习后我对这一点表示怀疑)。

JWT分为三部分，头部 (Header) ，声明 (clams) ，签名 (signature) ，三个部分以英文句号.隔开。JWT的内容以Base64URI进行了编码。

头部 (Header)
{
“alg”:“HS256”,
“typ”:“JWT”
}
alg
是说明这个JWT的签名使用的算法的参数，常见值用HS256（默认），HS512等，也可以为None。HS256表示HMAC SHA256。
typ
说明这个token的类型为JWT

声明 (Claims)

{
 "exp": 1416471934,
 "user_name": "user",
 "scope": [
   "read"
   "write"
],
"authorities": [
  "ROLE_ADMIN"
  "ROLE_USER"
],
  "client_id":"my-client-with-secret"
}
1
2
3
4
5
6
7
8
9
10
11
12
13

JWT固定参数有：
iss:发行人
exp:到期时间
sub:主题
aud:用户
nbf:在此之前不可用
iat:发布时间
jti:JWT ID用于标识该JWT

签名 (Signature)
服务器有一个不会发送给客户端的密码(secret)，用头部中指定的算法对头部和声明的内容用此密码进行加密，生成的字符串就是JWT的签名。
下面是一个用HS256生成JWT的代码例子
HMACSHA256(base64UrIEncode(header) + “.” +
base64UrIEncode(payload),secret)

1、用户端登录，用户名和密码在请求中被发往服务器
2、(确认登录信息正确后）服务器生成JSON头部和声明，将登录信息写入JSON的声明中(通常不应写入密码，因为JWT是不加密的)，并用secret用指定算法进行加密，生成该用户的JWT。此时，服务器并没有保存登录状态信息。
3、服务器将JWT（通过响应）返回给客户端
4、用户下次会话时，客户端会自动将JWT写在HTTP请求头部的Authorization字段中
5、服务器对JWT进行验证，若验证成功，则确认此用户的登录状态
6、服务器返回响应

jwt就是身份的信息，所以我们更改身份信息，就类似于我们在前期讲过的用cookie来实现管理员的登录，只是说jwt是一种加密的字符串，需要我们进行分析进行逆向
jwt不仅判断身份还判断传输数据，如果这个数据涉及到数据库查询，还会导致sql注入，如果涉及到其它的东西，就会导致其它的漏洞
就是在登录的时候，你把你的登录用户改成admin，然后在jwt的数据包保持统一，那么对方就以为你是admin登录的，登录进去之后，就用admin这个用户执行操作