Security practices for internal web application

I am a developer working on an internal web-based application, and I have been given responsibility to make sure the system is secure. I have no experience in this area, but I still want to do the best job开发者_如何学C I can: I'm in the middle of reading OWASP's guide (http://surfnet.dl.sourceforge.net/project/owasp/Guide/2.0.1/OWASPGuide2.0.1.pdf), but there is a lot of information to process, and unfortunately deadlines are deadlines.

Can the knowledgeable users here at Stack Overflow please poke holes in my design and show me where my understanding is lacking? If the entire idea is fundamentally flawed, knowing that would be appreciated, too. Thanks for any input.

This application is hosted internally, and should not be visible at all externally, even though it is accessed over our wireless networks. I trust our network engineers to handle this, though.

The users of this application are only a subset of all the employees in this corporate environment. In addition, even authorized users should be limited to only the information pertaining to them (which is largely an application-level concern, but I want to make sure exploits are not possible).

Security Framework for Internal Web Application (by a newbie)

All communication with the web server is done over HTTPS connections.

Logging in

1. User enters name and password, which are POSTed over an HTTPS connection
2. If the name and password are correct, generate a token, and store it in a cookie. Also store the cookie in the database for future lookup. The token should have an expiration date and is associated with only the user that generated it.

Requests

1. Check that the token supplied is still valid (not expired)
2. Check that the token is valid for the user making the request
3. If everything checks out, refresh the token's validity for another 30 minutes (or so)
4. Otherwise, deny access

---

That sounds good.
The token can either be a signed expiration date (signed with a private key stored on the server) or a sequence of cryptographically secure random bytes which is stored in a database.

Unless the token is specific to an IP address, everything must be done over SSL.

---

Independently of authentication, you'll also need to look out for SQL injection, CSRF, XSS, and other security holes.

---

Important consideration: The entire session has to be over SSL. Firesheep has demonstrated quite clearly that being able to sniff cookies (by being on the same network as the victim) leaves your users open to session hijacking.

Security is more than just logging in. You'll want to read up on SQL Injection and Cross-Site Scripting Attacks, on the very least (the two most common attacks against web-applications).

---

Look into CSRF attacks. They bypass cookie checks and company firewalls.