0

I'm using cookies in my Java EE application (jQuery on the client) and while taking security as a key point, I came to know that one can read the cookies and edit them by reading article's. I'm really want to make application out of these attacks.

I read How to prevent Javascript injection attacks within user-generated HTML on SO and didn't find a solution to make my cookies secure.

Community
  • 1
  • 1
Suresh Atta
  • 120,458
  • 37
  • 198
  • 307
  • 1
    What exactly are you using the cookies for? Does your backend support sessions and session id's? using session id's and storing the data in the session isn't bullet proof, but it's atleast more secure than storing a userid directly in a cookie. – Kevin B Mar 01 '13 at 19:33
  • yes exactly ,session id's and some transaction ids of users also . – Suresh Atta Mar 01 '13 at 19:34

3 Answers3

1

Unless there is some other vulnerability in your site (or the user's system), there is no way for a third party to modify cookies.

Therefore you can treat them exactly the same as you would any other data that comes from the client (except that you don't need to worry about cookie data being faked with a CSRF attack). That is to say: Trust the cookie as much as you trust the user.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
1

There are several flags you can set for cookie to mitigate the security risk.

  1. The secure flag. It mandates that cookie should only be sent through https. This is important, even when your site is using https. Why? Let's say a bank site forces end user to use https. The user connects to the bank site through https, login successfully. The bank site sends the cookie back to the user browser through https. Assuming a hacker can sniff the network and see all the cleartext communcation between the end user and the bank site. Obviously for now, the hacker cannot see anything, as the cookie is transmitted through secure channel. Here is what the hacker can do if the HttpOnly flag is not set

    a) The hacker creates a site www.maliciouscode.com.

    b) He sends an email to the end user with the link, luring the end user to the site.

    c) The user takes the bait, connecting to http://www.maliciouscode.com site through another browser tab.

    d) The malicious site redirects the user browser to the bank site through http.

    e) The user browser sends the cookie through HTTP to the bank site.

    f) The hacker intercepts the cookie since it is sent as cleartext, places it in his own browser and login as the user

  2. The HttpOnly flag. The name is misleading. It is not the opposite of the secure flag. It means the cookie should only be used by browser through http (and https) protocol only, but not used by other means such as JavaScript. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This is to prevent the XSS attack.

Lan
  • 6,470
  • 3
  • 26
  • 37
-2

Cookies are not secure. Forget protecting them.

  • You should protect your server by having all communication on HTTPS. HTTPS protects your cookies more than anything else (it cannot protect against Session Hijacking though).
  • Do not store any sensitive information in the cookie other than the session id.
  • Make sure your cookies are configured as HTTP ONLY. If not, the session id will be sent as a part of the query string and can be intercepted (and cached) by any one.
  • Regenerate your session id on major events like user login, password change, etc.
Pradeep
  • 2,469
  • 1
  • 18
  • 27
  • 1
    Cookies are sent in Cookie headers, never in a query string. Setting cookies to HTTP ONLY just tells the browser not to let JavaScript though them. – Quentin Mar 02 '13 at 00:12