I have been asked to build a tabbed section on pages that have RESTful URLs without a trailing slash (.NET MVC), for example http://myhost/books/the-amber-spyglass
For the tabbed sections to be a bit more user friendly I want them to remember which tab was open on each page as the user moves around, so that if they return to a book they were previously on the same tab remains opened. This is achieved by setting a cookie named "tab" with value set to the tabid and path set to the page they are on (so it doesn't affect tabs on other pages). So far pretty basic stuff you'd think, and it does work quite nicely too.
Enter Internet Explorer.
In IE it turns out a cookie with path /books/the-amber-spyglass will NOT match the above URL and consequently won't get set properly. If I add a trailing slash so the path is /books/the-amber-spyglass/ instead it works fine - but I cannot change our URL schema, and even if I could "the-amber-spyglass" is a resource, NOT a folder.
Does anyone have a recommended solution to this, surely exceedingly common, problem?
Many thanks in advance,
JS
See http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx
Due to an obscure bug in the
underlying WinINET InternetGetCookie
implementation, IE’s document.cookie
will not return a cookie if it was set
with a path attribute containing a
filename.
For instance, if a page sets a cookie
on itself like so:
Set-Cookie:
HTTPSet-PathCookie=PASS;path=/check.htm
…the cookie will be sent with HTTP
requests but will not appear in the
document.cookie collection.
Related
I am developing a web page that needs to display, in an iframe, a report served by another company's SharePoint server. They are fine with this.
The page we're trying to render in the iframe is giving us X-Frame-Options: SAMEORIGIN which causes the browser (at least IE8) to refuse to render the content in a frame.
First, is this something they can control or is it something SharePoint just does by default? If I ask them to turn this off, could they even do it?
Second, can I do something to tell the browser to ignore this http header and just render the frame?
If the 2nd company is happy for you to access their content in an IFrame then they need to take the restriction off - they can do this fairly easily in the IIS config.
There's nothing you can do to circumvent it and anything that does work should get patched quickly in a security hotfix. You can't tell the browser to just render the frame if the source content header says not allowed in frames. That would make it easier for session hijacking.
If the content is GET only you don't post data back then you could get the page server side and proxy the content without the header, but then any post back should get invalidated.
UPDATE: 2019-12-30
It seem that this tool is no longer working! [Request for update!]
UPDATE 2019-01-06: You can bypass X-Frame-Options in an <iframe> using my X-Frame-Bypass Web Component. It extends the IFrame element by using multiple CORS proxies and it was tested in the latest Firefox and Chrome.
You can use it as follows:
(Optional) Include the Custom Elements with Built-in Extends polyfill for Safari:
<script src="https://unpkg.com/#ungap/custom-elements-builtin"></script>
Include the X-Frame-Bypass JS module:
<script type="module" src="x-frame-bypass.js"></script>
Insert the X-Frame-Bypass Custom Element:
<iframe is="x-frame-bypass" src="https://example.org/"></iframe>
The X-Frame-Options header is a security feature enforced at the browser level.
If you have control over your user base (IT dept for corp app), you could try something like a greasemonkey script (if you can a) deploy greasemonkey across everyone and b) deploy your script in a shared way)...
Alternatively, you can proxy their result. Create an endpoint on your server, and have that endpoint open a connection to the target endpoint, and simply funnel traffic backwards.
Yes Fiddler is an option for me:
Open Fiddler menu > Rules > Customize Rules (this effectively edits CustomRules.js).
Find the function OnBeforeResponse
Add the following lines:
oSession.oResponse.headers.Remove("X-Frame-Options");
oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
Remember to save the script!
As for second question - you can use Fiddler filters to set response X-Frame-Options header manually to something like ALLOW-FROM *. But, of course, this trick will work only for you - other users still won't be able to see iframe content(if they not do the same).
I have an Html file containing the following code:
<script>
Object.defineProperty(document, "referrer", {get : function(){ return "myreferrer.com"; }});
//document.location="somelink.com";
</script>
From what I've read,maybe the thing I'm trying cannot be done,but I wanted to be sure.
I want to visit the site somelink.com but when my browser finishes the redirection to the location,the document.referrer value to be "myreferrer.com".
If I run the html with this format(document.location in comments)
the command in url --> javascript:alert(document.referrer) is the one I want.
But if I erase the comments and activate the document.location line,the above command will show up an empty document.referrer and not the one I want.
Can I achieve what I have in mind?
Some browser versions allowed you to customize the referer header using the approach of overriding the document.referer property in javascript, but that doesn't appear to be reliable. Even if some browsers still allow that, there's no guarantee it would work in future versions.
If you need a workaround, you could link to the desired referrer domain and serve up an intermediate page that performs the navigation to the final destination URL via an HTML form submission. That should preserve that intermediate page as the referrer.
Within the context of a browser extension however, you can alter the headers via onBeforeSendHeaders
So my ISP (Smartfren; Indonesia) has decided to start injecting all non-SSL pages with an iframing script that allows them to insert ads into pages. Here's what's happening:
My browser sends a request to the server. ISP intercepts it and instead returns a javascript that loads the requested page inside an iframe.
Aside being annoying in principle, this injection also breaks any number of standard page functionality; and presents possible security hazards.
What I've tried to do so far:
Using a GreaseMonkey script to nix away the injected code and redirect to the original URL. Result: Breaks some legitimate iframes. Also, the ISP's code gets executed, because GreaseMonkey only kicks in after the page is loaded.
Using Privoxy for a local proxy and setting up a filter to clean up the injection and replace it with a plain javascript redirect to the original URL. Result: Breaks some legitimate iframes. ISP's code never gets to the browser.
You can view the GreaseMonkey and Privoxy fixes I've been working on at the following paste: http://pastebin.com/sKQTvgY2 ... along with a sample of the ISP's injection.
Ideally I could configure Privoxy to immediately resend the request when the alteration is detected, instead of filtering out the injected JS and replacing it with a JS redirection to the original URL. (The ISP-injection gets switched off when the same request is resent without delay.) I'm yet to figure out how to accomplish that. I believe it'd fix the iframe-breaking problem.
I know I could switch to a VPN or use the Tor browser. (Or change the ISP.) I'm hoping there's another way around. Any suggestions on how to eliminate this nuisance?
Actually now I have a solution:
The ISP proxy react on the Accept: header that the browser sends.
So this is the default for firefox:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Now we are going to change this default:
And set it to: Accept: */*
Here is how to setup header hacker for google chrome
Set the title to anything you like:NO IFRAME
Append/replace select replace with
String */*
And Match string to .* and then click add.
In the permanent header switches
Set domain to .* and select the rule you just created
PS: changing it in the firefox settings does not work 100% because some request like ajax seem to bypass it so a plugin is the only way as it literally intercepts every outgoing browser request
That's it no more iframes!!!
Hope this helps!
UPDATE: Use DNSCrypt is the best solution 😁
OLD ANSWER
Im using this method
Find resource that contain iframe code (use chrome dev tool)
Block the url with proxy or host file
I'm using linux, so i edited my hosts file on
/etc/hosts
Example :
127.0.0.1 ibnads.xl.co.id
I've recently got an email from Google, saying that they are going to ban my AdSense account because I'm sending Personally Identifiable Information to them with my Google AdSense tag requests. It says that around 1% of requests from my website have a referrer of:
some_user#my_website.com/some/subpage
and they consider some_user#my_website.com to be PII (even though it can be completely made up abcd1234#my_website.com). More on this here: https://support.google.com/adsense/answer/6163366?hl=en .
I never link to this kind of URLs (the only form I use is my_website.com/some/subpage), but I guess my users sometimes enter it manually (since product-wise my website is providing an email service, it may seem reasonable by some logic).
I figured URI of some_user#my_website.com/some/subpage is legal since http basic auth allows for specifying user like this. When I entered it manually to Firefox, some_user# disappears from the location bar but in the Net panel of Firebug I can see all files are indeed requested from some_user#my_website.com/some/subpage and that's how Google sees it too.
I though that as a brute-force solution even something like:
if uri contains '#':
redirect to my_website.com
would do.
I'm using NGINX/UWSGI/Python Paste + JS. I've tried to implement the above condition both on server side and in JS, but my URI always says my_website.com/some/subpage even if I manually put some_user#my_website.com/some/subpage in the browser address bar.
I've also tried configuring basic_auth in NGINX to disallow providing any user but with no effect.
How do I get rid of these requests?
How do I get the FULL URI (with some_user#) in JS? I tried document.URI and window.location.href but they didn't contain the user part...
Apparently presence of user# part in the URI can be detected by examining window.location.href. I haven't noticed it before since window.location.href only contains user# in Webkit-based browsers (e.g. Chrome, Opera, Safari) but not in Firefox!
To resolve the problem I've added a check on that in JS + a JS redirect to an URL without user[:password]#.
Hopefully Google uses the same variable to figure out referrer for the ad requests, so it get PII only from Webkit browsers & fixing it for Webkit suffices. Will keep you posted.
I'll try to explain it as easy as possible.
Replication:
I'm doing an auth/login system where:
The user input him credentials and send the data to the server [classic form].
The server check everything and then (if it's ok) set up a session in the server and response an static view which is rendered using handlebars and by passing one variable: sessionName.
This view includes a js snipet which add a cookie using the code below: document.cookie += ';session_name={{ sessionName }}'. At this moment, all is still correct. And the cookie is added correctly.
And then it redirects to the root of the website. At this point, I expect to have the cookie I set before. But there's not.
Relevant data:
The variable sessionName is compiled properly.
The Analytics [Mixpanel and Google Analytics] cookies are persistent.
I tested in Chrome 39 and Firefox Developers Edition using Mac OSX Yosemite.
The server uses node.js and hapi.js of Wallmart Labs with the hapi.js plugin hapi-auth-cookie
I also tested to set the cookie manually but it doesn't persists neither. Any kind of the ones that I use.
The cookie is a simple string; accurately: hubato so: ;session_name=huabto.
TL;DR
My cookies doesn't persist when navigating. Regardless how or what I set in the cookie.
I had to add the path=/ parameter and it works like a charm!
You can find all the information related to the cookies here.
And beware of the characters you're using because not all of them are allowed.