0

Assume I have a single servlet in a web app, and all users need to be logged in before they can do anything. So in the get and post methods there is an if block to test if the user is logged by trying to extract a session attribute in to process request, and else to redirect to login page if not logged in.

Given this scenario, is there a way an intruder can manipulate the system to gain entry without knowing the password? Assume the password is hard-coded into the servlet. If yes, where would he start?

qualebs
  • 1,291
  • 2
  • 17
  • 34
  • What about session-hijack attacks? – Dai Mar 30 '13 at 23:11
  • You could authenticate in a servlet filter every time for every request. It'd be inefficient, but no session hijack possible. I think any system can be manipulated. I don't think a blanket guarantee can be given. – duffymo Mar 30 '13 at 23:13
  • 2
    You need a secure connection or you are open to man in the middle attacks – Hogan Mar 30 '13 at 23:13

2 Answers2

2

I would look at http://docs.oracle.com/javaee/5/tutorial/doc/bncbe.html#bncbj and the section linked from that section about specifying authentication mechanisms.

See also (on Stackoverflow) Looking for a simple, secure session design with servlets and JSP and How do servlets work? Instantiation, sessions, shared variables and multithreading

In short, you don't need to do much yourself about checking for a session attribute if you use the mechanisms described on those pages. Your login form can be used in the 'form-login' configuration requiring authentication.

Community
  • 1
  • 1
JohnK
  • 406
  • 4
  • 6
0

The key of security is around your comment extract a session attribute -- how are you doing this? Are they sending you a query string param? Are they sending you credentials in the method headers?

To @Hogan's point, unless this is over HTTPS the answer is: "No, it is not secure. A man-in-the-middle (MITM) can get the password from your submission and simply re-use it to mask its own nefarious requests".

If the communication IS done over HTTPS, then you should be fine. Having a single hard-coded password is fine, but consider the case where the password gets compromised; now every single client/user/etc. has to change their code.

A better design is to issue clients a key they can send along with their requests that you can use to identify who they are and if a key gets compromise, re-issue a new one to that user/client/etc.

This assumes traffic is over HTTPS

If traffic is not, a lot of this breaks down and you need to look at things like HMAC's. I wrote this article on designing secure APIs -- it should give you a good introduction to how all this nightmare of security works.

If your eyes are rolling into the back of your head and you are thinking "My god, I just wanted a YES/NO", then my recommendation is:

  1. Require all traffic to be over HTTPS
  2. Issue individual passwords to each client so if one gets compromised, every single one isn't compromised.
  3. That should get you pretty far down the road.

Hope that help. This topic is super hairy and I know you didn't want a history lesson and just want to solve this question and move forward. Hope I gave you enough to do that.

Riyad Kalla
  • 10,604
  • 7
  • 53
  • 56
  • can the man in the middle get access by attacking the server directly without intercepting data from clients? what I was hoping to get from this question is to understand what is hackable. I mean can I state with absolute certainty that if the intruder got no intercepted passwords from clients there is no way he can crack the system – qualebs Mar 30 '13 at 23:35
  • 1
    @qualebs with the caveat that nothing is hack-proof, yes, as long as your logic is solid in the servlet (or filter, depending on how you want to impl it) -- if the MITM can NEVER send the right password, the logic in your servlet will block the logic from continuing through to processing the request without the right password. In that sense though, MOST systems are "secure" -- the problem is leaking credentials. Just don't want to give you a false sense of security, you still have to be diligent with security. – Riyad Kalla Mar 31 '13 at 15:46