Is it possible to change the HTTP_REFERER value in VBScript? To avoid XSS attacks I am using CSRF data in my links. But when I am linking the user to an external website, this CSRF data could be caught by the destination webpage if they are checking the HTTP_REFERER.
So I read you should put an intermediate page in between, which will redirect to the desired page. So I tried creating a page named RedirectPage.asp which takes the URL as a parameter and does a Server.Redirect. But if I would click an external link on pagex.asp?CSRF..., the final HTTP_REFERER I catch is still pagex.asp.
So is there a way to "clean up" my REFERER header?
Thanks!!
By using a meta redirect instead of a redirect header, you can alter the referrer in Firefox and IE, but not Chrome, as mentioned here: https://stackoverflow.com/a/2985629/160565
You can consistently clear (not change, but eliminate) the http_referer by redirecting through an SSL page however.
To save yourself a redirect, you could also check for browsers that support the rel="noreferrer" html5 attribute and use that instead in those cases. I believe currently that's just webkit browsers.
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer
Related
In our application we have some elements that work with ajax.
We offer users to embed parts of the app in an iframe.
Everything work fine in Chrome and Mozilla. In Safari we get 422 error, and the server log looks like this:
2015-07-15T08:26:06.818885+00:00 app[web.1]: Completed 422 Unprocessable Entity in 4ms
2015-07-15T08:26:06.815411+00:00 app[web.1]: Can't verify CSRF token authenticity
2015-07-15T08:26:06.823389+00:00 app[web.1]: ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
We figured out that if we access directly the iframe url AND THEN to the page which contains the iframe it works fine, which might indicates that it has to do with cookies.
I tried this solution, but we still have this problem.
Safari does not (by default) allow cookies to be set in iFrames unless the user has visited the site already. Imagine this code:
# a.com
<iframe src="b.com/iframe">
If you visit b.com directly (any page) and it sets a cookie, then Safari will send that cookie when you visit a.com and the iFrame to b.com is loaded.
However, if you visit a.com without first visiting b.com, then Safari will ignore any cookie that b.com/iframe tries to set.
The solution is described here (if the link doesn't work for you, here is version saved by web archive) in the section called "A solution for Safari".
Detect if cookies are supported.
If not, put an overlay on the page saying, "This site requires cookies. Please click here to continue."
When the user clicks on the link/button, open a popup, which sets a cookie and closes itself. On desktops you can make the popup fairly small and innocuous. On mobile devices it is uglier since you can't make the popup smaller than full-screen. However, either way the popup is only on screen for less than a second.
The iframe reloads itself and it can now use cookies.
Finally I figured out that Safari does not allow keeping cookies in iframe.
It means that if you need to use cookies, you need to do something.
The solution I found is this:
In the iframe code check if session[:safari_cookie_fixed] exist. If not, render a code that will communicate using postMessage with the parent window and let him know that we need a redirection.
The parent window send a signal via postMessage to the iframe when the iframe is loaded. The listener, which was rendered in case the cookie does not exist, send a signal to the parent to perform redirect, and the parent does a redirection to /set-cookie page in the iframe domain, adding its current url as a query-string parameter.
set_cookie action save a cookie safari_cookie_fixed and redirect back to the parent page (which its url is available in the query-string)
Of-course this solution requires adding some js code in the parent page, but when you give your user the iframe html code you can include the js as well.
The title ways it all. I want to use a cookie to send some metadata over to the client that is specific to the current page he is viewing. I'd rather not put it in the HTML, mainly because the metadata is only calculated after all the HTML is already generated and the closing </html> tag is in place.
Previously I was simply sticking it in a hidden <input/> after the final </html>, and browsers seem to render it fine, but I want to do the same thing while having standards compliant HTML. Although I want the cookie to be sent back whenever the client makes an ajax call to the server, I want it to invalidate immediately upon leaving the page.
If the page is in an unique path (or can be URL-rewritten as such), then just set the cookie's path attribute to the page's full path. The browser will send the cookie only back whenever the page URL is covered by the cookie's path.
Alternatively, depending on the concrete functional requirement, you could also consider using the HTML5 data attributes.
If you click on a result in Google Instant, the referer sent by your browser to the destination website contains a bunch of parameters, including the all important q=[autocompleted query]
But you're coming from a page whose URL is simply http://www.google.com/ with a bunch of stuff after the # character, i.e. as an on-page anchor.
So the browser appears to be sending a URL as the referer which is different from the URL of the page that you were viewing when you clicked.
There doesn't seem to be an additional redirection, so how on earth do they do that?
Most of the time, a Google search result actually sends you to a Google redirect page rather than directly to the target page. They use JavaScript to switch the target of the link onmousedown as you click on it.
You can see this effect by click-and-holding on the search result link and watching your status bar.
This isn't specific to Google Instant, they've been doing it for quite a long time on their standard results pages.
The page anchor part of the URL can be manipulated client-side without a new request to the server. Even when talking about static anchor links (e.g. Section Foo), clicking on them does not cause a new request to be sent to the server; it is processed completely within the browser.
The javascript being used by Google to make Google Instant work is simply altering the anchor programatically before making a request to the server.
What Google are you using?
My URL after searching is this:
http://www.google.es/#sclient=psy&hl=es&q=something+to+search&aq=f&aqi=g4g-o1&aql=&oq=&gs_rfai=&pbx=1&fp=b0....
It does include the q= part
Can I call the server to set a new cookie with an AJAX request (that is, after the page has already loaded)?
For example, when a visitor hits a link, ajax would open a php file that sets a new cookie like this:
setcookie('cookiename', 'true', time()+3000, "/",'...');
But this is done after the html (the page containing the actual <a> tag pressed) was rendered. Is it nevertheless ok to set cookies in ajax? (maybe because the php file loaded is separate from the original html page).
You can have the server's response set a cookie, certainly. Remember that cookies are an HTTP thing, not an HTML thing; the fact that your original HTML file is already on the browser is irrelevant. Your ajax request is a separate HTTP request to the server, which (hopefully!) generates an HTTP response back to the browser; and that response can include a new Set-Cookie header.
I'm not a PHP person, you'll need to check that there are limitations in the PHP mechanism you're using for setting the cookie (I can't imagine there are). But fundamentally, no, there's no problem doing this. I've done it with both JSPs and classic ASP.
I've set cookies in the response to AJAX requests on my site and I haven't had any problems with it yet. (Although I haven't looked for problems.) It could be that some browsers don't set cookies when receiving them in an XmlHttpRequest but so far I've seen it work in IE, Chrome and Firefox.
Why not use javascript to edit cookies? Return the content of the cookie in JSON format and use javascript to store the values.
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1