I'm visiting a website and soon I click on a bookmark in my browser. A new website is opened. My question is:
Does the referer data (which is submitted to the new website) only contain the bookmark info or is my last visited website also within the data?
I'm really not sure about it.
Testing with Google Chrome and Fiddler shows that Chrome doesn't send a Referer header when fetching a page after clicking a bookmark.
An HTTP referrer is only sent if the user arrives from a resource with a URL (generally, another web page). Typing in a URL, clicking on a link in a desktop email program, word document, etc., or opening a bookmark all do not send a referrer, because those sources do not have URLs of their own.
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from which
the Request-URI was obtained (the "referrer", although the header
field is misspelled.) The Referer request-header allows a server to
generate lists of back-links to resources for interest, logging,
optimized caching, etc. It also allows obsolete or mistyped links to
be traced for maintenance. The Referer field MUST NOT be sent if the
Request-URI was obtained from a source that does not have its own URI,
such as input from the user keyboard.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Note that there is no guarantee that a referrer will ever be sent, even if the source does have a URL.
Related
I am particularly new to security in websites.The day before, I logged in to my college website via my roll number, password and a captcha code. When I opened the developer tools on Mozilla, I could see one Post request (my details) being sent over the network.
I studied in my college course that there are 2 ways to send these type of details to a server. One is via URL arguments and other is through the http parameters. I clicked on the parameter tab of this POST request and I see the my login details in plain text like this :
LoginId -
Password -
Captcha - .......
Does it mean that these details are being sent as it is? or these details are only visible to me? Forgive me if it's too lame.
"Does it mean that these details are being sent as it is?"
It depends. If the request is sent through HTTP, yes. If the request is sent through HTTPS, no.
You can install a proxy such as Charles to observe. When the login request is sent through HTTP, the request URL and body are all visible, which means if someone is sniffing packets on internet, he/she can easily see your login id and password. It's visible to everyone.
When the login request is sent through HTTPS, however, in Charles the request URL would be "unknown" and the request body would be a bunch of unreadable code (encrypted). It indicates that even if someone is sniffing, it's impossible to steal valuable information. It's only visible to you.
When we click a link on a website and visit that link the HTTP request contains the previous site as the HTTP referrer. But if I click a link inside a email I have received, that HTTP request does not contain a HTTP referrer field...(clicking a link in a email received to my gmail)
So my question is, do we have a method to distinguish between these two scenarios ?
I mean any method to identify these two clicks separately using parameters in the HTTP request
I think, that when You click a link on a https page the header not contains the HTTP referrer (in php: $_SERVER['HTTP_REFERER']). And google use https, so from links in gmail the HTTP referrer not send.
Just like explained in my previous answer, don't rely on the referrer.
Just use a query string parameter like &source=email, &fromemail=true or &campaign=email.
Original post:
This web application sends out emails which contain a link to a URL.
Correction-Clarification 9/17/2014:
An .EXE running as a scheduled task on a server (in "support" of the web app and connecting to same database) sends out emails which contain a link to a URL.
The nature of the email content is essentially a "reminder"; the link when clicked is essentially an acknowledgement signaling "done".
Resumption of original post follows:
Clicking the link in the email does 2 things at the target .ASPX page:
the page logic updates a database and sends another email to the same user
the page finishes by displaying a "success" message in the browser
Would it be bad design to eliminate the success message sent by the browser?
I'm thinking the opening of the web page just to announce "success" is not needed. If the target URL were replaced with something with no user interface (e.g. HTTPHandler, webservice) then I'm thinking the email sent back to the same user confirming "success" would be adequate.
Yet, part of that approach "feels awkward", I guess because normally clicking on links in emails causes web pages to open. Given these requirements, would this be bad design to eliminate the browser?
UPDATE - 10-17-2014:
see: Submit to HttpHandler results in RequestType GET instead of POST
update below
Actually, it's bad design to have a state change occur based on a GET request. A number of email systems (and virus scanning software) will follow the link in order to determine whether it should be quarantined or not.
Never mind that a GET request causing a change in state is pretty much against how the web is supposed to work anyway.
What should happen is they click the link, then the mail program opens the browser. You then show a page asking them to confirm the action by clicking a button. That buttons makes a POST request which you then act on.
Finally, I'm not entirely sure how you would eliminate the browser anyway. The mail program detects that it's a link and opens the browser once the user clicks on it. This is no different than how things like opening word documents or zip files. The email program just asks the OS what program is supposed to handle the action and passes it off to that program.
With your update, I think there's a much cleaner way. However this is dependent on the capabilities of the email client that'll be receiving the messages. Should be good for the vast majority of them.
In the body of the email, instead of sending a link, include an HTML form that contains a button which performs a postback to your server. See this ( link ) for samples of how some other companies have done it.
This way the action is a single step instead of two AND you aren't doing things the Wrong Way(tm).
For a web app I want to let users review and edit a record they made previously through a browser form. In their confirmation mail, they get an access link with a secret token, like http://myapp.com/edityourstuff/hdD8sF2m Clicking this link shows them a form in which they can edit the existing data they submitted earlier.
This is not as secure as a username/password combination, but much more convenient and suitable for my situation.
However, I want to make this as secure as possible.
GET URLs
If the link containing the secret access token is disclosed, unauthorised people can access the data. My concern here is about shared/public computers.
I was planning to tackle this problem with the following pattern:
Access to /edityourstuff/ds8sdfhe via link in email
Start a session, store the secret token in there
redirect to clean /edityourstuff without token
The app now has access to the token in the session and can display the form accordingly. And the URL bar does not show it.
My question now is: Do browsers store the initial URL, that immediately redirects to the clean URL in their history?
I know that the different HTTP redirect status codes (301, 302, 303) have different use cases in theory. Is there any information on how different browsers treat the different redirect codes in respect to (not) storing the initial URL in browser history?
I just did some quick testing myself, with Firefox 7.0.1
When using the above pattern, no matter if 301, 302 or 303 redirect, Firefox does not return to the initial URL when clicking the back button. However, it is shown in the full browsing history and is part of the URL completion list of the browser bar.
This is exactly the drawback I was hoping to avoid.
I have a login page and users from different domains are redirected to this page for the purpose of SSO. I use the referrer HTTP Header field to know where the user has come from, thus on successful login, I return him/her back to his/her original domain.
But sometimes my referrer is not set, while other times it's set. Why?
Users can come to your page using different methods:
By entering the URL of your page, directly into the address bar of the browser
By clicking a link to your site from another site
By reloading your current page
By Submitting a form on your site (sending POST request back to your site)
By navigating through back/forward buttons of your browser.
By being redirected through a previous page to the current page.
Now, browsers really differ in how and when they set referrer header field. But as a general rule, you can be sure that on link click, or on submitting a form (post request), they set referrer field. Also if you have come to the current page via a redirect or a link, browser still preserves referrer header on F5 (page reload).
If you see that your referrer field is empty, it's because someone knows your Login page URL and enters that directly into the address bar, or someone has bookmarked it, so sends a GET request.
Generally, you shouldn't always expect the referrer field, because it's outside your control. You should use cookies, or query strings, because they are under your control.
the other thing is that some user may have referer option set as disabled in their browsers as a part of browser security settings.