Trace UUID: OC70-VG3X-LMN2-0TIX
https://apptwo.contrastsecurity.com/Contrast/static/ng/index.html#/f7ea7169-d4eb-42c4-b32e-5c0ea0ca9733/vulns/OC70-VG3X-LMN2-0TIX/overview
Description
We observed 4 pages without sufficient anti-clickjacking controls:
Risk
The application doesn't apply anti-framing controls to the given page. Not applying these controls will allow it to be
framed by other websites. This can present a few security issues, but the chief concern is that framed pages may be used in
Clickjacking attacks.
Clickjacking (also called UI Redress) is an attack whereby an attacker can trick a user into clicking on something different
from what it appears they are clicking on. Most attacks will first build a page that entices the user to click on it - for scandalous
pictures, monetary rewards, and other promises. The buttons and links on this page are carefully placed so that they overlap with
buttons, links or other items on a second page that gets layered on top of the first one.
The problem for the victim in this scenario is that the link that they'd like to click for the promised rewards on the evil page
is actually "beneath" a translucent, second page which has been framed into the HTML document. Thus, when they intend to click
on "Collect Your Prize!", they're really clicking on Transfer Your Money!, or similar.
Numerous real-life Clickjacking attacks have caused damage to Adobe Flash Player, and numerous websites including Facebook,
Twitter, YouTube, and others.
There are generally two controls that prevent framing of a web page: the X-Frame-Options header, and so-called
frame-busting JavaScript. Details about these controls can be found in the Remediation tab.
Neither of these anti-framing controls were found in the HTTP response to the following URL(s):
Recommendation to fix this finding
As mentioned on the Summary tab, there are two controls against framing - setting a proper X-Frame-Options header on the response to a page and including frame-busting JavaScript.
Using the X-Frame-Options header
All major modern browsers honor a header, called X-Frame-Options. This header instructs browsers about a page's preferences regarding being framed. Not setting this header has no effect, which means that the page is allowed to be framed from any web site. There are 3 possible values that can help restrict framing:
DENY. When set to DENY, no pages may frame this page.`SAMEORIGIN. When set to SAMEORIGIN, any page outside the origin of the hosting page may not frame this resource.`ALLOW-FROM [URI]. The ALLOW-FROM setting, supported by Internet Explorer and Firefox, allows developers to whitelist a URI that is allowed to frame the given content. It's not known if this feature will eventually be adopted by Chrome, Safari, or other WebKit-based browsers. However, because numerous browsers don't support ALLOW-FROM, and it breaks X-Frame-Options in those browsers (meaning it allows any site to frame those pages), we recommend avoiding the use of ALLOW-FROM.`
If Contrast sees a setting of X-Frame-Options of DENY or SAMEORIGIN, it will not report this issue.
Using frame-breaking code
There are lots of variants of "frame-breaking code"; a term that describes JavaScript that makes sure a site is only in
the top-level frame of an HTML document. This JavaScript is tricky to write, as a framing attacker controls part of the
JavaScript variable space. This makes it difficult to decide which variables and checks can be trusted.
Currently, the best known defense which works on legacy and modern browsers is a combination of two pieces: a snippet of CSS
and a snippet of JavaScript. Here's the CSS snippet, which hides the entire web page from view. If the page is detected to be
the highest level frame, its contents will be un-hidden by the script described next. Put this style, and the JavaScript that
removes this style in the document HEAD element.
<style id="antiClickjack">body{display:none !important;}</style>
The other piece of the control is the JavaScript. This page does a simple, secure check (self === top) to make sure it's
the top level frame. If it is, it removes the stylesheet used above and un-hides the page. If the page is framed, the user is
redirected to the page at the top level, effectively "busting out" of the unknown 3rd party framer, and to the owner of original
resource:
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
Because this check happens instantaneously, this check is largely invisible to users, and load-testing shows it adds no
significant performance increase to page loading or page rendering time. Contrast won't report this issue if it finds something
that looks like frame-breaking code, even if it's not exactly like the code above.
Trace UUID: OC70-VG3X-LMN2-0TIX
https://apptwo.contrastsecurity.com/Contrast/static/ng/index.html#/f7ea7169-d4eb-42c4-b32e-5c0ea0ca9733/vulns/OC70-VG3X-LMN2-0TIX/overview
Description
We observed 4 pages without sufficient anti-clickjacking controls:
Risk
The application doesn't apply anti-framing controls to the given page. Not applying these controls will allow it to be
framed by other websites. This can present a few security issues, but the chief concern is that framed pages may be used in
Clickjacking attacks.
Clickjacking (also called UI Redress) is an attack whereby an attacker can trick a user into clicking on something different
from what it appears they are clicking on. Most attacks will first build a page that entices the user to click on it - for scandalous
pictures, monetary rewards, and other promises. The buttons and links on this page are carefully placed so that they overlap with
buttons, links or other items on a second page that gets layered on top of the first one.
The problem for the victim in this scenario is that the link that they'd like to click for the promised rewards on the evil page
is actually "beneath" a translucent, second page which has been framed into the HTML document. Thus, when they intend to click
on "Collect Your Prize!", they're really clicking on Transfer Your Money!, or similar.
Numerous real-life Clickjacking attacks have caused damage to Adobe Flash Player, and numerous websites including Facebook,
Twitter, YouTube, and others.
There are generally two controls that prevent framing of a web page: the X-Frame-Options header, and so-called
frame-busting JavaScript. Details about these controls can be found in the
Remediationtab.Neither of these anti-framing controls were found in the HTTP response to the following URL(s):
Recommendation to fix this finding
As mentioned on the Summary tab, there are two controls against framing - setting a proper
X-Frame-Optionsheader on the response to a page and includingframe-busting JavaScript.Using the X-Frame-Options header
All major modern browsers honor a header, called
X-Frame-Options. This header instructs browsers about a page's preferences regarding being framed. Not setting this header has no effect, which means that the page is allowed to be framed from any web site. There are 3 possible values that can help restrict framing:DENY. When set to DENY, no pages may frame this page.`SAMEORIGIN. When set to SAMEORIGIN, any page outside the origin of the hosting page may not frame this resource.`ALLOW-FROM [URI]. The ALLOW-FROM setting, supported by Internet Explorer and Firefox, allows developers to whitelist a URI that is allowed to frame the given content. It's not known if this feature will eventually be adopted by Chrome, Safari, or other WebKit-based browsers. However, because numerous browsers don't support ALLOW-FROM, and it breaks X-Frame-Options in those browsers (meaning it allows any site to frame those pages), we recommend avoiding the use of ALLOW-FROM.`If Contrast sees a setting of X-Frame-Options of
DENYorSAMEORIGIN, it will not report this issue.Using frame-breaking code
There are lots of variants of "frame-breaking code"; a term that describes JavaScript that makes sure a site is only in
the top-level frame of an HTML document. This JavaScript is tricky to write, as a framing attacker controls part of the
JavaScript variable space. This makes it difficult to decide which variables and checks can be trusted.
Currently, the best known defense which works on legacy and modern browsers is a combination of two pieces: a snippet of CSS
and a snippet of JavaScript. Here's the CSS snippet, which hides the entire web page from view. If the page is detected to be
the highest level frame, its contents will be un-hidden by the script described next. Put this style, and the JavaScript that
removes this style in the document HEAD element.
<style id="antiClickjack">body{display:none !important;}</style>
The other piece of the control is the JavaScript. This page does a simple, secure check (self === top) to make sure it's
the top level frame. If it is, it removes the stylesheet used above and un-hides the page. If the page is framed, the user is
redirected to the page at the top level, effectively "busting out" of the unknown 3rd party framer, and to the owner of original
resource:
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
Because this check happens instantaneously, this check is largely invisible to users, and load-testing shows it adds no
significant performance increase to page loading or page rendering time. Contrast won't report this issue if it finds something
that looks like frame-breaking code, even if it's not exactly like the code above.