Reading GitLab Hidden HackerOne Reports and Golang Parameter Smuggling
Fairly simple vulnerability where GitLab had an internal endpoint for their own tracking of H1 reports on
h1.sec.gitlab.net. The researcher found one of these links and discovered the
/a path which would dump all attachments keys, which you could use to re-construct the urls to download attachments.
Post by Microsoft’s 365 Defender research team on an access control issue in TikTok’s Android app. The problem focuses on WebViews and how they interact with deeplinks, which are special hyperlinks that Android supports that applications can setup hooks for. They’re commonly used for internal app communication and routing. WebViews have a “bridge” functionality where a Java bridge class can be exposed and it’s methods can be published and called through the WebView. You can consider the attack that’s detailed as two issues.
One problem is in the deeplink handler for
https://m.tiktok[.]com/redirect, which would take a query parameter to redirect the user. It’s possible to trigger internal deeplinks through the query parameter to call into non-exported activities. This expands the attack surface, though TikTok considers this acceptable.
The more critical issue is in one of the internal schemes
[redacted-internal-scheme]://webview?url=<website>, which would take a URL and load it into the WebView. TikTok has filters in-place to prevent untrusted hosts from being loaded, however, this filtering was somewhat flimsy, and was bypassed by adding two additional parameters to the deeplink. Unfortunately, the Defender team doesn’t go into any more detail here.
A vulnerability in Apache HTTPD’s
mod_proxy reverse proxy module. The issue comes down to an interesting logic bug in
ap_proxy_create_hdrbrgd() where it would clear hop-by-hop request headers via
ap_proxy_clear_connection() after the x-forwarded header addition. This leads to a situation where x-forwarded headers that were passed in a hop-by-hop list immediately get dropped and won’t make it upstream. There’s a few scenarios this could be exploited, particularly where something relies on the x-forwarded headers (such as ExpressJS and it’s trust proxy setting, or certain tomcat valves).
A post by Oxeye which studies a desync attack based on Golang’s
net/url package and some subtle changes that were made to it in Go v1.17, which patched a bug where the
ParseQuery() method would consider semi-colons a valid separator. As per the RFC for the URL spec, while semi-colons are an accepted separator for the path, they aren’t for the query. Similarly, the WHATWG URL specification only lists the ampersand (
&) as a valid separator. As such, other language libraries like nodejs don’t recognize
; as a valid separator, and so the Go maintainers fixed
net/url to conform. In go 1.17, a check was added to
ParseQuery() that would return an error if a semi-colon was present.
The problem is, the URL package’s
Query() routine that calls
ParseQuery() explicitly ignores the error return, making it silently fail. This is a perfect soup for a smuggling attack in instances where a front-end might be running a newer version of Golang and a back-end an older version. On top of that, the
NewSingleHostReverseProxy() method would take a raw query string and send it as-is without parsing it. In these cases, the front-end could ignore the semi-colon separated parameter, whereas it slips through to the backend that parses it as a separate parameter. This was found in multiple open source projects, including Harbor (open source artifact registry), and HTTP reverse proxies/routers Traefik and Skipper.