/ Register

Join the community today
Become a Member

X-Frame-Options header and sameorigin - Double-framing attacks?

Discussion in 'Nginx, PHP-FPM & MariaDB MySQL' started by pamamolf, Jun 5, 2019.

Previous Thread Next Thread
Loading...
  1. Jun 5, 2019 #1
    pamamolf

    pamamolf Well-Known Member

    4,125
    429
    83
    May 31, 2014
    Ratings:
    +841
    Local Time:
    5:35 AM
    Nginx-1.29.x
    MariaDB 10.6.x
    Hello

    Just got this mail:

    We are a team of academic researchers from Stony Brook University (US), Universita Ca Foscari Venezia (Italy), and the CISPA Helmholtz Center for Information Security (Germany) investigating the usage of security headers on the Web.

    As part of our analysis, we are investigating the usage of the X-Frame-Options header to control framing on the Web. Based on our analysis, your site is attempting to control framing with the following value

    sameorigin

    We noticed that this value potentially allows for double-framing attacks with certain browsers such as Internet Explorer and Edge (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options#Browser_compatibility)

    The currently proposed way to ensure that all modern browsers properly protect against framing attacks is to use the Content-Security-Policy directive frame-ancestors. In particular, for your value of X-Frame-Options, the corresponding value is

    frame-ancestors 'self'

    Note that in order to protect older browsers, keeping X-Frame-Options in place is recommended. As CSP takes precedence over X-Frame-Options, securing legacy clients without interfering with modern browsers is possible through the usage of the DENY directive in XFO.

    For further information on CSP's frame-ancestors, please refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

    As this email is part of a research project in which we are trying to understand the lack of adoption of CSP in the wild, it would be immensely helpful if you could provide us with feedback regarding the lack of CSP's frame-ancestors to protect against framing attacks on your Web site (i.e. where you not aware of the CSP mechanism, that specific CSP directive, or, were you not adopting it, for some other reason?)

    Any thoughts on this?

    Can we fix that on Centminmod?

    Thank you
     
  2. Jun 5, 2019 #2
    Jimmy

    Jimmy Well-Known Member

    1,799
    391
    83
    Oct 24, 2015
    East Coast USA
    Ratings:
    +999
    Local Time:
    10:35 PM
    Another reason not to use a Microsoft product.
     
  3. Jun 5, 2019 #3
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    12:35 PM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    CSP can't be automated it is a per site, per theme deployment where only web developers know which local and 3rd party remote assets are to be allowed - otherwise like HSTS, improper Content Security Policy (CSP) implementations can end up DOS (denial of service) your own sites. It's same reason why default created centmin mod nginx vhosts have the X-Frame-Option header disabled and commented out by default leaving it up to folks who know the consequences of enabling it, to do so themselves. Commented out and disabled with hash # in front
    Code (Text):
    #add_header X-Frame-Options SAMEORIGIN;


    Take a read of all Scott's articles on his site including Content Security Policy - An Introduction - in theory nice as long as you're not using Google Adsense or similar advertisers which would be a continuous and ongoing amount of CSP whitelisting work to do.

    So yes you can implement CSP yourself, but you'd be on your own in doing so :) Of course other members here can share their experience with CSP etc too.
     
Previous Thread Next Thread
Loading...

.