显示安全漏洞的zap工具，但我们在源代码中找不到这些漏洞？

Question

漏洞显示为：-

1. SQL注入- SQLite

方法： GET

参数：查询

攻击：‘case随机else (10000000)当不为空时，“Attack "”end

证据:使用参数值‘case随机性took (10000000)在非空时使用“”随机took(10000000)来控制查询时间，这会导致请求占用542毫秒，参数值’case随机took(100000000)时不为空，而“query”结束--这会导致请求花费900毫秒，而原始的未修改查询值查询花费167毫秒。

1. 基于SQL注入- Oracle时间的

方法： GET

参数：查询

攻击：字段:查询值查询和存在(从双并选择UTL_INADDR.get_host_name('10.0.0.1')从双并选择UTL_INADDR.get_host_name('10.0.0.2')从双并选择UTL_INADDR.get_host_name('10.0.0.3')从双重联合选择UTL_INADDR.get_host_name('10.0.0.4')从双重联合选择UTL_INADDR.get_host_name('10.0.0.5')

1. 高级SQL注入- Oracle和基于时间的盲

方法： GET

参数：查询

2972=DBMS_PIPE.RECEIVE_MESSAGE(CHR(113)||CHR(65)||CHR(80)||CHR(114),5)攻击：查询和攻击

1. SQL注入- MsSQL

方法： GET

参数：查询

攻击：查询WAITFOR延迟'0:0:15‘--

1. SQL注入-高超声速SQL -基于时间的

方法： GET

参数：查询

攻击：字段:查询，值"；从INFORMATION_SCHEMA.SYSTEM_COLUMNS中选择"java.lang.Thread.sleep"(15000)，其中TABLE_NAME = 'SYSTEM_COLUMNS‘和COLUMN_NAME = 'TABLE_NAME’

1. 基于时间的SQL注入- PostgreSQL

方法： GET

参数：查询

攻击：字段:查询，转换时的值大小写(pg_sleep(15)作为varchar) > '‘然后0 query 1结束

1. SQL注入- MySQL

方法： GET

参数：查询

攻击：查询/睡眠(15)

1. 高级SQL PostgreSQL > 8.1堆叠查询(注释)

方法： GET

参数：查询

攻击：查询；选择PG_SLEEP(5)--

1. 高级SQL注入- Oracle堆栈查询(DBMS_PIPE.RECEIVE_MESSAGE -注释)

方法： GET

参数：查询

DBMS_PIPE.RECEIVE_MESSAGE(CHR(105)||CHR(122)||CHR(102)||CHR(108),5)攻击：攻击：2018年2月；从DUAL中选择

1. 高级SQL注入- Microsoft SQL Server/Sybase基于时间的盲。

方法： GET

参数：查询

CHAR(48)+CHAR(58)+CHAR(48)+CHAR(58)+CHAR(91)+CHAR(83)+CHAR(76)+CHAR(69)+CHAR(69)+CHAR(80)+CHAR(84)+CHAR(73)+CHAR(77)+CHAR(69)+CHAR(93) 攻击：查询) WAITFOR、和(1972=1972 )

我们的所有源代码都遵循给定的示例：

public interface UserRepository extends JpaRepository<User, Long> { @Query("select u from User u where u.firstname = :firstname or u.lastname = :lastname") User findByLastnameOrFirstname(@Param("lastname") String lastname, @Param("firstname") String firstname); }

Answer 1

选择一个基于时间的攻击并重新运行它-您可以通过右键单击ZAP中的警报并选择'Open/Resend with Request‘来实现这一点。检查以查看请求花费了多长时间(它显示在对话框的底部)--是否与攻击所用的延迟时间相同(或稍多一点)？如果是这样的话，试着增加延迟和重发--现在是否需要更长的时间？

如果时间受到攻击中指定的时间的影响，那么您将有一个SQL注入漏洞。

为什么我没有提到你发布的源代码呢？那是因为我不知道这些是否都是相关代码:)

您可能还想尝试在代码上使用静态分析器--它可能会显示大量的假阳性，但您可以只关注它报告的任何SQL注入漏洞。