Information systems must not be susceptible to Cross-frame Scripting (XFS) attacks and clickjacking.
Information systems must implement proper input validation and output encoding. With proper input validation and output encoding, information systems will not be susceptible to cross-frame scripting, either stored or reflected. A successful cross-frame scripting attack may redirect a user to a malicious third-party page.
Technical Risk : Without proper input validation and output encoding, information systems are susceptible to cross-frame scripting, which may result in unauthorized access or malicious attacks against the user.
Corrective Action : This issue can be fixed using the following methods1. Implementing the response header X-Frame- Options and set the value to 'Deny' or 'same origin'.2. Sending the proper browser response headers that instruct the browser to not allow framing from other domains .
The application (Zeppelin) loads in iframe.
<iframe src="https://localhost:8443/#/" width="100%" height="600"></iframe>
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites. Set the X-Frame-Options header for all responses containing HTML content. The possible values are "DENY", "SAMEORIGIN", or "ALLOW-FROM uri"
X-Frame-Options Header Types
There are three possible values for the X-Frame-Options header:
DENY, which prevents any domain from framing the content. The "DENY" setting is recommended unless a specific need has been identified for framing.
SAMEORIGIN, which only allows the current site to frame the content.
ALLOW-FROM uri, which permits the specified 'uri' to frame this page. (e.g., ALLOW-FROM http://www.example.com).