JAVA 在 SQL执行当中 分为3种写法：
JDBC注入分析
Mybatis注入分析
Hibernate注入分析
JDBC 模式不安全JAVA代码示例部分特征
定义了一个 sql 参数 直接让用户填入id的内容
一个最简单的SQL语句就被执行了
使用安全语句却并没有被执行
Mybatis： # 和 $的区别
并没有看见SQL 语句 为什么
因为这个JAVA是调用了两个库这两个库里面有调用SQL的函数
其中不安全的示例代码在user.java的库
在MyBatis中，# 和 $ 用于表示不同的参数插入方式，它们的主要区别在于如何处理参数插入的安全性和方式。
# 标记（Prepared Statement）
- 安全性: 使用
#标记，MyBatis 会将参数作为PreparedStatement的参数进行处理，自动防止SQL注入攻击。 - 占位符: 参数会被替换为一个
?占位符，然后在执行SQL时，数据库驱动会将实际的参数值绑定到占位符上。 - 优点: 安全性高，适用于动态参数的情况。
- 示例: sql
复制代码
在这个例子中，SELECT * FROM users WHERE name = #{name}#{name}表示参数name，在生成的SQL语句中会被替换为一个?，然后在执行时再绑定实际的参数值。
$ 标记（字符串替换）
- 安全性: 使用
$标记时，MyBatis 直接将参数的值插入到SQL语句中，不进行任何转义或保护，因此存在SQL注入风险。 - 直接插入: 参数值会被直接拼接到SQL语句中，这在处理列名、表名等结构性元素时比较有用。
- 优点: 灵活性高，但不适合动态参数的使用，容易产生安全隐患。
- 示例: sql
复制代码
这里，SELECT * FROM users ORDER BY ${column}${column}会被替换为传入的参数值，例如name，结果是生成类似ORDER BY name的SQL语句。
选择使用的建议
- 对于动态值（如用户输入的字符串、数值等），应该使用
#来防止SQL注入。 - 对于动态SQL语句的结构部分（如列名、表名等），如果需要使用动态插入，可以使用
$，但需确保传入的值是可信的，不会导致SQL注入。
Hibernate:
安全写法 写完name=name后先进行了预编译
不安全写法直接拼接
总结
实操-靶场
1.先分析SQL用的哪种模式
在路径中找特征 jdbc mybatis hibernate 有的写不完整 搜索myba
找到了是myba并且知道了版本
找到了包 或许SQL就是用这个实现的 我们需要进入 看看
继续翻找找到了真正源码一般在resources
article 上下双方的目录是一一对应的
搜不到 # 有问题不知道什么原因没有进行编译 网上搜搜原因老师随便点几下就好了 说不是编译的原因
2.然后找到成功
总结又加了一条 in
因为有IN 所以程序员只能写$value
这个时候我们就要去实地去测试有没有对那些SQL语句进行过滤
3.把定义的id名进行搜索
搜索点了第一个含有这个函数声明的地方但是没看见任何内容
老师Ctrl shift +h
单击进去看调用
然后审计完之后，发现是要管理员账号登录进去之后 才能进行的注入，需要得到管理员cookie，然后抓包后修改好包的路径 然后 cookie加上 然后把包的内容保存到1.txt
sqlmap.py -r 1.txt 对包进行扫描
对存在注入点加上*让sqlmap识别到
但是为什么在请求体内加上
参数articelld*进行注入我是没看懂的我没有审计到 感觉应该是articlid 这样的话参数我就懂了
有的地方看起来有注入 如下 全是美元符号
为什么注入不成功 因为有int 把我们的符号全变为整数