This document outlines the security issues related to web applications, covering topics such as authentication, authorization, data integrity, and overall security measures against malicious code and website attacks. It discusses various authentication methods, including basic, digest, form, and client-cert authentication, as well as various ways to implement security through declarative and programmatic means. Key concepts like auditing and defining roles associated with access control are emphasized to ensure protection and proper management of user permissions.

1. 1
Secure Web Applications
Helmi ben abdallah @rchitect JEE

2. 2
OBJECTIVES COVERED IN THIS CHAPTER:
6.1 Identify correct descriptions or statements about the security issues:
• Authentication
• authorization
• Data integrity
• Auditing
• Malicious code
• Website attacks
6.2 Identify the deployment descriptor element names, and their structure, that declare the
following:
• A security constraint
• A web resource
• The login configuration
• A security role
6.3 Given authentication type: BASIC, DIGEST, FORM, and CLIENT-CERT, identify the correct
definition of its mechanism.

3. 3
Security Issues
• securing your web application should be a priority to
ensure the integrity of your data and application. This
process begins by implementing the four basic security
principles:
• Authorize ,Authenticate ,Provide data confidentiality
,Monitor access.
• In addition to these principles, we will also discuss the
following security concerns:
> Malicious code
> Website attacks

4. 4
Authorization
provides a visual representation of these two approaches to security: the client-server
approach, in which the aim is to secure the client, and the J2EE approach, in which the aim is
to secure the server.

5. 5
• The onset of the Internet caused network security to become a
huge concern.
• When Java first hit the market, it was known as the Internet
language.
• It marketed applet development as the product that provided a
secure environment for clients accessing unknown sources over
the Internet.
• However,restricting applet access to the client system was not a
successful solution to security.
• Instead, other means of protection were needed to enable
authorized access without limiting functionality.
• The concern is no longer focused on the applet client, but rather
a J2EE client (servlet or JSP) attempting to access an enterprise
application.

6. 6
Authentication
• After the client identifies themselves, they must provide
evidence to prove they are truly who they claim.
• Authentication is the process whereby the client supplies
credentials to prove their identity. Most often proof is provided
via a password.
• Other examples include the swipe of a card, retinal scans,
fingerprints, or digital certificates located on the user’s system.

7. 7
Data Integrity
• Access control fails if others can gain access to password or authentication information
as it is transmitted over the network.
• Encrypting information protects data and provides another level of security.
• The protocol called Secure Sockets Layer (SSL) was developed to use public key
cryptography to encrypt communication between the client and server.
• Two main security concerns are solved when using public key cryptography:
> The first is confidentiality. Because the data is encrypted, you are
guaranteed privacy.
> The second is integrity. As long as the information can be decoded
properly by the intended recipient, you can be fairly sure that the data
was not tampered with during transmission.

8. 8
Auditing
• Auditing users is a way of ensuring that users who log in
successfully access only those resources that are
appropriate to their role.
• The servlet security model is role-based .
• This means that users are assigned to roles, such as
Manager, Employee, or Guest.
• Each role is assigned certain privileges, and access is
granted to roles rather than users.

9. 9
• To determine whether to provide a client with access to a
given resource, the server:
1. Discovers which roles are available
2.Checks to see which roles are allowed
3.Checks to see whether the user is assigned to any
available roles

10. 10
• Notice that security evolves around the role rather than the
user. By using a server-specific tool, users are mapped to
particular roles.
• The granularity of permissions can be defined at a finer level.
By using the tool or the deployment descriptor, you can specify
the method permissions for each role as well.
• Access for each role can be denoted in two ways: through
• declarative security
• or
• programmatic security.

11. 11
Declarative Security
• Declarative security uses the deployment descriptor to
specify which resource a role can access.
• The advantage of this approach is that implementing
security is independent of source code: when security
changes must be made, there is no need to recompile or
make changes to the code.

12. 12
• By including the security-constraint tag in your web.xml file
located in the /WEB-INF directory, you can define each resource
and the roles that have access.
• Here is an example of how to restrict a particular directory to
users that have the role of Administrator.

13. 13
<security-constraint>
<web-resource-collection>
<web-resource-name> Admin area </web-resource-name>
<url-pattern> /admin/* </url-pattern>
</web-resource-collection>
<auth-constraint> <role-name> Administrator </role-name> </auth-constraint>
</security-constraint>

14. 14
Programmatic Security
• There are three Java methods within the javax.servlet
.HttpServletRequest class that provide information about the
user making a request:
• String getRemoteUser() : returns a String of the username
used to log in to the website.
• boolean isUserInRole(String role) : indicates whether the
user accessing the servlet is assigned to the passed-in role.
• Principal getUserPrincipal() : returns a java.security
.Principal object representing the user who is logged in.

15. 15
Here is an example of how programmatic security can filter activity based on the
user:
public class AccessServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/plain");
PrintWriter out = res.getWriter();
String username = req.getRemoteUser();
if (username == null) { out.println("You are not logged in.");
} else if ("Mary".equals(username)) { out.println("Hello Mary, glad you can
join us");
} else {
out.println("Hello " + username);
}

16. 16
This example has Mary assigned to the role of GeneralUser. With this said,
the deployment descriptor would look like the following:
• <security-constraint>
> <web-resource-collection>
<web-resource-name>
AccessServlet
</web-resource-name>
• <url-pattern> /serlvet/AccessServlet </url-pattern>
> </web-resource-collection>
• <auth-constraint>
<role-name> GeneralUser </role-name>
</auth-constraint>
</security-constraint>
• As you can see, declarative and programmatic security can be used together. The downside of
defining security measures within code is that changes to security will result in the need to
recompile the code.

17. 17
Malicious Code
• In the technical world, the term malicious code is
synonymous for virus.
• Unfortunately, many people thrive on developing software
that locates system vulnerabilities and attacks.
• Sometimes the code is kind enough to simply overflow a
particular folder with messages of love, but other times
viruses have been known to wipe out entire hard drives.
• There are no flags or method calls that can protect your
system against these types of assaults.
• One solution is the use of antivirus software.

18. 18
Website Attacks
• When establishing a website, assume the site will be attacked.
Even if the information isn’t critical, hackers often use systems
for the sole purpose of hiding their trail.
• By bouncing from machine to machine, they can arrive at a
destination with a trail too difficult to trace.
• One form of protection is the utilization of a firewall.
• Another consideration to help against attacks is the installation
of intrusion detection tools.
• There are a number of tools you can use to detect attackers.
Packet sniffers, for example, enable you to view all the traffic
on your network.
• If any activity looks odd, you can use your firewall to block the
intruder.

19. 19
Authentication Types
• The web container provides four authentication techniques
to determine client validity:
1. BASIC authentication requires the client to provide a user login name and
password in order to access protected data.
2. FORM authentication adds a bit of elegance to logging in. It enables an
application to request authorization by using a customized HTML page.
3. DIGEST authentication provides a little bit more security in that it
encrypts the login name and password to prevent others from acquiring this
privileged information while it travels over the network.
4. CLIENT-CERT authentication stands for client certificate. This approach
requires the client to provide a digital certificate containing information about
the issuer, signature, serial number, key type, and more. Basically, it is a
complex object used to identify the client.

20. 20
BASIC
• The simplest form of authentication is known as HTTP Basic
authentication,or BASIC.
• As its name indicates, an application utilizing this form of
certification asks for basic information, such as the user’s
login name and password.
• The data is then transferred to the server by using BASE64
encoding for validation.
• The good news is that this process is easy to implement; the
bad news is that it doesn’t offer much security beyond
authenticating the client.

21. 21
public class PrivateServlet extends HttpServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/plain");
PrintWriter out = res.getWriter();
out.println("You are accessing
private information");
}
}

22. 22
• Within the security-constraint, there are two sub-elements:
> web-resource-collection
> auth-constraint
• The web-resource-collection element defines three important
features of the protected code:
> The web-resource-name is the name used by a tool to
reference the servlet. The name must be specified even if a
tool is not used.
> The url-pattern indicates the URL pattern to the source code
requiring protection. If alias names are used to reference
servlets, those too should be included.
> The http-method indicates all HTTP methods that should
have restricted access. If no HTTP method is specified, then
all methods are protected.
Remember: the methods defined within the http-method element apply to all
servlets defined by the url-pattern element.

23. 23
The auth-constraint element defines any
number of roles that canhave access to
the protected code.
• Tomcat uses the conf/tomcat-users.xml file to characterize each
group. The file might look similar to the following:
<tomcat-users>
<user name="Mandy" password="secret" roles="Broker" />
<user name="Tim21" password="secret“ roles="Administrator" />
<user name="Bob14" password="secret" roles="Broker, Employee" />
</tomcat-users>

24. 24
The login-config Element
<login-config>
<auth-method>
BASIC <!--BASIC, DIGEST, FORM, CLIENT-CERT -->
</auth-method>
<realm-name>
Default <!-- Optional, used for BASIC -->
</realm-name>
</login-config>

25. 25
The security-role Element
<security-role>
<description>
Represents all fulltime employed individuals.
</description>
<role-name> Employee </role-name>
</security-role>

26. 26
FORM
• The benefit to the Form approach is aesthetic. Essentially
you can guarantee that all users, regardless of which browser
they use.
• Several requirements are necessary :
a. The form method must be POST.
b. The action or URL must be defined as j_security_check.
c. The name attribute for the username must be j_username.
d. The name attribute for the password must be j_password.

27. 27
We’ll call it Login.html:
<HTML>
<BODY>
<form method="POST" action="j_security_check">
<P>Welcome to my custom login screen!</P>
<P>Name: <INPUT TYPE=’text’ NAME=’j_username’ SIZE=15></P>
<P>Password: <INPUT TYPE=’password’ NAME=’j_password’ SIZE=15></P>
<P><INPUT TYPE=’submit’ VALUE=’OK’></P>
</FORM>
</BODY>
</HTML>

28. 28
Custom authentication form
Once again, we will keep it very simple and
define the following Error.html page:
<HTML>
<BODY>
You failed to log in successfully.
Hit the “Back” button to try again.
</BODY>
</HTML>

29. 29
<login-config>
<auth-method> FORM </auth-method>
<form-login-config>
<form-login-page>
/AuthenticationForm.html
</form-login-page>
<form-error-page>
/Error.html
</form-error-page>
</form-login-config>
</login-config>

30. 30
DIGEST
As we have said, one of the greatest security limitations of BASIC authentication is that
information is transferred over the network in simple BASE64-encoded text.
Someone snooping the line can easily capture a client’s username and password to gain access
to the site. DIGEST adds an extra layer of security when authenticating the user.
Instead of transferring the password,the server creates a nonce, a random value that is unique.
An example of a nonce could be the client’s IP address followed by a time stamp and some
random data. It might look something like this: 127.0.0.1: 86433665446: dujehIIJRTGDKdkfj
• The client uses a secure encryption algorithm to create, or hash, a digest.
• A digest is a one-directional, encrypted value that represents data. In this case, the digest
consists of the nonce, username, and password.

31. 31

32. 32
CLIENT-CERT
• HTTPS Client authentication, or CLIENT-CERT, is the strongest
form of authentication. HTTPS is HTTP over Secure Socket
Layer (SSL).
• Instead of simply providing a username and password, the client
must provide that information in addition to a personal certificate
for authorization to access the server.

33. 33

34. 34
Scenarios that were previously threatening pose no or little threat when
using certificates. Here are some potential scenarios:
• If the object is retrieved during its commute to its
destination by an unauthorized receiver, that person will
be unable to extract its information because they lack the
key.
• Because the certificate also has a time stamp associated
with it, a retrieved certificate is invalidated after a period
of lapsed time; thus it cannot be forged during future login
attempts.
• Obtaining a stolen public key serves no purpose because
although it allows you to verify the person sending the
certificate, it does not grant you access to the system they
are attempting to access.

35. 35
• A common problem is known as man-in-the-middle attacks.
Someone places themselves between the client and server and
manages to intercept the authentication and pose as a valid
user.
• One solution to protecting a public key during its transfer is to
encrypt communication or use direct connections the other is to
use digital certificates.
• Digital certificates attach identity to a public key. They act like a
driver’s license or passport in that they prove you are who you
claim to be.
• A certificate contains your public key and some additional
information signed by a third party’s private key. Companies
such as Versign and Thawte, known as a certificate authority
(CA), sell certificates to individuals to enable them to sign their
public key.

36. 36
Deployment Descriptor Tags<web-app>
<servlet>
<servlet-name> secret </servlet-name>
<serlvet-class> SalaryServlet </servlet-
class>
</servlet>
<security-constraint>
<web-resource-collection>
<web-resource-name>
SecretProtection </web-resouce-
name>
<url-pattern> /servlet/SalaryServlet
</url-pattern>
<url-pattern> /servlet/secret </url-
pattern>
<http-method> GET </http-method>
<http-method> POST </http-method>
</web-resource-collection>
<auth-constraint>
<role-name> manager </role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method> FORM </auth-method>
<form-login-config>
<form-login-page> /AuthenticationForm.html
</form-login-page>
<form-error-page> /Error.html
</form-error-page>
</form-login-config>
</login-config>
</web-app>

37. 37

38. 38

39. 39