项目经过扫描扫出来36个数据越权的高危漏洞,看了看这些问题和报告中给的修改建议

Access Control: Database (36 issues)
Abstract
如果没有适当的 access control,就会执行一个包含用户控制主键的 SQL 指令,从而允许攻击者访问未经授
权的记录。
Explanation
Database access control 错误在以下情况下发生: 1. 数据从一个不可信赖的数据源进入程序。 2. 这个数据
用来指定 SQL 查询中主键的值。 示例 1: 以下代码使用可转义元字符并防止出现 SQL 注入漏洞的参数化语
句, 以构建和执行用于搜索与指定标识符 [1] 相匹配的清单的 SQL 查询。您可以从与当前被授权用户有关的
所有清单中选择这些标识符。
...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...
问题在于开发者没有考虑到所有可能出现的 id 值。虽然界面生成了属于当前用户的清单标识符列表,但是攻
击者可以绕过这个界面,从而获取所需的任何清单。由于此示例中的代码没有执行检查以确保用户具有访问
所请求清单的权限,因此它会显示任何清单,即使此清单不属于当前用户。 有些人认为在移动世界中,典型
的 Web 应用程序漏洞(如 Database access control 错误)是无意义的 -- 为什么用户要攻击自己?但是,谨
记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的
可能性很高,它们会强制扩展移动应用程序的攻击面(包括跨进程通信)。 示例 2: 以下代码会调整
Example 1 以适应 Android 平台。
...
String id = this.getIntent().getExtras().getString("invoiceID");
String query = "SELECT * FROM invoices WHERE id = ?";
SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE,
null);
Cursor c = db.rawQuery(query, new Object[]{id});
...
许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 Struts 和 Spring MVC)。为了突出显示未经
验证的输入源,该规则包会对 Fortify Static Code Analyzer( Fortify 静态代码分析器)报告的问题动态重新调
整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功
能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程, Fortify 软件安全研究团队开发了
Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
Recommendation
与其靠表示层来限制用户输入的值,还不如在应用程序和数据库层上进行 access control。任何情况下都不允
许用户在没有取得相应权限的情况下获取或修改数据库中的记录。每个涉及数据库的查询都必须遵守这个原
则, 这可以通过把当前被授权的用户名作为查询语句的一部分来实现。 示例 3: 以下代码实现的功能与
Example 1 相同,但是附加了一个限制,以验证清单是否属于当前经过身份验证的用户。
...
userName = ctx.getAuthenticatedUserName();
id = Integer.decode(request.getParameter("invoiceID"));
String query =
"SELECT * FROM invoices WHERE id = ? AND user = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
stmt.setString(2, userName);
2021年8月17日 下午5:04
© Copyright [2008-2021] Micro Focus or one of its affiliates.
7
ResultSet results = stmt.execute();
...
下面是 Android 的等同内容:
...
PasswordAuthentication pa = authenticator.getPasswordAuthentication();
String userName = pa.getUserName();
String id = this.getIntent().getExtras().getString("invoiceID");
String query = "SELECT * FROM invoices WHERE id = ? AND user = ?";
SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE,
null);
Cursor c = db.rawQuery(query, new Object[]{id, userName});
...
 

上面是报告中的描述,感觉没多大鸟用,网上搜了下相关的帖子,大部分也都得抄的这段,有用的帖子没几个。

下面两个帖子感觉靠谱点

解決 Fortify Access Control: Database_¥三石的博客-CSDN博客_access control database fortify

部分Fortify代码扫描高风险解决方案_人生路且修且行的博客-CSDN博客_access control database fortify

我项目中遇到的情况:一个方法需要查询角色的授权关系,需要两表关联查询,就是要所有符合条件的数据,有什么好越权的,简直莫名其妙了,代码检查工具本来是规范代码的,现在反而成了铁律了,不改不给过。我开一个路面清扫车,在路边前行清扫路边尘土,你非得给我扯什么交规禁止我在非机动车道行驶。

还有一些查询是用mapper写的sql,多表关联的,入参的变量字段既不带id,也不是主键 都不知道怎么改

我还是妥协了,谁让甲方是爸爸呢?

为了应付这类检查我有3中处理方式

1 原来是mapper里写sql的改为querywarp查询,尤其是一些单表的

2 如果是没什么必要的数据库查询删了

Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐