• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

How to create a secure login system?

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

As an assignment (school), I need to create a web application using jsp. Some features are mandatory, such as a login system and use of a database.
And so I started looking around for a place to get started. Someone recommended I use JSF so I read the first few chapters of Core JavaServer Faces (Geary, Horstman) 2nd ed.

So now I have a form with a name field, a loginController bean with getter and setter for 'name' and a validateLogin method that for now does nothing: if name is 'boe' return failure, otherwise return success. If failure is the outcome of the 'validator' (whaha it doesn't deserve the name validator :P) a page failure.jsp is displayed (telling the user that boe is not a name), otherwise the user is welcomed.

All very nice, but the application will have some pages that only logged in users may view. How to do this?

Okay, so I started reading and googling and all. All I can find is code snippets and snippets of partial explanation with a common subject: the HttpSession API. Some say "FacesContext fc = javax.faces.context.FacesContext.getCurrentInstance();" followed by "HttpSession session = (HttpSession) FacesContext.getCurrentInstance().getExternalContext().getSession(false);", some say you should not use the 'false' in getSession because it might return null, some say to use a backing bean like so: "httpSession.setAttribute("login", "Login");", some say to use "ExternalContext#getSessionMap();" (huh? '#'?) but none give a satisfactory explanation on what it all means.

Can anyone point me to a place to start making sense of all this? I have been googling for hours and hours and cannot find anything actually helpful.

Many thanks,
Nik
 
Nikki Massa
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, this is what I've got so far.

A login validating bean (note the questions between the code )


With this faces-config.xml


Entering a name in the name field and submitting the value correctly directs me to failure.jsp or secure/welcome.jsp.
I then started playing with making sure a page can only be accessed when the user is logged in.
A link (using commandLink) links to one such page, lets call it 'data.jsp'. When the user clicks this commandLink, this code snippet from the DataBean decides if the user will end up at data.jsp or at the login page index.jsp:

This works fine: the user enters the incorrect name, ends up at failure.jsp, clicks the commandLink and ends up at index.jsp. The user enters the correct name, ends up at secure/welcome.jsp, clicks the commandLink and ends up at data.jsp.
But...
The user logs out by clicking the logout commandButton, which calls code:

faces-config then sends the user to index.jsp.

After logout, you can still enter /sevure/data.jsp in the browser URL field and access this page.
I think this is because validation is performed after clicking a link. If validation checks out, the user is sent to the next page.
So when you access the page by typing its URL, no validation is performed and anyone can access this page.

So much for this attempt. I would greatly appreciate any comments or tips or suggested reading or whatever.

Nik
 
Saloon Keeper
Posts: 28486
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oooh, that's just BEGGING for trouble, Evidently you haven't heard me rant on this subject.

I've worked with J2EE since before JSPs were even invented, and without exception EVERY login system I've seen people create has been insecure. Most of them were massively insecure.

Security is very hard. It's a classic "weakest link" situation. One false move and the whole thing is useless. I know a lot of people who think they're clever. They've put a lot of effort into creating clever security systems, some of them for very sensitive applications. And by and large, every last stinking one of their clever systems could be bypassed in under 15 minutes. Usually, in fact, in a single URL request.

The J2EE standard DEFINES a secure login system. Or, to be more accurate, a secure Authentication and Authorization system. Secure login doesn't actually mean much if any logged in user can do anything they want. This is a system that was designed, vetted, and tested by security professionals. It has worked without significant changes for over a decade now. It works primarily by taking patterns from the webapp's web.xml file and matching incoming URLs against them. If a URL matches, the container applies security to the request, and if certain minimum requirements aren't met, the URL is bounced before the application can even see it. You can't attack what you can't reach.

So, in short, my advice on how to create a secure login system is: don't. Use the one that's already there. It's been validated, debugged, and best of all, it's mostly transparent, so there's relatively little you have to do to a webapp in order to take advantage of it.
 
Nikki Massa
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your reply Tim.

Tim Holloway wrote:Oooh, that's just BEGGING for trouble, Evidently you haven't heard me rant on this subject.


er, no?

Tim Holloway wrote:
I've worked with J2EE since before JSPs were even invented, and without exception EVERY login system I've seen people create has been insecure. Most of them were massively insecure.

Security is very hard. It's a classic "weakest link" situation. One false move and the whole thing is useless. I know a lot of people who think they're clever. They've put a lot of effort into creating clever security systems, some of them for very sensitive applications. And by and large, every last stinking one of their clever systems could be bypassed in under 15 minutes. Usually, in fact, in a single URL request.


Yesterday I learnt that this is indeed very, very simple. URL injection. Username/password attacks. That kind of stuff. And even though this particular site I'm building is a school project, in the future I might be handling truly sensitive information and security becomes a very important issue. So rant on!

Tim Holloway wrote:The J2EE standard DEFINES a secure login system. Or, to be more accurate, a secure Authentication and Authorization system. Secure login doesn't actually mean much if any logged in user can do anything they want.


I've heard examples of people being able to access details on other accounts, just because they were logged in on the system. This particular website migt as well have used one username and password for all its customers...

Tim Holloway wrote:This is a system that was designed, vetted, and tested by security professionals. It has worked without significant changes for over a decade now. It works primarily by taking patterns from the webapp's web.xml file and matching incoming URLs against them. If a URL matches, the container applies security to the request, and if certain minimum requirements aren't met, the URL is bounced before the application can even see it. You can't attack what you can't reach.

So, in short, my advice on how to create a secure login system is: don't. Use the one that's already there. It's been validated, debugged, and best of all, it's mostly transparent, so there's relatively little you have to do to a webapp in order to take advantage of it.



So, I'll be looking into this then.

Thanks for the rant!
Chrz, Nik

***edit
How'bout this:
http://onjava.com/pub/a/onjava/2002/06/12/form.html
 
Hot dog! An advertiser loves us THIS much:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic