Slide 1 Web Application Security ©SoftMoore Consulting.

31
Slide 1 Web Application Security ©SoftMoore Consulting

description

Approaches to Web Application 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 ConsultingSlide 3

Transcript of Slide 1 Web Application Security ©SoftMoore Consulting.

Page 1: Slide 1 Web Application Security ©SoftMoore Consulting.

Slide 1

Web Application Security

©SoftMoore Consulting

Page 2: 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.

Page 3: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 4: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 5: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 6: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 7: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 8: Slide 1 Web Application Security ©SoftMoore Consulting.

Example Login UsingBASIC Authentication

©SoftMoore Consulting Slide 8

Dialog box from Internet Explorer

Page 9: Slide 1 Web Application Security ©SoftMoore Consulting.

Example Login UsingBASIC Authentication

©SoftMoore Consulting Slide 9

Dialog box from Firefox

Page 10: Slide 1 Web Application Security ©SoftMoore Consulting.

Example Login UsingForm-Based Authentication

©SoftMoore Consulting Slide 10

Page 11: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 12: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 13: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 14: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 15: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 16: Slide 1 Web Application Security ©SoftMoore Consulting.

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.

Page 17: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 18: Slide 1 Web Application Security ©SoftMoore Consulting.

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.

Page 19: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 20: Slide 1 Web Application Security ©SoftMoore Consulting.

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.

Page 21: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 22: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 23: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 24: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 25: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 26: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 27: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 28: Slide 1 Web Application Security ©SoftMoore Consulting.

Example of a Digital Certificate

©SoftMoore Consulting Slide 28

Page 29: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 30: Slide 1 Web Application Security ©SoftMoore Consulting.

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

Page 31: Slide 1 Web Application Security ©SoftMoore Consulting.

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.