I'm implementing login-logout process using servlet. I've written code for logout and login and it is working fine but when I copy the URL from address bar of any restricted page and paste it after logout processing ,- still it shows all results with full access. I want to prevent users go back anyhow on that page after logout process. But I fail every time.
I show you my code ... and plwase guys help me... correct my mistakes....
Login Servlet code
Logout Servlet code
I'm setting headers also to prevent browser caching.... but still going on that page after logout....
I think I'm committing some mistake in setting headers or testing session availability...... Please correct me....
If you are writing your own login code, my experience is that you are not going to have a very secure web application. J2EE has its own login system, which has been around for many years and has never (to my knowledge) been cracked.
Also, if you simply MUST write your own login code, there are more secure ways to test for valid credentials. Reading the password from the database and checking it in user code is not secure. Especially since you're not even encrypting the password in the database, so you have twice as many targets for Bad Guys.
Try this, instead:
This keeps the password from being pulled into the JVM where it might be visible. Ideally, you'd have the password in a character array, instead of a String, since you can blank out a character array after use, but Strings remain until garbage-collected.
An IDE is no substitute for an Intelligent Developer.
You don't seem to be testing for the presence or absence of the "user" attribute in the session. As a result, you can have a session which doesn't have a "user" attribute (because the user logged out) but you don't treat that as a logged-out user.
By the way if you're going to do this, it's better to use a filter to check whether the user is logged in or not. Putting the same logic in every servlet is a bad idea, that's why filters were invented.
You also need to process the password through a salted one-way hash, such as SHA1, and never store the cleartext password anywhere. In registration, you hash the entered passphrase, and store that in the database. When you do the login, you accept the user's input and hash it, then compared the resulting hash with the value in the database. This is the minimum you can do.
You really should have a site-specific salt/nonce and a per-user specific salt/nonce. I could go on, but don't want to get too far OT
Joined: Aug 08, 2012
Please help me correcting the problem in my way(using session).. how can we utilize session attributes or session object for secure login and logout process.
And if any user try to copy paste URL or try to click back button after logout.... he should,nt reach there....
Please try to help me in this way....
How to prevent browser caching and where exactly shoyld we right code for that in servlet...?
How should we invalidate session or destroy the session removing all atrributes and how can we null the session reference..??
J2EE defines a standard security system that is built into every J2EE webserver. That includes the "incomplete" ones such as Tomcat. If you use it, it will automatically take care of the login process and all you have to do is define 2 forms and some settings in web.xml. No java coding at all. To log out of this security system, the webapp merely has to obtain the HttpSession object and invoke its invalidate() method. That will remove the session ID from the server's session cache. Since the only part of the session that the client can directly touch is the session ID, pressing the "back" button on the browser for an uncached page would result in the submission of a session ID that no longer had a session attached to it, which would cause the builtin security system to present a login screen automatically.
Cache control for clients is done by including cache control headers in server responses. These headers are only suggestions to the client, but most client use those suggestions intelligently. Also, in the case of the Tomcat webapp server (and probably many others), the server will automatically insert a no-cache header in the response when the user is logged in in order to ensure that sensitive information isn't stored in the client's cache.