github / github/codeql

LGTM.com - Java - Lost type information leads to incomplete path and false positive

未关闭
#2,332 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
false-positive Java
主要语言
CodeQL
星标
10.1k
派生
2.1k
平均合并
2 天 15 小时
30 天内合并 PR
141

描述

**Description of the false-positive**

It looks like the query language is connecting sources and sinks through a type checking system that is interpreting methods like `Object::toString` when called on `Object` when at runtime that type will be `String` to be the same as `MyCustomType::toString`.

**URL to the alert on the project page on LGTM.com**
https://lgtm.com/projects/g/spring-projects/spring-framework/snapshot/a21fcec7555409e8859aba85fb2fe95d53760f80/files/spring-web/src/main/java/org/springframework/web/context/support/HttpRequestHandlerServlet.java?sort=name&dir=ASC&mode=heatmap#xe877feaabe7d1240:1

**Analysis**

QL Correctly identifies a source of user-supplied data and correctly tracks it to a place where it is used in the `toString` method.

![part1](https://user-images.githubusercontent.com/1323708/68895831-258ee800-06f8-11ea-9d92-a62439e7004b.png)

Now we have some arbitrary location in the codebase where `toString` is called on `Object`.
![part1a](https://user-images.githubusercontent.com/1323708/68895934-5f5fee80-06f8-11ea-9322-79a86a6ed883.png)

Now we see where those code paths allow this `toString` value to be returned up the stack.

![part2](https://user-images.githubusercontent.com/1323708/68896014-8dddc980-06f8-11ea-8e27-ff90071a49fc.png)

Now we get to the sink location. However, we see that `StringUtils.arrayToDelimitedString` is being passed a `String[]` not a `ServletWebRequest` that would mean this was indeed a vulnerability.

![part3](https://user-images.githubusercontent.com/1323708/68896062-aa7a0180-06f8-11ea-85a1-d35c82ed48a7.png)

TL;DR: Looks like a type confusion issue? Or perhaps there's no logic for detecting the true type that `toString` will be called on.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。