Before we begin we would like to inform you that the content (X-Forwarded-For for API vulnerabilities) is only for “Educational Purposes” and we do not entertain or take responsibility for any misuse and all the information is publically available.
APIs are the backbone for communication between any two applications, let it be for a website that wants to accept payments for orders or whether an application wants to update user data in its database, API serve as a lifeline for all these communications. But with growing usage, there’s always scope for security vulnerabilities.
X-Forwarded-For is an HTTP header, that is used to find the originating client IP address for the clients connecting through proxy, load balancers or any intermediary devices, this header can be used to exploit a potential vulnerability in the API, let’s see how.
X-Forwarded-For role in API
Whenever an API communication is initiated between a client and the server through API, the server sanitizes inputs based on client’s IP-address, the IP address is found using the X-Forwarded-For header if the communication goes through multiple intermediary devices.
When the communication rules of the API don’t authorize accessing the API endpoints from IP addresses outside the server’s internal network or outside the trusted networks the server might throw an error which can look something like ” not allowed from this IP address”.
This error is caused when the user tries to reach the API endpoint directly and the endpoint doesn’t recognise the IP address as trusted, this can be bypassed by using the “X-Forwarded-For” HTTP header.
Checking for API vulnerability using X-Forwarded-For
Step-1: Changing the Host address
Once you intercept an HTTP GET request using proxy tools like BurpSuite or Caido, it is recommended to forward the response to the repeater before proceeding to the next step. Once in the repeater add the “X-FORWARDED-FOR: 127.0.0.1”, this sets the client origin IP address to 127.0.0.1 tricking the server.
As we can observe here when the localhost address is provided the error changes to “Meethod Not allowed” meaning the server is tricked with the IP address. For most of the cases providing the localhost address works but in some scenarios, the server expects specific IP addresses specifically addresses that are trusted or within the server’s internal network.
Step-2: Trying the Post request
Once we are sure with the API or the server accepting requests because of the change in X-Header-For, we can now try and send POST requests to the server, here we tried to create a user after we found out that the POST request here needs a “username” and “password”. It is necessary for you as a hacker to know what serialization format you are dealing with before you play with the requests.
Here we tried to give a JSON input and the API created a user using the HTTP post request.
Part 3: check whether you are now able to communicate with the API endpoint
As you have created a user by manipulating the “X-Forwarded-For” HTTP header you have now exploited the vulnerability as the input is not sanitized by the server, now as we created the user we can now check our access by visiting the endpoint again.
Here, the Host is dopo7rij.eul.ctfio.com which is the site initiating the communication with the API, whereas the POST HTTP response method with value: \by\ap-xip/api/auth/register is the endpoint, we can know about these endpoints by reading the API documentation disclosed by the web application or the open API documentation.
As we visit the API endpoint with the URL : dopo7rij.eul.ctfio.com\by\ap-xip/, we are asked for login credentials and now we can provide the credentials which we have previously used to create a user using POST request.
After this, we are now successfully logged in:
Conclusion
This is one of the ways to check for API vulnerabilities using “X-Forwarded-For” HTTP headers, we can also further exploit the API by checking for XSS, IDOR and upload vulnerabilities if there’s scope.
Thanks to NahamSec