cve搭建
Some time ago I wrote about unsafe deserialization and DoS vulnerabilities I’ve discovered in Apache Olingo. This post describes one more issue in the library. This time, it’s a little flaw in the Olingo client which may allow sending some HTTP requests to arbitrary URLs. The issue has been fixed in the 4.7.1 release.
前一段时间，我写了关于在Apache Olingo中发现的不安全的反序列化和DoS漏洞的文章。 这篇文章描述了库中的另一个问题。 这次，这是Olingo客户端中的一个小缺陷，它可能允许将一些HTTP请求发送到任意URL。 该问题已在4.7.1版本中修复。
In case you don’t know, Apache Olingo is a Java library that implements the Open Data Protocol (OData). This protocol allows the creation and consumption of queryable and interoperable RESTful APIs in a simple way.
如果您不知道，Apache Olingo是一个实现开放数据协议(OData)的Java库。 该协议允许以简单的方式创建和使用可查询和可互操作的RESTful API。
Originally published at https://blog.gypsyengineer.com
最初发布在 https://blog.gypsyengineer.com
问题 (The issue)
The OData protocol runs over HTTP. Apache Olingo offers an OData client. In particular, the library has the AsyncRequestWrapperImpl class that can send a request to an OData server and then processes a response. When a client asks the OData server to create a new record, the server may not be able to create it right away. In this case, the server may reply with a 202 status code and include the Location header with a URL. The class saves this URL for the future:
OData协议通过HTTP运行。 Apache Olingo提供了一个OData客户端。 特别是，该库具有AsyncRequestWrapperImpl类，该类可以将请求发送到OData服务器，然后处理响应。 当客户端要求OData服务器创建新记录时，该服务器可能无法立即创建它。 在这种情况下，服务器可以使用202状态代码进行回复，并在Location标头中包含URL。 该类将为将来保存以下URL：
private void retrieveMonitorDetails(final HttpResponse res) {
Header[] headers = res.getHeaders(HttpHeader.LOCATION);
if (ArrayUtils.isNotEmpty(headers)) {
this.location = URI.create(headers[0].getValue());
...Then, the class can send a GET request to the URL to check if the record is ready:
然后，该类可以将GET请求发送到URL，以检查记录是否准备就绪：
public boolean isDone() {
if (response == null) {
// check to the monitor URL
final HttpResponse res = checkMonitor(location);
...
public R getODataResponse() {
HttpResponse res = null;
for (int i = 0; response == null && i < MAX_RETRY; i++) {
res = checkMonitor(location);
...
protected final HttpResponse checkMonitor(final URI location) {
if (location == null) {
throw new AsyncRequestException(
"Invalid async request response. Missing monitor URL");
}
final HttpUriRequest monitor = odataClient.getConfiguration()
.getHttpUriRequestFactory().create(HttpMethod.GET, location);Or, it can even send a DELETE request:
或者，它甚至可以发送DELETE请求：
public ODataDeleteResponse delete() {
final ODataDeleteRequest deleteRequest = odataClient.getCUDRequestFactory()
.getDeleteRequest(location);
return deleteRequest.execute();
}
...
public AsyncResponseWrapper asyncDelete() {
return odataClient.getAsyncRequestFactory().getAsyncRequestWrapper(
odataClient.getCUDRequestFactory().getDeleteRequest(location)).execute();
}The problem is that the class doesn’t check if the URL from the Location header belongs to the server. As a result, the server can trick the client to send a request to an arbitrary URL. For example, the URL can point to a private resource that is accessible by the client but not by the server.
问题在于该类不会检查Location标头中的URL是否属于服务器。 结果，服务器可以欺骗客户端以将请求发送到任意URL。 例如，URL可以指向可由客户端但不能由服务器访问的私有资源。
The AsyncBatchRequestWrapperImpl class also has the same issue.
AsyncBatchRequestWrapperImpl类也有相同的问题。
The issue was discovered during code review.
该问题是在代码检查期间发现的。
解决方案 (The solution)
The issue has been fixed by adding a check that makes sure that a URL from the Location header belongs to the server. The check now is implemented in the checkLocation() method which verifies that the scheme, the domain names and the port match with the server's URL:
通过添加检查以确保来自Location标头的URL属于服务器，已解决了该问题。 现在，在checkLocation()方法中实现检查，该方法验证方案，域名和端口是否与服务器的URL匹配：
private URI checkLocation(URI uri) {
if (!this.uri.getScheme().equals(uri.getScheme())) {
throw new AsyncRequestException("Unexpected scheme in the Location header");
}
if (!this.uri.getHost().equals(uri.getHost())) {
throw new AsyncRequestException("Unexpected host name in the Location header");
}
if (this.uri.getPort() != uri.getPort()) {
throw new AsyncRequestException("Unexpected port in the Location header");
}
return uri;
}我的应用程序容易受到攻击吗？ (Is my application vulnerable?)
The answer to this question highly depends on how a particular application uses Apache Olingo.
这个问题的答案高度取决于特定应用程序如何使用Apache Olingo。
First, if the application doesn’t use the AsyncRequestWrapperImpl or AsyncBatchRequestWrapperImpl classes, then it's not affected.
首先，如果应用程序不使用AsyncRequestWrapperImpl或AsyncBatchRequestWrapperImpl类，则不会受到影响。
If the application uses the classes, then the following questions may help to understand how an attacker can take advantage of the issue in these classes:
如果应用程序使用这些类，则以下问题可能有助于了解攻击者如何利用这些类中的问题：
- Can the application connect to an untrusted server? 应用程序可以连接到不受信任的服务器吗？
- Is there a way how someone can trick the application to send a request to an untrusted server? 有人可以欺骗应用程序将请求发送到不受信任的服务器吗？
- Is there a way how an attacker can modify the data between client and server? 攻击者是否有办法修改客户端和服务器之间的数据？
If the answer to at least one of those questions is more yes rather than no, then the application is likely affected.
如果对这些问题中至少一个的回答是“是”而不是“否”，则该应用程序可能会受到影响。
结论 (Conclusion)
The issue doesn’t look serious because it may be quite difficult for an adversary to exploit it. Nevertheless, it may be better to update Apache Olingo to 4.7.1 to stay on the safe side.
这个问题看起来并不严重，因为对手可能很难利用它。 不过，最好还是将Apache Olingo更新到4.7.1，以保持安全。
Originally published at https://blog.gypsyengineer.com
cve搭建