A proxy server is a go‑between or intermediary server that forwards requests for content from multiple clients to different servers across the Internet. A reverse proxy server is a type of proxy server that typically sits behind the firewall in a private network and directs client requests to the appropriate backend server. A reverse proxy provides an additional level of abstraction and control to ensure the smooth flow of network traffic between clients and servers.

Why is used?

• Load balancing — A reverse proxy server can act as a “traffic cop,” sitting in front of your backend servers and distributing client requests across a group of servers in a manner that maximizes speed and capacity utilization while ensuring no one server is overloaded, which can degrade performance. If a server goes down, the load balancer redirects traffic to the remaining online servers.
• Web acceleration — Reverse proxies can compress inbound and outbound data, as well as cache commonly requested content, both of which speed up the flow of traffic between clients and servers. They can also perform additional tasks such as SSL encryption to take load off of your web servers, thereby boosting their performance.
• Security and anonymity — By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network.

So basically I escalated a REVERSE PROXY to 2 SQLi and 3 RCE on the internal servers and a couple of other issues. There was information disclosure and other problems found.

To find the reverse proxy you can use Burp or DNSBIN better to catch the DNS request.

You need to modify the requests like this

GET / HTTP/1.1
Content-Length: 95
Content-Type: application/x-www-form-urlencoded

to

GET http://burpcollaborator_url HTTP/1.1
Content-Length: 95
Content-Type: application/x-www-form-urlencoded

Then you need to check the DNS responses, but filter a lot of WAF and manual pingbacks you get because most of the time is false positive

If you get a DNS response only and not a HTTP one, don’t give up. It means other ports on the same internal portal might be accessible, just not 80 or 443. Or some internal sites cannot be shown by the reverse proxy. You might need to trick with adding an url or subdomain that pretends to be valid.

Once you get access to an internal asset, you need to use the reverse proxy and test it like it’s an external website

Of course is a big are to explore and many bypass combinations to try like:

GET https://external_site.com@internal_site:4566 HTTP1/1 etc

I believe this are is not fully explored, even if the bug type is not new. Probably similar issues can be found with another name or attacks work with other techniques. Like a reverse proxy can also be exploited via another url parser issue etc. But I encourage everyone to look more here.

The attacker just needs to create a special URL (/img/..%2faccount/attacker/), so Nuster applies an “aggressive caching” rule, still, the web app returns a response of self XSS (it sees ‘/account/attacker/`). The response with an XSS payload will be cached by Nuster (with the key: Host + /img/..%2faccount/attacker/), so the attacker will be able to misuse this cache to XSS attack other users of the web application.From the self-XSS, we’ve got a usual XSS.