This is a series of Security related articles.
F - 0: Introduction
This article is a part of Cross-Frame Scripting (XFS), this is an example of a real high security issue created by Fortify Dynamic Scanning --- WebInspect.
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
A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. The attacker could use this weakness to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks.
Clickjacking
The goal of a Clickjacking attack is to deceive the victim (user) into interacting with UI elements of the attacker’s choice on the target web site without their knowledge and then executing privileged functionality on the victim’s behalf. To achieve this goal, the attacker must exploit the XFS vulnerability to load the attack target inside an iframe tag, hide it using Cascading Style Sheets (CSS) and overlay the phishing content on the malicious page. By placing the UI elements on the phishing page so they overlap with those on the page targeted in the attack, the attacker can ensure that the victim must interact with the UI elements on the target page not visible to the victim.
WebInspect has detected a page which potentially handles sensitive information using an HTML form with a password input field and is missing XFS protection.
An effective frame-busting technique was not observed while loading this page inside a frame.
HTTP/1.1 200 OK
Cache-Control: no-cache,no-cache, no-store, must-revalidate
Pragma: no-cache,no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Vary: Accept-Encoding
Server:
Content-Security-Policy: frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-POWERED-BY:
Date: Mon, 22 Feb 2021 18:27:02 GMT
Content-Length: 10387
F - 2: Details
Create a test page containing an HTML iframe tag whose src attribute is set to /hcwfisv/. Successful framing of the target page indicates that the application is susceptible to XFS.
Note that WebInspect will report only one instance of this check across each host within the scope of the scan. The other visible pages on the site may, however, be vulnerable to XFS as well and therefore should be protected against it with an appropriate fix.
F - 3: Example
Example: Ignore.
F - 4: Recommendation
The Content Security Policy (CSP) frame-ancestors directive obsoletes the X-Frame-Options header. Both provide for a policy-based mitigation technique against cross-frame scripting vulnerabilities. The difference is that while the X-Frame-Options technique only checks against the top-level document’s location, the CSP frame-ancestors header checks for conformity from all ancestors.
If both CSP frame-ancestors and X-Frame-Options headers are present and supported, the CSP directive will prevail. WebInspect recommends using both CSP frame-ancestors and X-Frame-Options headers as CSP is not supported by Internet Explorer and many older versions of other browsers.
In addition, developers must also use client-side frame busting JavaScript as a protection against XFS. This will enable users of older browsers that do not support the X-Frame-Options header to also be protected from Clickjacking attacks.
X-Frame-Options
Developers can use this header to instruct the browser about appropriate actions to perform if their site is included inside an iframe. Developers must set the X-Frame-Options header to one of the following permitted values:
- DENY
Deny all attempts to frame the page
- SAMEORIGIN
The page can be framed by another page only if it belongs to the same origin as the page being framed
- ALLOW-FROM origin
Developers can specify a list of trusted origins in the origin attribute. Only pages on origin are permitted to load this page inside an iframe
Content-Security-Policy: frame-ancestors
Developers can use the CSP header with the frame-ancestors directive, which replaces the X-Frame-Options header, to instruct the browser about appropriate actions to perform if their site is included inside an iframe. Developers can set the frame-ancestors attribute to one of the following permitted values:
- ‘none’
Equivalent to “DENY” - deny all attempts to frame the page
- ‘self’
Equivalent to “SAMEORIGIN” - the page can be framed by another page only if it belongs to the same origin as the page being framed
- <host-source>
Equivalent to “ALLOW-FROM” - developers can specify a list of trusted origins which maybe host name or IP address or URL scheme. Only pages on this list of trusted origin are permitted to load this page inside an iframe
- <scheme-source>
Developers can also specify a schema such as http: or https: that can frame the page.
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 solutioin.
F - 5: The Fix or Suggestion
Fix 1:
Set up CSP (Current Security Policy) and X-Frame-Option (see How to Set Up a Content Security Policy (CSP) in 3 Steps (sucuri.net))
![]()
In this case, we have
Content-Security-Policy: frame-ancestors 'none'
and we modify X-Frame-Options from SAMEORIGIN to DENY
X-Frame-Options: DENY
Note:
To view the header in Browser, please see: How to view HTTP headers in Google Chrome?
At the same time, we add the Client side Frame Busting JavaScript as a Protection against XFS for the whole web pages (we add it in the master page):
![]()
After the fix, the error is still not removed from the Danymic Scan by Fortify WebInspect, then we create a False Positive Request to let the Application Security Team to review or close the issue manually. However, we got response:
The CSP header is missing a few directives including 'strict-dynamic' in combination with a nonce or hash. You may refer to Content Security Policy - OWASP Cheat Sheet Series.
Fix 2
In case to add "script-src 'nonce-r4nd0m' 'strict-dynamic';" into the CSP, we need to find out
Where to set the HTTP Response Header
Most modifications to your HTTP Response header will happen in the configuration file.
- Find out what server your website is running on. You can also log into your cPanel and check under the Server Information interface to find out. This will show the server that hosts your account.
- Once you know your server, set your HTTP response header within the corresponding configuration file as detailed below. We have also linked additional resources for greater detail.
In our case, we have: IIS (Internet Information Services)
Open the IIS manager
![]()
Media source: docubrain.com
- On the left select the website that you want to set the HTTP Response Header for
- Select the HTTP Response Headers icon.
- Select “add” and enter your name and value for the header
Then, we have
![]()
Alternatively, if you don’t want to open the IIS manager you can add your policy to the web.config file. It will look something like this depending on the directives you chose:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'self'; img-src*" />
</customHeaders>
</httpProtocol>
</system.webServer>
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.
Reference