3

How do I protect my users from session hijacking?

Daniel DiPaolo
  • 55,313
  • 14
  • 116
  • 115
Doug
  • 813
  • 1
  • 7
  • 7
  • Which platform/language? Are you referring to ASP.NET ? – rlb.usa Apr 15 '10 at 19:54
  • possible duplicate of http://stackoverflow.com/questions/22880/what-is-the-best-way-to-prevent-session-hijacking – Matthew Flaschen Apr 15 '10 at 19:55
  • 1
    @Matthew Flaschen that is a terrible answer. – rook Apr 15 '10 at 19:59
  • Note that 1. That posting is auto-generated (http://meta.stackexchange.com/questions/44173/autocomment-when-voting-to-close-as-duplicate/45331#45331), 2. It's a comment not an answer, and 3. The question is very similar to the previous one. – Matthew Flaschen Apr 15 '10 at 23:00

4 Answers4

3

There are three sections in the Owasp Top 10 for 2010 that you should read.

1: (!!) A3: "Broken Authentication and Session Management." (!!)

2: "Cross Site Request Forgery" (XSRF)

3: "Cross Site Scripting" (XSS)

rook
  • 66,304
  • 38
  • 162
  • 239
1

From StackOverflow's creators blog
Preventing CSRF and XSRF Attacks

Found by Googling "Prevent csrf"
http://www.google.com/search?client=safari&rls=en&q=prevent+csrf&ie=UTF-8&oe=UTF-8

Christopher Altman
  • 4,868
  • 2
  • 33
  • 49
  • Session riding is one of many attacks that can compromise a session. – rook Apr 15 '10 at 19:59
  • Good point, when I read this question my mind went immediately to cross site request forgery, but you are right, there are man in the middle and other attacks. – Christopher Altman Apr 15 '10 at 20:00
1

One way that I know of is to check for consistency in the IP address of the user. By this I mean checking that the current IP address match the IP address last used during the same session. This would, however, not stop session hijacking from someone using the same IP address.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
RadiantHeart
  • 266
  • 1
  • 4
  • 10
0

Consider the use of a secret salt known only to the client and server that is established at logon (hopefully an SSL logon). Afterwards the server can provide a count with each response and the client can provide a hash of (count + secret salt) with the next request. A potential hijacker has no access to the secret salt and cannot generate the next hash. Even a non-SSL login can probably establish a secret salt if login is accomplished using one-time-use hashed passwords.

davej
  • 165
  • 1
  • 6