Severity Differences Between SSRF & XXE

SSRF stands for Server-Side Request Forgery and is a type of attack in which a vulnerable server is forced by the attacker/hacker to trigger unwanted malicious requests to the third-party servers and/or to internal resources.

XML stands for XML External Entity and is a type of attack that is performed over an application that parses XML input. This type of attack could also allow an attacker /hacker to access files on the application server file system, to interact with any backend or third-party systems that the app itself could access, and further, it could be taken to RCE (Remote Code Execution) as well.

It should be kept in mind that both types of attacks share few similarities to some extent. The most basic and simple method of SSRF exploit is explained in the below image.

In the above image, it could be observed that an attacker is generating a request to the vulnerable server which directs the server to make a request on the behalf of the attacker. The vulnerable server then generates a request to a host on the internal network which would not typically be available to outer attackers. The internal network host answers to the vulnerable server’s request, and simultaneously this response/answer is transferred back to the attacker. There are numerous different methods of this situation, yet this is the most straightforward instance to start with.

SSRF and XXE weaknesses give attackers a wide scope of control. An attacker might have the option to control the information, convention, and destination of the request that the server makes, or it is also possible that they might be confined to just controlling the IP address or destination domain. Ordinarily, with SSRF, the measure of control falls someplace within these limits.

At the point when an attacker has restricted authority over the request being transmitted by the server, it confines what can be achieved and will in general lower the criticality. SSRF exploits perceivability commonly falls someplace in the middle of being fully perceivable and totally blind from the attacker’s point of view. Full is when an attacker can see (or if nothing else foresees) the full request and can get a complete reaction, and Blind is when the request made by the vulnerable server and additionally the reaction conveyed back to the attacker may not be completely visible, compelling pieces of the adventure to be a calculated guess.

In a full SSRF exploit, an attacker can see and control a significant part of the requested information and would then be able to get a reasonable response. This typically brings about a more significant attack than when an attacker doesn’t have full control or perceivability over their ideal request and can’t get the complete response. Most attacks fall someplace in the middle, allowing partial control and some perceivability.

Blind attacks frequently force an attacker to depend on tricks to effectively perform an attack. A few of them are as follows:-

• Compelling a DNS query to originate from a non-web accessible host to get a sign that the attacks/exploit was rewarding.

• Driving yields into some other configuration than anticipating an HTTP Response, for instance constraining a vulnerable server to create a PDF that contains document substance or a server reaction like an SSH, Telnet, or FTP banner.

• Differentiating reaction times among requests and making presumptions depending on reaction times. For instance, a reaction session of one second for ports 22, 80, and 443 may show open ports (particularly since these are normally open ports) where a reaction session of more than 5 seconds might be the aftereffect of a timeout, demonstrating a closed port.

• Depending on HTTP response codes as a sign of achievement or disappointment, however, it could be mistake-prone. For instance, if the convention utilized in the SSRF is hardcoded as https://and is out of the attacker’s control, the consequences of playing out a request to ports that are expecting a TLS handshake will act uniquely in contrast to services that are anticipating HTTP, which will act uniquely in contrast to ports that don’t expect web traffic by any means. Moreover, visiting a website with a legitimate certificate may bring about an unexpected reaction in comparison to visiting a site with a self-signed, lapsed, misconfigured, or in any case dishonest certificate.

Another significant thought is the thing that in what environment the vulnerable system is and what systems it can speak with. An independent system helpless against XXE or SSRF running in a partitioned network with strict inbound and outbound correspondence limitations may present little threat/risk to an organization. The inverse is valid if the vulnerable system is a server in a corporate network with practically zero network division and the vulnerable service is running with an advantaged venture client account.

Some thought is needed in every one of these zones prior to deciding business threats/risks. Every vulnerability ought to be assessed cautiously to choose their risk and decide the fix prioritization.

One sort of exploit is quite rare, known as External only exploit, and occurs when an attacker is only capable to compel the vulnerable server to make a connection with the server on the web, however when there is no capacity to demonstrate connections with administrations on the internal network can happen.

One exemption for this is the point at which the attacker can drive a vulnerable server to extract a document that is secured by validation. At times, this procedure can be utilized to leak an enterprise client account’s password hash on the grounds that the vulnerable server attempts to validate to an attacker-controlled worker (utilizing SMB) to recover the document.

On the off chance that the password is easy or if the attacker has sufficient opportunity and processing assets, it could be conceivable to calculate the password which is related to the hash leaked. In the event that the same organization has remotely accessible administrations like Outlook Web Access (OWA), Citrix, VPN, or another service that acknowledges enterprise credentials, this may allow further misuse and would present more risks/threats than an ordinary “external only” SSRF.

If you like this article, follow us on Twitter, Facebook, Instagram, and LinkedIn.