【问题标题】:IBM Appscan Security Vulnerability SQL injectionIBM Appscan 安全漏洞 SQL 注入
【发布时间】:2014-09-24 17:16:12
【问题描述】:

我有应用程序扫描,我通过它扫描我的项目,但在类似的语句中

 preparedStatement = conn.prepareStatement(sql);

存在 SQL.Injection 漏洞,我正在使用 esapi api 来设置准备好的语句中的值,例如

preparedStatement.setString(1 , OracleEncoder.encode(code) ); 

OracleEncoder 正在这样做

   ESAPI.encoder().encodeForSQL( ORACLE_CODEC,param);

知道如何修复这个漏洞吗?

【问题讨论】:

标签: java security jdbc


【解决方案1】:

您不需要将绑定参数编码到preparedStatement,

// preparedStatement.setString(1 , OracleEncoder.encode(code) ); 
preparedStatement.setString(1 , code ); 

PreparedStatement.setString() JavaDoc 的相关部分说,

驱动程序在将其发送到数据库时将其转换为 SQL VARCHAR 或 LONGVARCHAR 值(取决于参数的大小相对于驱动程序对 VARCHAR 值的限制)。

【讨论】:

  • 好的,关于 IBM 应用程序扫描漏洞,因为它抱怨当我写你的方式或我的方式时
  • @Haider 你的方法根本行不通。至于 IBM 应用扫描,请联系 IBM。
【解决方案2】:

假设您正在进行静态分析,appscan 没有标记您的 ESAPI API,您应该在 appscan 中为您的 encodeForSQL 方法创建一个 SQLi 验证器标记。这样,下次扫描时,扫描引擎将获取新标记并了解 SQLi 威胁已被 esapi 调用消除。

【讨论】:

    【解决方案3】:

    如果您在代码中使用 ESAPI 库函数和准备好的语句,那么您可以将此问题标记为不是问题。 Prepared statement 是避免 SQL 注入的一种缓解技术。

    preparedStatement = conn.prepareStatement(sql);
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-12-05
      • 2020-08-21
      • 2013-04-20
      • 1970-01-01
      • 2019-05-03
      • 1970-01-01
      • 1970-01-01
      • 2017-11-24
      相关资源
      最近更新 更多