This is a series of Security related articles I wrote. This article is the first one.
F - 0: Introduction
This article is a part of Server-Side Request Forgery (SSRF), this is an example of a real high security issue created by a Fortify Static Scanning.
This is the structure of this article,
- F - 0: Introduction
- F - 1: Overview
- F - 2: Details
- F - 3: Example
- F - 4: Recommendation
- F - 5: The Fix or Suggestion
- F - 6: False Positive Accepted
F - 1: Overview
The function Create() on line 1452 initiates a network connection to a third-party system using user-controlled data for resource URI. An attacker might leverage this vulnerability to send a request on behalf of the application server since the request will originate from the application server's internal IP address.
![]()
F - 2: Details
A Server-Side Request Forgery occurs when an attacker can influence a network connection made by the application server. The network connection will originate from the application server's internal IP and an attacker can use this connection to bypass network controls and scan or attack internal resources that are not otherwise exposed.
In this case, Create() is called in BasePage.vb on line 1452.
F - 3: Example
Example: In the following example, an attacker can control the URL to which the server is connecting.
string url = Request.Form["url"];
HttpClient client = new HttpClient();
HttpResponseMessage response = await client.GetAsync(url);
The attacker's ability to hijack the network connection depends on the specific part of the URI that can be controlled, and on the libraries used to establish the connection. For example, controlling the URI scheme lets the attacker use protocols different from HTTP or HTTPS like:
- up://
- ldap://
- jar://
- gopher://
- mailto://
- ssh2://
- telnet://
- expect://
An attacker can leverage this hijacked network connection to perform the following attacks:
- Port Scanning of intranet resources.
- Bypass firewalls.
- Attack vulnerable programs running on the application server or on the intranet.
- Attack internal/external web applications using Injection attacks or CSRF.
- Access local files using file:// scheme.
- On Windows systems, file:// scheme and UNC paths can allow an attacker to scan and access internal shares.
- Perform a DNS cache poisoning attack.
F - 4: Recommendation
Do not establish network connections based on user-controlled data and ensure that the request is being sent to the expected destination. If user data is necessary to build the destination URI, use a level of indirection: create a list of legitimate resource names that a user is allowed to specify, and only allow the user to select from the list. With this approach, the input provided by the user is never used directly to specify the resource name.
In some situations, this approach is impractical because the set of legitimate resource names is too large or too hard to maintain. Programmers often resort to implementing a deny list in these situations. A deny list is used to selectively reject or escape potentially dangerous characters before using the input. However, any such list of unsafe characters is likely to be incomplete and will almost certainly become out of date. A better approach is to create a list of characters that are permitted to appear in the resource name and accept input composed exclusively of characters in the approved set.
Also, if required, make sure that the user input is only used to specify a resource on the target system but that the URI scheme, host, and port is controlled by the application. This way the damage that an attacker is able to do will be significantly reduced.
Note
The F - 1 to F - 4 are mainly from fortify auto detector (Micro Focus) with some of my input (graph or explanations), F - 5 and below are the input from myself --- the solution.
F - 5: The Fix or Suggestion
![]()
The SSRF problem is created from code, Line 1440 (see attachment 1): the URL is from the database, which is treated by Fortify as "user-controlled data". The fact is that the database is not user accessible, it is part of the program with the same security level with the code, it is not accessible from outside of firewall, so it is not "user-controlled data".
Therefore, the issue becomes that Fortify treats the code as "user-controlled data", in fact it is not. This is a False Positive issue.
F - 6: False Positive Accepted
Accepting developer attestations. --- From the Application Security Team.
Note
False Positive Accepted means the tool (Fortify Scanner) is wrong:
False positives occur when a security testing tool incorrectly flags an issue that is not legitimate (i.e. tool says SSL 3.0 is enabled, but it is not – the tool was wrong). In these cases, teams are encouraged to follow the process outlined below for issues to be suppressed and for us to ensure the bug is resolved.