Build Secure Login Page

[b]Don't allow the login page to be framed[/b]
Allowing the login page to be displayed within a frame can open the application up to a cross frame scripting vulnerability in some browsers. The EComm Core provides functionality to prevent framing in traditional template-based, JSP-based, and JavaServer Faces applications.

[b]Don't disclose information through the help page[/b]
If the login page links to a help system, the information available should only cover the login page and other pages that are accessible before the user logs into the application. It's a common mistake to expose additional information through the help system. This may assist potential attackers who wish to learn about the how the application works and what functionality is available.

Offset the User Id and Password fields from the center of the page
A common phishing technique is to insert code into a session that results in an HTTP Basic Authentication box displaying in the center of the screen. If the User Id and Password entry fields are centered on the page, they can be hidden by the dialog and the user may enter their credentials into the wrong input fields.

[b]Don't prefill user id and password data[/b]
A login page should never prefill the user id and password fields with previously entered data. For example, if the user enters an incorrect password, when the page is redisplayed, both fields should be empty. To prevent the browser from prefilling the fields, both input elements should have the autocomplete='off' attribute set.

[b]Don't use unique error codes or messages for User Id or Password errors.[/b]
Using unique error codes or messages for User Id or Password errors can lead to inadvertent information disclosure. This could allow an attacker to identify valid User Ids and potentially guess a common password or launch a denial-of-service attack.

[b]Establish a new session after authentication[/b]
For simple applications, the best approach is to code the login page so it doesn't establish a session. However, many more complex applications require a session before the user is authenticated to implement functions such as new user enrollment or password changes and resets. If a session is established before authentication, it should be deleted and a new session established after the user authenticates to avoid a session fixation attack.

[b]Redirect the user after authentication[/b]
After the user has been authenticated, the next page the application displays should not be the application's landing page, but instead should be a page that uses a meta refresh tag to redirect the user to the landing page using the newly established session identifier.

This prevents a security issue where the user can logout then use the browser's Back button to back up to the landing page and click Refresh which causes the login credentials to be resubmitted by the browser and a new session established.

If the user attempts this with an application that has a redirect between the login and landing pages, the information the browser resubmits is the session identifier (which is now invalid), not the login credentials.

[b]Use cookies correctly[/b]
Session cookies should be marked secure and HTTPOnly.