apache / apache/servicecomb-java-chassis
servicecomb 2.8.14版本接口入参校验失败后抛出的异常信息存在内部代码结构和行号等信息
- Dominant language
- Java
- Stars
- 1.9k
- Forks
- 814
- Avg merge
- 8d 23h
- Merged PRs (30d)
- 1
Description
#### 背景
当 接口调用传递的body跟接口定位的入参不一致时,接口返回的message信息存在内部代码结构和行号等信息
#### 复现demo
接口入参定义如下:
```
public class CommonReq {
private String name;
private Integer type;
}
```
http请求传递的body如下:
```
{
"name": "jedrek",
"type": "hard"
}
```
报错信息如下:
{
"message": "Parameter is not valid for operation [xxx]. Parameter is [commonReq]. Processor is [body]. Message is [Cannot deserialize value of type `java.lang.Integer` from String \"hard\": not a valid `java.lang.Integer` value\n at [Source: (org.apache.servicecomb.foundation.vertx.stream.BufferInputStream); line: 3, column: 13] (through reference chain: CommonReq[\"type\"])]."
}
这个打印信息感觉存在安全问题,暴露了接口的内部实现,可否针对于这种场景,对打印的异常message进行调整
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the request-body deserialization error handling that produces the reported Parameter, Processor, and Message response. Reproduce the CommonReq payload with a non-integer type, then verify that the response no longer exposes internal code structure, source locations, or implementation details while still communicating that the input is invalid.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100