Let's say I set a cookie on an image request in an email (so the cookie is set when the user views the images in the email). If the user then clicks through the email so their browser opens, will the browser have access to the cookie I just set?
Obviously, if the user has Outlook as their email client and Firefox as their default browser, the email cookie (if it exists) will not be accessible. But what if they use IE? On an iPhone or Android phone, what happens?
I found another interesting post on this topic:
So cookies are usually served with HTML requests over HTTP. Email is not HTML served over HTTP, it's HTML over IMAP or POP. Since there's no HTTP request for the HTML, there's nowhere for cookies to be sent.
HOWEVER, there is a caveat. While your HTML is not served with an HTTP request and contains no cookies, the images in your email are requested via HTTP. Its possible your image server(s) could send cookies and most email clients will send the cookie back if the image is re-requested. There's no breakdown on mail client support for cookies, but I know the Outlook suite on PC definitely will respect cookies in image request headers. We saw this in testing our image validation software, there are a VERY small number of image servers out there that are sending cookies. It's likely you are not in this bucket, though, since it is rare.
I am not a lawyer, but reading this link,
https://ico.org.uk/for-organisations/guide-to-pecr/cookies-and-similar-technologies/
I think you are ok not including the message. You are definitely ok if you can confirm no cookies are served along with your images. However, I am not a lawyer.
Let's also remember that e-mail can sometimes be opened in a browser, where the HTTP protocol is used.
Another issue is that the person can be tracked not only using cookies but also, for example, with the personalized link.
I hope I helped someone.
I think you answered your own question...
It's a client-side problem (for you). It's "catch as catch can". No Guarantees any combination you use will be 100% fool-proof.
Outlook to Safari (or FF, Opera, etc). There are too many variables. Not to mention any one of your recipients could have their email client set to Plain Text.
I got the best tracking by assigning a query parameter to the images as well as ALL the links.
But I've never found a solution that actually accounted for 100% of the emails that were sent (comparing/tracking view rates afterward).
I don't think the cookies are carried across. You might want to make a token to put in the query string and authenticate a session that way.
Related
If ideologically I oppose to the policies of a certain browser's ​developers (I think that the browser harms the users), can I somehow block that browser from accessing my website?
I would assume that such block would have to be backend, frontend won't help here, but can backend languages such as PHP/Ruby/C++/Python, etc. really help for that sake?
Your server can look at the HTTP_USER_AGENT header in the HTTP request that the client sends to the server. This header typically contains information about the user agent that made the request - i.e. if the request originated from a web browser, then the user agent information will generally contain the vendor and version of the browser. So, your server can respond conditionally based on what the client sends in this header.
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent for more info, and for examples of user agent strings for a number of widely used browsers.
However, be aware that the HTTP_USER_AGENT header is populated by the client. Therefore, this header cannot be trusted, as it can easily be forged by the client.
I have a front end HTML website that posts requests to a WebApp hosting online. These html pages run locally on any machine. Thus, they are making cross site requests.
I am thinking of saving cookies and validating these cookies in each request that is sent to my WebApp. Is that the best way to go?
Also, when the user goes back and forth from 1 page to another, (and it is required that he is logged in), do i send a request with cookie from the HTML at the start of the page and redirect him to login page accordingly if his cookie is not valid?
Thanks in advance,
The way you are planning to go about seems alright. Ofcourse you will have to think well about how you are going to save your access tokens. I would use an access token with the IP, username and session expiration date encoded in it.
However just checking on page load would not be the best idea since the result of the check could be spoofed. You should sent this acces token with every request for information so your webapp can decide wether or not to reply with information.
I'm fairly new to website development. I'm working on a site where the user logs in with username/password, and gets a sessionID from the server in response. This sessionID is sent back to the server (and a new one returned) with each request.
I'd like the site to work properly if the user opens it in multiple tabs or windows. i.e. once logged in at one tab, opening a members-only URL in another tab works without loggin in. (And, logging out in one tab logs out from all.) I see no way of doing this without storing the latest sessionID in a cookie. That way the latest sessionID can be "shared" among all tabs.
However I am starting to read up on cookies, and some of the security threats. I was unaware that cookies were sent with every request. I don't need to send my cookie to the server, ever. The sessionID is added to the xhr request's headers -- not read as a cookie. So I'm wondering if there is a way to disable sending of this cookie. My only purpose for it is to allow multiple tabs/windows in the same browser to share the same session.
I was reading up on the path parameter for cookies. Apparently this can be used to restrict when the cookie is sent to a server? What if I set the path to something that would never be used? Would this prevent the cookie from ever being sent out automatically? I only want to access it from JavaScript.
A coworker has put a lot of safeguards into the server-side of this application, which I won't go into here. So this question is just about what client-side precautions I can and should take, particularly with cookies, for optimal security. If there is a better way to allow a members-only site to work properly with multiple tabs open at once, I'm all ears.
I discovered just now that in HTML 5 there is local storage, which stores key/value pairs much like a cookie, but is not sent with every server request. Since it's supported in every browser except IE 7 and earlier, I'll be switching to this to enable sharing data between tabs when available, and use cookies instead on IE 7 and earlier.
The sessionID is stored in a cookie already there's no need to manage it. Because the HTTP protocol is stateless the only way to maintain state is through a cookie. What happens when you set a session value the server will look up the dictionary of items associated with that cookie id (session Id).
What is meant by stateless is that between requests HTTP does not know if your still alive or have closed your browser. Therefore with each request the browser will attach all cookie values to the request on the domain. SessionId is stored in the cookie automatically when they go to your site. The Server then uses that value to look up anything you've set in the users session.
Depending on which programming language and/or server you're using the session could be handled differently but that's usually abstracted away from the programmer.
Now with respect to sessions, there are a number of different things that make them insecure. For example if an attacker were able to get their hands on your session cookie value they could replay that cookie and take over your session. So sessions aren't a terribly secure way of storing user information. Instead what most people do is create an encrypted cookie value with the users details, the cookie could be a "session cookie" meaning as soon as the user closes their browser window the cookie is thrown away from the browser. The encrypted cookie contains user information and role information as well as some identifier (usually the clients ip address) to verify that the user who is submitting the request is the same user the cookie was issued to. In most programming languages there are tools that help in abstracting that away as well (such as the ASP.NET membership provider model).
Check out some details on the HTTP protocol and HTTP cookies on Wikipedia first
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
http://en.wikipedia.org/wiki/HTTP_cookie
and check out the membership provider model on ASP.NET, it's a really good tool for helping to secure your site.
http://msdn.microsoft.com/en-us/library/sx3h274z(v=vs.100).aspx
Preventing the browser sending cookies seems to defeat the object of using cookies in the first place.
If you don't want the sessionID to be sent with each request, why set the cookie? A better solution would be to use a custom response header that you send from the server to the browser - this will then be under your control and will not be sent automatically with all browser requests. You are using request headers to send your sessionID anyway so you could receive them from the server using a custom header and read this into your JavaScript from each XHR.
I'm not 100% sure that I'm using the correct terminology or if I'm leaving out information that is required to answer. So please be patient with me.
My client wants to include a video feed from an outside source inside a members area of their website. The members area is delivered over https and the video feed is not. Does this compromise the secure data?
I know that some browsers alert the user that there are secure and non-secure data being loaded on the page. Frankly, my client is okay with that, but I don't want to move forward if the user account information (specifically, session, etc.) is compromised.
Thanks for any help.
If your pages references unencrypted Javascript or Flash, you're totally unprotected; an attacker can substitute any Javascript he wants, and can steal non-HTTP-only cookies, or make arbitrary HTTP requests that impersonate the current user.
If you reference unencrypted CSS, you're still vulnerable; attackers can arbitrarily modify your layout, and can execute arbitrary code in IE and Firefox.
If you reference unencrypted images, you're mostly fine; all the attacker can do is see the Referer header and find out what page the user is seeing. (He'll also get any non-SSL-only cookies for the image's domain).
The attacker can also alter the images to suit his needs, which may be a concern.
If you identify your user based on a cookie, e.g. using a standard SessionId, then you are vulnerable, even if only referencing static images.
By default, the user's browser will resend the session cookie for each request to the same host, irrelevant of protocol. I.e. you securely authenticated your user using HTTPS on your login form, and ensure to continue using HTTPS for all sensitive pages...
However, you also include "non-sensitive" images over HTTP... the user's browser will happily send the sensitive session cookie over non-encrypted, non-secure, plain-text HTTP, when requesting those images.
Then it's just a matter of grabbing that cookie from HTTP, and impersonating your users back on the secure part of the site.
Note, this is by default.
You CAN change this behavior, by adding the secure; attribute to your cookies. Depending on your framework, you can configure it to happen automatically. Again, this is not the default, you have to explicitly change it.
And while you're at it, add the httpOnly; attribute too.
Regarding cross-site request forgery (CSRF) attacks, if cookies are most used authentication method, why do web browsers allow sending cookies of some domain (and to that domain) from a page generated from another domain?
Isn't CSRF easily preventable in browser by disallowing such behavior?
As far as I know, this kind of security check isn't implemented in web browsers, but I don't understand why. Did I get something wrong?
About CSRF:
On wikipedia
On coding horror
Edit: I think that cookies should not be sent on http POST in the above case. That's the browser behavior that surprises me.
Why wouldn't the browser send cookies?
Site A (http://www.sitea.com) sets a cookie for the user.
User navigates to site B (http://www.siteb.com). Site B features integration with site A - click here to do something on site A! The users clicks "here".
As far as the browser can tell, the user is making a conscious decision to make a request to site A, so it handles it the same way it would handle any request to site A, and that includes sending site A cookies in the request to site A.
Edit: I think the main issue here is that you think there is a distinction between authentication cookies and other cookies. Cookies can be used to store anything - user preferences, your last high score, or a session token. The browser has no idea what each cookie is used for. I want my cookies to always be available to the site that set them, and I want the site to make sure that it takes the necessary precautions.
Or are you saying that if you search yahoo for "gmail", and then click on the link that takes you to http://mail.google.com, you shouldn't be logged in, even if you told gmail to keep you logged in, because you clicked on the link from another site?
It isn't that a browser is sending the cookie to or from an outside domain, it's the fact that you're authenticated and the site isn't validating the source of the request, so it treats it as if the request came from the site.
As far as whether a browser should disallow that... what about the many situations where cross-site requests are desirable?
Edit: to be clear, your cookie is not sent across domains.
I don't know that there's much the browser can do in that situation since the point of an XSRF attack is to direct the browser to another point in the application that would perform something bad. Unfortunately, the browser has no idea whether or not the request it's being directed to send is malicious or not. For example, given the classic example of XSRF:
<img src="http://domain.com/do_something_bad" />
it's not apparent to the browser that something bad is happening. After all, how is it to know the difference between that and this:
<img src="http://domain.com/show_picture_if_authenticated" />
A lot of the old protocols have big security holes -- think back to the recently-discovered DNS vulnerabilities. Like basically any network security, it's the responsibility of the end-points; yeah, it sucks that we have to fix this ourselves, but it's a lot harder to fix at the browser level. There are some obvious ones (<img src="logoff.php"> looks damn fishy, right?), but there will always be edge cases. (Maybe it's a GD script in a PHP file after all.) What about AJAX queries? And so on...
The cookies for a site are never sent to another site. In fact, to implement a successful CSRF attack, the attacker does not need to have access to these cookies.
Basically, an attacker tricks the user, who is already logged in to the target website, into clicking a link or loading an image that will do something on the target site with that user's credentials.
I.e., the user is performing the action, and the attacker has tricked the user into doing so.
Some people have said they don't think there's a lot the browser can do.
See this:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
It's an overview of a proposal for a new HTTP header to help mitigate CSRF attacks.
The proposed header name is "Origin" and it's basically the "Referer" header minus the path, etc.