API Security Testing (Part — 2)

Hi all, I took a long gap after publishing the first part of API Security Testing. I was occupied with my new job, life in a new city and my CISSP exam which I failed. Will tell you my CISSP journey some other day when I will clear it. Here we go…..

As I told you earlier, the API Sec Test is a complicated area for most of the Pen tester. We should not act as a script kiddie while testing the security part. Though there are many vulnerabilities which could be found. I would narrow down focus to important flaws. It might require a third part to complete the series.

XXE and SSRF are two major vulnerabilities in API end points now. The screenshots I have used here are from PortSwigger Academy as I cannot use my real-time screenshots. Confidentiality matters!!

Step 5: XXE

XXE — XML external entity (XXE) injection

XML — Extensible Markup Language

After reading these abbreviations, you might wonder what’s an External Entity? Why are we focusing on XML here only, why not HTML External Entity or SAML External Entity and so on?

The XML as its name suggests, it interacts with files on the application server filesystem and any backend or external systems.

HTML is the markup language which helps you to create and design web content. While XML Makes documents transportable across systems and applications. With the help of XML, you can exchange data quickly between different platforms.

During the Pen tester research, the reported vulnerabilities on HTML are taken care of developers and we explored to find vulnerabilities on other Mark Languages. xml version=”1.0" which is used by most of the API developers, is found to be vulnerable to this attack.

Next query is why External Entity, not an internal entity? This is a simple one. While referring external entity, the markup language says the file on the system in this case web server where the application is running. When it says internal entity, it refers to the entity written inside its code.

How you find it?

· Capture the XML requests in your burp suite.

· Go to your BURP HTTP history and filter all the XML requests for ease of testing.

· Once you filter out your XML requests, you will see a request like this one.

· Then you try this modification to the XML code. Insert the following external entity definition in between the XML declaration and the stockCheck element:

<!DOCTYPE test [ <!ENTITY xxe SYSTEM “file:///etc/passwd”> ]>

· Then replace the productId number with a reference to the external entity: &xxe; . In the next response, you will find the /etc/passwd file. Just like below.

· Now if you see my screenshot, you’ll have a clear idea about the payloads placing and the sensitive data are found.

· Please note that real time attacks aren’t that simple. It requires the intelligence of the Pen tester to modify the payloads accordingly.

· We perform Blind XXE attack to be on safer side while testing an API end point.

Impact of XXE:

· We can retrieve internal files.

· We can perform Remote Code Execution and SSRF also.

Mitigation:

The safest way to prevent XXE is always to disable DTDs (External Entities) completely. Depending on the parser, the method should be similar to the following:

factory.setFeature(“http://apache.org/xml/features/disallow-doctype-decl", true);

Disabling DTDs also makes the parser secure against denial of services (DOS) attacks such as Billion Laughs. If it is not possible to disable DTDs completely, then external entities and external document type declarations must be disabled in the way that’s specific to each parser. (Source OWASP)

Step 6: SSRF

You have heard CSRF (cross site request forgery) and you know how to perform. What’s this SSRF?

SSRF — Server-Side Request Forgery

When I heard this first time, I was totally overwhelmed. Such vulnerability exists and people exploit it too. May be Pen test isn’t my cup of tea. Life changing thoughts…ha ha !!

When the application trusts the user blindly and executes its input as given and the OS of the web server also trusts the application inputs, then it happens. It’s all the game of betrayal. Now the Game of Thrones theme rings. If you are looking for a concrete definition, here it is:

“Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.”

How you find it?

· You can find it in any request. Doesn’t matter a GET or POST request.

· It must have a parameter processing though.

· Without a parameter, you can try “URL redirect attack” points to execute it.

· Real time, if you find Internal IP disclosure vulnerability in an API, you can use that IP address in your payload to perform this attack.

What I did?

· Here I found my stockapi parameter to barge in.

· It didn’t happen, when I give /admin. Not so easy.

· I changed a little bit to http://localhost/admin. Looks easy and simple.

· May be I am in admin page. Who knows ? Let’s try to delete an user.

· You see that “Success” message. I deleted an user named “carlos” from the before screenshot.

Impact of the SSRf could be anything. This attack is related to XXE attack too. You can do a SSRF from XXE. Your brainstorming part! Mostly it can perform scanning of internal ports and addresses. But you have seen it can delete an user if used wisely.

Mitigation: It could be as simple as input validation. To prevent SSRF vulnerabilities in your web applications, it is strongly advised to use a whitelist of allowed domains and protocols from where the web server can fetch remote resources.

CONTD…. Follow me on linked in https://in.linkedin.com/in/saumya-prakash-rana-4287b990