The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
IN OTHERS WORDS
Server Side Request Forgery (SSRF) refers to an attack where in an attacker is able to send a crafted request from a vulnerable web application. SSRF is usually used to target internal systems behind firewalls that are normally inaccessible to an attacker from the external network. Additionally, it’s also possible for an attacker to leverage SSRF to access services from the same server that is listening on the loopback interface (127.0.0.1).
Typically Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the request that is being sent. A common example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party service.
Detecting Server Side Request Forgery (SSRF)
In order to detect Server Side Request Forgery (SSRF) automatically, we’ll need to rely on an intermediary service since the detection of such a vulnerability requires an out-of-band and time-delay vector. Acunetix solves this by making use of AcuMonitor as its intermediary service during an automated scan.
During a scan, Acunetix will make requests containing a unique AcuMonitor URL. If AcuMonitor receives a request on one of these unique URLs, it will send a notification back to Acunetix indicating it should raise an alert for Server Side Request Forgery (SSRF).
The following is the result of an Acunetix scan with AcuMonitor to detect Server Side Request Forgery (SSRF). The alert contains information about the HTTP request that was performed including the IP address of the server that made this request and the User-agent string used in the request, if any. This information can help the developers identify the source of the problem and fix it.
Mitigating Server Side Request Forgery (SSRF)
Whitelists and DNS resolution
Implementing simple blacklists or regular expressions directly on the user’s input to filter out which IP addresses or domains can make requests is a bad approach to take when mitigating an SSRF.
In general, blacklists are a poor security control because there will always be bypasses not envisaged by a developer. In this case, bypass by an attacker are as easy as using an HTTP redirect, a wildcard DNS service such as xip.io or even alternate IP encoding.
Instead, the most robust way of dealing with Server Side Request Forgery (SSRF) is to whitelist the DNS name or IP address which your application needs access to. If a whitelist approach does not suit your use case, and you must rely on a blacklist, it’s important to validate user input properly. An example of this is to not allow requests to private (“non-routable”) IP addresses (detailed in RFC 1918), however, in the case of a blacklist, the correct mitigation to adopt will vary from application to application. In other words, there is no universal “fix” to SSRF since it highly depends on the application’s functionality and business requirements.
Response handling
Ensuring that the response received by the remote server is indeed what the server is expecting is important to prevent any unforeseen response data leaking to the attacker. Above all else, under no circumstances should the raw response body from the request sent by the server be delivered to the client.
Disable unused URL schemas
If your application only makes use of HTTP or HTTPS to make requests, only allow those URL schemas. Disabling unused URL schemas will prevent a web application from making requests using potentially dangerous URL schemas such as
file:///, dict://, ftp:// and gopher://.Authentication on internal services
Services such as Memcached, Redis, Elasticsearch and MongoDB do not require authentication by default. Server Side Request Forgery vulnerabilities could provide an attacker with the opportunity to access some of these services without any authentication standing in the way. Therefore, it’s best to enable authentication wherever possible as another defense mechanism.
OBTAINED FROM DIFFERENT SOURCES
Acunetix: www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
& others great authors
& others great authors
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.Languages
Class: Language-Independent (Undetermined Prevalence)
Paradigms
Web Based (Undetermined Prevalence)
Technologies
Web Server (Undetermined Prevalence)
+ Common Consequences
The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Technical Impact: Execute Unauthorized Code or Commands
+ Notes
Relationship
CWE-918 (SSRF) and CWE-611 (XXE) are closely related, because they both involve web-related technologies and can launch outbound requests to unexpected destinations. However, XXE can be performed client-side, or in other contexts in which the software is not acting directly as a server, so the "Server" portion of the SSRF acronym does not necessarily apply.
