Most web applications use login pages as a way to secure the application and authenticate application users. A login page specifies the login URL in a web application that users must pass through to get to the authenticated URLs at the heart of the application.
Authenticated URLs are URLs that become accessible to users only after they successfully log in to the login URL. A logout URL is a URL that, if accessed, forces users to return to the login URL before re-accessing authenticated URLs. System administrators use these special URLs to prevent forceful browsing by causing users to pass through the login URL before viewing the restricted authenticated URLs. In addition to specifying the login URL, login pages in the security policy can also enforce access validation by defining access permissions for users.
In Application Security Manager™ (ASM), security policies use login pages for several features:
Login enforcement specifies the authenticated URLs and logout URLs for the application. Session awareness provides tracking information of user sessions so that you can investigate suspicious activity and the attacker. Brute force protection prevents hackers from staging multiple attempts to guess user names and passwords so that they can log on to the application. Database security integration can use login pages to provide event notification and user data to a third-party database monitoring system.
Your web application might contain URLs that should be accessed only through other URLs. For example, in an online banking application, account holders should be able to access their account information only by logging on through a login screen first. You can create login pages manually, or have the system create them automatically.
Application Security Manager™ (ASM) adds login pages for you automatically if you use certain options. The options are Detect Login Pages and Learn from Responses in the Learning and Blocking Settings. If you create the security policy automatically using the Enhanced or Comprehensive policy types, the system sets these options by default. If you are using other policy types (Fundamental or Custom), you can explicitly set these options. These options cause ASM to detect login pages in the web application and add them to the security policy when sufficient legitimate traffic has accessed the application.
You can also create login or logout pages manually by specifying the login or logout URLs used by the application. The same URL can be used as both a login URL and a logout URL.
If the Learning Mode is Manual, the login page is added to the learning suggestions on the Traffic Learning screen where you can add it to the policy. The login pages in the security policy are included in the Login Pages List.
|?||Any single character.|
|[abcde]||Exactly one of the characters listed.|
|[!abcde]||Any character not listed.|
|[a-e]||Exactly one character in the range.|
|[!a-e}||Any character not in the range.|
|None||The web server does not authenticate users trying to access the web application through the login URL. This is the default setting.|
|HTML Form||The web application uses a form to collect and authenticate user credentials. If using this option, you also need to type the user name and password parameters written in the code of the HTML form.|
|HTTP Basic Authentication||The user name and password are transmitted in Base64 and stored on the server in plain text.|
|HTTP Digest Authentication||The web server performs the authentication; user names and passwords are not transmitted over the network, nor are they stored in plain text.|
|NTLM||Microsoft LAN Manager authentication (also called Integrated Windows Authentication) does not transmit credentials in plain text, but requires a continuous TCP connection between the server and client.|
|JSON/AJAX Request||The web server uses JSON and AJAX requests to authenticate users trying to access the web application through the login URL. For this option, you also need to type the name of the JSON element containing the user name and password.|
Following are descriptions of the access validation criteria for the response to the login URL. You configure one or more of these validations when defining a login page manually. A login attempt is only successful if all of the specified validation criteria are satisfied.
|Access validation||Define in login page as|
|A string that should appear in the response||A string that must appear in the response for the system to allow the user to access the authenticated URL; for example, Successful Login.|
|A string that should NOT appear in the response||A string that indicates a failed login attempt and prohibits user access to the authenticated URL; for example, Authentication failed.|
|Expected HTTP response status code||An HTTP response code that the server must return to the user to allow access to the authenticated URL; for example, 200.|
|Expected validation header name and value (for example, Location header)||A header name and value that the response to the login URL must match to permit user access to the authenticated URL.|
|Expected validation domain cookie name||A defined domain cookie name that the response to the login URL must match to permit user access to the authenticated URL.|
|Expected parameter name (added to URI links in the response)||A parameter that must exist in the login URL’s HTML body to allow access to the authenticated URL.|
Login enforcement indicates how the security policy implements login pages including an optional expiration time, a list of URLs that require authentication to get to, and a list of URLs used to log out of the application. You can also use authenticated URLs to enforce idle time-outs on applications that are missing this functionality.