This is a newbie question.
Using HTTPS the whole time taxes servers since everything has to be encrypted/decrypted.
In case I only want to protect the session ID sent to the browser and saved as cookie to avoid man-in-the-middle sniffing the session ID, I was wondering if HTTPS can be enabled only when the browser sends the session ID along with the HTTP query, while the reply is sent by the server in plain HTTP?
Thank you.
No, this isn't possible -- the browser and server collaborate to set up a two-way channel and will use it for both directions.
In any case, a large part of the overhead from using SSL comes when setting up the connection, rather than using the connection, and you wouldn't be able to save on this overhead.
You could write a filter which took every request and redirected to non-https equivalent URLs?
That way every request would be request https, then responded to http?
Related
I have read some articles about preventing session hijacking, and most said to use https on your site, but I don't understand how https can prevent session hijacking
how do https prevent session hijacking?
Session hijacking can also be performed by someone sniffing your network traffic. For example, imagine that you're connected to Stackoverflow via HTTP, and there's someone reading every request you send to the server. Every time you access to a different page, you'll send your authentication cookies, along with your request to Stackoverflow, so it'll know that you're logged in, and it'll not ask you to log in again.
The problem is that since your communication is being performed as plaintext, that attacker can read your requests, he'll be able to grab your authentication cookies, and he'll be able to impersonate you.
Now, if you're using HTTPS, you're communicating over an encrypted channel. Even if an attacker is sniffing all your requests, he'll not be able to get any meaningful information, because he'll only see encrypted text. That's the reason why HTTPS is good to prevent session hijacking.
Of course, there are different ways to hijack a session, and a man in the middle is just one of them, so maybe you should take a look at this: https://www.owasp.org/index.php/Session_hijacking_attack
Also, just as a side-note, "just using HTTPS" is not a panacea, it needs to be properly configured and implemented, so if you're the one who'll be performing some server-side configurations, I highly recommend you to read more about the protocol and attacks on the protocol, to avoid some common mistakes (like enabling old versions of SSL, or using broken algorithms, like RC4).
I'm not getting my head around the whole session-management thing.
I've now implemented this to take care for the login process and also this example to protect my services from XSRF attacks.
But now that I'm having it I wonder:
If I turn on SSL, is the cookie sent before a secure connection is built up? So is this session ID (the cookie) ever secure?
Is it save to send the cookie on each request to identify the user? E.g. if a user wants to view his/her settings, to make sure it's not a fake request that tries to retrieve the settings from another user. Is it clear what I mean by that? I would send the session ID on each request, compare it to the session ID in my database and if the request-token (XSRF securiy) is fine I execute the request - or is that too much overhead?
I'm still not quite confident if what I'm doing here is 100% correct and I want to make sure that I don't unnecessarily break any security measures I've spent time implementing.
SSL or TLS connections are established before the HTTP request is sent over the wire, so data in the request is encrypted.
I'm not sure I understand your second question, but a lot of web applications use cookie based authentication to identify the user. As cookies are automatically sent to the website, you have to protect yourself against CSRF attacks.
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.
Let say, I make a call to a HTTPS server. THe server send me back http response. Is there a way I can change the http response in the client side? (i.e. any javascript..etc)
Thanks.
--- UPDATE ----
Well, for HTTP request, let say a javascript making a ajax call with query=123456. Of course, I can intercept it and change query=123456 before it is sent it out. (if I want to hack).
But, when the http response come back, is it possible that I can intercept the data and change it before it reach the browser. assuming that it is HTTPS.
--- More ---
The actual program I am writing require the data from server be secured. because the javascript code will be public (thus anyone can inject into their page), I have to make sure the response data sent from my server will be the same as the one the javascript side receive it.
sorry for the initial question not being clear. :)
The best you can do is make sure the data sent from the server is correct. That's all. On the client side, all bets are off by definition. If the connection to the server is SSL secured, it's harder for anybody to mess with the data, but by far not impossible. One of the advantages of an HTTPS connection is that the identity of the server is confirmed. That's displayed to the user in form of a security lock or a green address bar or whatnot. And conversely, when a certificate is invalid, the browser will complain to the user about it. It's completely up to the user to notice or disregard all that though.
Javascript can be manipulated on the client or by a man-in-the-middle attack between your server and the client, data can be manipulated the same way, there's no guarantee for anything on the client side. Which is why the client should never be entrusted to do anything of importance, the server needs to have the last say in anything. SSL can help indicate to the user whether a connection is trusted or not, but it's no guarantee.
You can create a proxy and have your traffic go through the proxy. The proxy would have to, using the proper certificate, "decrypt" the traffic and then "encrypt" it and send it on it's way. But why would you want to? This sounds malicious.
I dont see what good changing data going to the browser is going to do unless you're trying to fool the suer.
Try playing around with fiddler for a bit.
How does one go about securing parts of an HTTP request, say their Session ID? I know you can use HTTPS, but then your servers must decrypt all of the request. Wouldn't it be ideal to only encrypt the required parts of a request?
Are there any frameworks or resources out that that allow you or inform you how to do this?
HTTPS is the correct tool to use. The computational load of decrypting the packets is very low. Google changed to HTTPS by default for the whole of GMail earlier this year, and they report that the CPU load on their servers for SSL encryption/decryption is around 1%.
If you only encrypt part of the stream then you still have the problem of man-in-the-middle and replay attacks. SSL is the only way to prevent these. It doesn't really matter if the session ID is encrypted. If a man-in-the-middle can capture it, he can reuse it in it's encrypted form, and the server wouldn't know the difference.
Here's a blog post about Google's experience since the GMail switch to 100% SSL.
HTTPS is all or nothing. If not all elements on a page are secured with HTTPS then users will get usually get a "broken lock" in the upper left corner. This is because an attacker could use this to inject an attack similar to xss and obtain the document.cookie value.
Further more if 1 request is sent with a session id then an attacker can obtain the value and authenticate as you.