Slide 1
Web Application Security
©SoftMoore Consulting
Web Application Security
Two major aspects of web application security
1. Preventing unauthorized users from accessing sensitive data– involves identification of which resources need protection and
who should have access to them
2. Preventing attackers from stealing network data while it is in transit– involves the use of Secure Sockets Layer (SSL) or Transport
Layer Security (TLS) to encrypt all network traffic between the client and the server (HTTPS)
©SoftMoore Consulting Slide 2
These two aspects of security are largely independent.
Approaches to WebApplication Security
• Declarative security– None of the individual web resources (servlets, JSP pages,
HTML pages, etc.) need any security-aware code.– Major security aspects are handled by the server.– Security requirements are specified in web.xml.
• Programmatic security– The web application manages at least some aspects of security.– To prevent unauthorized access, either a filter or else each web
resource must either authenticate the user or verify that the user has been authenticated.
– To safeguard network data, either a filter or else each web resource must check the network protocol and manually redirect to HTTPS if necessary.
©SoftMoore Consulting Slide 3
Authentication versus Authorization
• Authentication – the mechanism whereby systems may securely identify their users.– Who is the user?– Is the user really who he/she represents himself to be? – Authentication is usually achieved by requiring the user to login
with a user ID and password
• Authorization – the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system.– Does this user have access to this web resource?– Authorization is usually specified in terms of roles.
©SoftMoore Consulting Slide 4
Web Application Security Terms
• A role is an abstract name for the permission to access a particular set of resources in an application.
• A user is an individual (or application program) that has been defined in the web or application server.
• A principal (a.k.a. security principal) is essentially the same as a user.
• A realm is a “database” of users and roles.– can be stored in a file, in a relational database system, or other
similar mechanism
©SoftMoore Consulting Slide 5
General Concepts
• Users are assigned roles. It is possible for a user to have more than one role.
• A realm maintains the list of users, user passwords, and roles. When a user is authenticated (e.g., when the user logs in), the list of roles associated with that user is determined by querying the realm.
• Web resources (HTML pages, JSP pages, servlets, etc.) are protected by roles. If a user has the required role, then the user is allowed access to the web resource. Otherwise, access is denied.
©SoftMoore Consulting Slide 6
BASIC versus Form-Based Authentication
• When a user who has not been authenticated tries to access a protected resource– with BASIC authentication:
• server sends a 401 status code to the browser• browser pops up a dialog box asking for user name and password• user name and password are sent in authorization request header
– with form-based authentication:• server redirects user to a web page with an HTML form for entering
username and password
• In both cases, the username and password are checked against the realm database. If the user has the required role, access is granted.
©SoftMoore Consulting Slide 7
Example Login UsingBASIC Authentication
©SoftMoore Consulting Slide 8
Dialog box from Internet Explorer
Example Login UsingBASIC Authentication
©SoftMoore Consulting Slide 9
Dialog box from Firefox
Example Login UsingForm-Based Authentication
©SoftMoore Consulting Slide 10
Form-Based Authentication
1. Set up usernames, passwords, and roles.– server-specific process– for Tomcat can use file conf/tomcat-users.xml for testing
<?xml version="1.0" encoding="ISO-8859-1"?><tomcat-users> <user username="john" password= "moore" roles="admin,registered-user" /> <user username="jane" password="doe" roles="registered-user" /></tomcat-users>
©SoftMoore Consulting Slide 11
Form-Based Authentication(continued)
1. Set up usernames, passwords, and roles. (continued)– can use two database tables realm_user and user_role
create table realm_user ( user_id varchar(30) not null, password varchar(40) not null, constraint realm_user_pk primary key (user_id) );
create table user_role ( user_id varchar(30) not null, role varchar(15) not null, constraint user_fk foreign key (user_id) references realm_user(user_id) on delete cascade );
©SoftMoore Consulting Slide 12
Form-Based Authentication(continued)
2. Define the realm in webapp\META-INF\context.xml<Context> <Realm className="org.apache.catalina.realm.JDBCRealm" driverName="org.apache.derby.jdbc.ClientDriver" connectionURL="jdbc:derby://localhost:1527/C:\\DbName" connectionName="jmoore" connectionPassword="password" userTable="realm_user" userNameCol="user_id" userCredCol="password" userRoleTable="user_role" roleNameCol="role" digest="sha" /></Context>©SoftMoore Consulting Slide 13
Form-Based Authentication(continued)
3. Tell server that you are using form-based authentication (in web.xml).<web-app> ... <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/login-error.html</form-error-page> </form-login-config> </login-config> ...</web-app>
©SoftMoore Consulting Slide 14
Form-Based Authentication(continued)
4. Create a login page (HTML or JSP).<form method="post" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> ...</form>
5. Create an error page for failed login attempts.– no specific content mandated– Sample: “username and password not found” and a link back to
the login page– can be either an HTML or JSP
©SoftMoore Consulting Slide 15
Form-Based Authentication(continued)
6. Specify URLs to be password protected.<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>Sensitive</web-resource-name> <url-pattern>/sensitive/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> <role-name>executive</role-name> </auth-constraint> </security-constraint> ...</web-app>
©SoftMoore Consulting Slide 16
Multiple web-resource-collection entries are permitted.
Form-Based Authentication(continued)
7. List all possible roles that are granted access to any resource. (Required only with servlets 2.4 but not enforced by most servers)<web-app> ... <security-role> <role-name>admin</role-name> <role-name>executive</role-name> </security-role></web-app>
©SoftMoore Consulting Slide 17
BASIC Authentication
• Similar to form-based authentication except– the <auth-method> is BASIC rather than FORM– no need to write or specify the login and error pages
• Uses a browser-specific dialog to collect the user name and password (not a consistent look-and-feel)
• No easy way to “logout” short of closing the browser(With form-based authentication, the web application can invalidate the session when the user logs out.)
©SoftMoore Consulting Slide 18
In practice, most web sites created for externalcustomers use form-based authentication, butmany intranet applications use BASIC.
Problems with Declarative Security
• Server-specific– not completely portable
• Access is all or nothing– can’t customize the result based on the user’s roles
• Access is based on exact password match– can’t easily customize how user is authenticated
©SoftMoore Consulting Slide 19
Programmatic Security
• The web application manages at least some aspects of the security.
• Hybrid approaches are common, where the sever manages some aspects of security and the web application manages other aspects.
• Examples of hybrid approaches– The server could still authenticate users, but the web application
could customize the response based on user roles.– The server could still maintain control over which resources
require TLS/SSL/HTTPS.
©SoftMoore Consulting Slide 20
Declarative security is, by far, the most commonapproach to web application security.
Methods in HttpServletRequest
• boolean isUserInRole(String role)Returns a boolean indicating whether the authenticated user is included in the specified logical “role”.
• String getRemoteUser()Returns the login of the user making this request, if the user has been authenticated, or null if the user has not been authenticated.
• Principal getUserPrincipal()Returns a java.security.Principal object containing the name of the current authenticated user. (The Principal object contains little information beyond the username – primary use is for compatibility with preexisting code not related to servlets or JSP. Most web applications can use getRemoteUser().)
©SoftMoore Consulting Slide 21
Using Filters for Programmatic Security
• Filters can be used to manage web application security• Using filters decouples servlets and JSP pages from the
code to manage security, thereby providing some of the benefits of declarative security.
• Using a hybrid approach, the web application could use declarative security for authentication and programmatic security to manage access control.
©SoftMoore Consulting Slide 22
Example: Restricting User Access
public class AccessFilter implements Filter { private static final String HOME_PAGE = "/index.jsp"; private static final String ADMIN_PAGE = "/admin/index.jsp"; private static final String USER_PAGE = "/user/index.jsp"; ...
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest)request; HttpServletResponse res = (HttpServletResponse)response; String page = HOME_PAGE; // default if user has not // logged in String user = req.getRemoteUser();
©SoftMoore Consulting Slide 23
Example: Restricting User Access(continued)
if (user != null) { if (userInRole("admin") page = ADMIN_PAGE; else page = USER_PAGE; }
RequestDispatcher dispatcher = req.getRequestDispatcher(page); dispatcher.forward(request, response); } }
©SoftMoore Consulting Slide 24
Modifying web.xml for the Access Filter
<filter> <filter-name>AccessFilter</filter-name> <filter-class> com.softmoore.security.AccessFilter </filter-class> </filter>
<filter-mapping> <filter-name>AccessFilter</filter-name> <url-pattern>/admin/*</url-pattern></filter-mapping>
©SoftMoore Consulting Slide 25
Introduction to TLS and SSL
• Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are the two primary protocols used by the Internet for secure communication.– TLS is successor to SSL– terms TLS and SSL are often used interchangeably
• All data sent between the browser and server are encrypted.– URL starts with “https”.– browser usually displays a lock in the lower right corner– based on public-key cryptography and digital certificates
©SoftMoore Consulting Slide 26
Digital Certificates
• When a browser makes an initial attempt to communicate with a server over a secure connection, the server authenticates itself by providing a digital certificate.
• Certificates can be signed by a recognized Certification Authority (CA), or it can be self-signed (e.g., for internal use within an organization).
• Common Certification Authorities– VeriSign (subsidiaries Thawte and Geotrust)– GoDaddy– Comodo
©SoftMoore Consulting Slide 27
Example of a Digital Certificate
©SoftMoore Consulting Slide 28
Specifying Which URLs Require TLS/SSL
Within the deployment descriptor:<web-app> ... <security-constraint> ... <user-data-constraint> <transport-guarantee> CONFIDENTIAL </transport-guarantee> </user-data-constraint> </security-constraint> ...</web-app>
©SoftMoore Consulting Slide 29
Additional Requirements for Using TLS/SSL
• There must be valid keystore and certificate files.– For testing and intranet sites you can create a self-signed
certificate using keytool (provided with JDK)– For “real” internet sites, the certificate must be signed by a
Certificate Authority (CA) such as Thawte or VeriSign.
• There must be a Connector element for a TLS/SSL connector in the server deployment descriptor (file server.xml for Tomcat).– By default, Tomcat uses port 8080 for HTTP and 8443 for
HTTPS.– The “real” internet uses port 80 for HTTP and 443 for HTTPS.– The location of the keystore file and its password must be
specified in the server deployment descriptor.
©SoftMoore Consulting Slide 30
Example: Connector Elementin server.xml for Tomcat
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="443" enableLookups="true" disableUploadTimeout="true" acceptCount="100" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile=".keystore" keystorePass="password" clientAuth="false" sslProtocol="TLS"/>
©SoftMoore Consulting Slide 31
See “SSL/TLS Configuration HOW-TO” in theTomcat documentation for additional details.