I would like to ignore X-frame header on my website so that iframe can load external websites. There are chrome extension like
this one which works perfectly. How can I implement same concept through javascript?
You can’t use frontend JavaScript code running in a browser to cause the X-Frame-Options response header to be ignored. X-Frame-Options is a security feature designed in part as a defense against clickjacking attacks. If any site could just use some JavaScript code to cause browsers to ignore X-Frame-Options, that would pretty much make it completely useless.
That’s the reason why the only way you can cause it to be ignored in your own browser is by intentionally opting-in to insecure browsing by installing an extension as mentioned in the question.
But you can’t use JavaScript to force insecure browsing on other users by bypassing security features like X-Frame-Options that browsers have built-in support for.
Related
I have a specific asset on my server that responds requests with the following header:
cache-control:public,max-age=2592000,immutable
Sometimes the site might have to request the same file more than 10 times (The reason is not important). That's the reason why I configured this header.
Almost all mobile devices, desktop, and tables (along with the browsers) respect it, but some are not, they are just ignoring and requesting from the server again, E-V-E-R-Y single time. I'm using the BrowserStack to test, maybe the problem could be there, I'm not sure of anything now. Have you ever experienced such a thing? Is there a workaround, or something that I could do to debug it?
Thank you.
immutable is an Extension Cache-Control directive and is not supported by all browsers.
According to http://developer.mozilla.org :
Extension Cache-Control directives are not part of the core HTTP caching standards document.
If you check on the same page you can see that Chrome does not support it.
You may be better off using a simpler directive, like:
Cache-Control: public, max-age=31536000
This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.
I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.
Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.
Today i got confused when i was asked What is Cross browser scripting. Here as per my understanding Cross browser Scripting is related to Browser compatibility, Cross Site Scripting is related to java-script hacks & Cross Domain Scripting is related to Ajax calls.
I tried to google it also but not getting clear concept of cross browser scripting.
Please help me to understand the difference.
If a script is cross browser, it works comparably in all browsers. JavaScript engine in different browsers tend to vary in some minor details.
Cross domain scripting is either an attack that tries to hijack user sessions (malicious) or it's a way to communicate with another domain. Cross Domain Scripting aka Cross Origin Resource Sharing is quite tricky to set up.
"Cross-browser Scripting" is a somewhat archaic term (you'll see the article linked is dated 1997) meaning writing scripts that work across browsers. More recently this is usually called "browser compatibility".
"Cross-site Scripting" is a type of attack that involves making malicious scripts a part of someone elses page in order to deliver some payload that compromises their visitors.
"Cross-domain Scripting" is generally synonymous with "Cross-site Scripting".
If you have a cross-site scripting attack that works across all browsers, you might be inclined to call it a "Cross Browser Cross Site Scripting" attack, or XBXSS.
As I understand, the webserver will send p3p information to the browser, but will the browser then present that data to the javascript engine via some API?
No -- P3P information is not exposed to JavaScript, and generally has very little effect on browser behavior in general, other than a few weird edge cases on MSIE.
Aside from using browser headers, I want to blacklist/whitelist browser and plugins from my site so that I can prevent these older unpatched systems from (1) being a general user of my site (2) removing those 'targets' from would-be-attackers reach.
My goal is to define some kind of
endpoint security standard for users
who access my site, but without
directly managing the environment, as
they are customers.
Is there a standard way to use Whitelisting or Blacklisting to control browser access to my site?
For example, I want to prevent any browser that has outdated Flash, but I want to permit them if they have no Flash at all.
You could use modernizr.com to detect the browser and features?