Web Security: Worst-Case Situation

Question

I currently have built a system that checks user IP, browser, and a random-string cookie to determine if he is an admin.

In the worst case, someone steals my cookie, uses the same browser I do, and masks his IP to appear as mine. Is there another layer of security I should add onto my script to make it more secure?

EDIT: To clarify: my website accepts absolutely NO input from users. I'm just designing a back-end admin panel to make it easier to update database entries.

Answer 1

The proper way to secure admin access is using HTTPS.

There are two attacks against HTTPS:

1. Trojan on your machine
2. Man-in-the-middle uses legitimate yet malicious certificates

Clearly (1) is the most likely. But on the other hand, your Trojan is likely to be out after your bank details and such, and the attacker is not going to sieve through all your stuff to discover and explore your admin relationship with a website.

Clearly if the attacker is sophisticated as to go for (2) you are not in much of a position to prevail.

That's as small an attack surface as you can get.

Answer 2

Https is a must, but you also have to come to terms with the fact that no site can be 100% secure. The only other way for you to get a significant improvement in security is to have very short session timeouts and provide you users with hardware tokens, but even tokens can be stolen.

Answer 3

Checking the browser is a complete and absolute waste of code. There is no point in writing a secuirty system that is trivial for an attacker to bypass. If the attacker obtains the session id via xss or sniffing the line then they will also have your "user-agent".

Checking the ip address will force the attacker to "ride" on the session with XSS+XHR or XSRF. This is because the hijacked token will not work on his box. Unfortunately this also causes problems for corporate networks which use outgoing load balancing between multiple ip addresses.

HTTPS is a must be used for the entire session. At no point can your token be sent over HTTP. This is clearly layed out in "Broken Authentication and Session Management" in The OWASP Top 10 for 2010, which you absolutely must read if you are writing a session handler.

Session id's must always time out. If they do not then this is called an immortal session, which is a recognized vulnerability.

Further more i am concerned about the randomness of your token. Make sure your study how to properly generate a cryptographic nonce. Make sure your random number generator is strong and seeded with information that an attacker cannot know.

I also suspect that you haven't taken XSS and XSRF into consideration. It doesn't matter how strong you make your session in other areas if you leave a major vulnerability unchecked. Make sure you scan your application using a free xss scanner or the open source wapiti. Keep in mind that no test will accurately detect XSRF and every single request in your application is vulnerable unless you specifically patch it.

Answer 4

THe one thing I miss besides everything that is mentioned is fixing "all other security problems".

• If you have a SQL injection, you're effort on the cookies is a waste of time.
• If you have a XSRF vuln, you're effort on the cookies is a waste of time.
• If you have XSS, ....
• If you have HPP, ...
• If you have ...., ....

You get the point.

If you really want to cover everything, I suggest you get the vulnerability landscape clear and build an attack tree (Bruce Schneier).