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 把我们的符号全变为整数