Web Applications

1
Chapter 9

• Web Applications

2
Web Applications

• Web Applications are public and available to the
  entire world.
• Easy access to the application means also easy
  access for malicious users.
• HTTP protocol was not designed for applications.
• Stateless protocol
• Session management creates many security problems
• Application needs to protect itself as well as
  other users of the applications.

3
In this chapter

• Input and output validation
• HTTP Considerations
• Use of POST to keep sensitive information from
  logs and caches.
• Maintaining Sessions
• Using Structs framework for input validation

4
Input and Output Validation

• A web application cannot depend on the client to
  do input validation. Attackers are not going to
  use such clients.
• An attacker can change any value in the web
  request cookies, user-agent, hidden parameters.
• An attacker can post to a URL in the wrong order.

5
Example

• String userAgent request.getHeader(user-agent)
  
• String sQuery DELETE FROM UP_USER_UA_MAP WHERE
  USER_ID userId AND USER_AGENT
  userAgent
• stmt.executeUpdate(sQuery)

6
Do not trust the client

• Cant trust any information supplied by the
  client to be correct including any headers,
  hidden fields, cookies or parameters.
• Cant trust that the data is properly formatted
• Cant trust that the data contains only certain
  characters
• Cant trust that any data elements are of certain
  length.

7
Assume the browser is an open book

• Dont send data to the browser that you dont
  want the user to see.
• There is no such thing as secret hidden fields.
  
• Example E-trade
• Etrade used a weak masking algorithm to hide the
  username/password in a cookie.

8
Example

• A pre-school website needed to only allow parents
  to access a secure part of the website.
• The authentication used a JavaScript to ask the
  user to enter a password
• Parents received the password via paper.

9
Protect Your Clients

• Web applications must not send input from one
  user to another user without checking it.
• This problem is known as cross-site scripting
  (XSS)?
• XSS is one of the most common security problems
  on the web.

10
Example

• ltc if testparam.sayHellogt
• lt! Lets welcome the user param.name --gt
• Hello param.name!
• lt/c ifgt
• Hello Walter
• Hello ltscript srchttp//evil.org/evil.jsgtlt/script
  gt!

11
XSS attack

• Attacker creates a malicious URL and uses an
  inviting e-mail message or some other social
  engineering trick to get a victim to visit the
  URL
• User clicks on the link and it goes to a
  legitimate site with XSS problem
• The application in the legitimate site reflects
  the data back to the user browser and the browser
  executes the script and may send information like
  cookies and other data stored in the browser to
  the attacker.

12
XSS attack

• XSS is not limited to data reflected back to the
  browser by the same application
• Sometimes the data gets stored in a database and
  several users can get impacted
• Sometimes one application may store the bad data
  and another sends it to the users.
• All applications that send data to the user
  should check it for validity.

13
MySpace

• A user was able to post a script on his profiles
  that was sent to everybody who looked at the
  profiles
• The script executed and add him as a friend to
  the victim
• As a friend he was able to see data he could not
  see before.

14
Preventing XSS

• Perform output validation or output encoding
• Output encoding changes the output such that it
  does not get interpreted by the browser
• Use whitelist not blacklist
• Example a last name can only contain certain
  characters
• Encode special characters
• JSTL ltcoutgt tag by default escapes gt,lt, ,
• Java.net.URLEncoder object transforms any
  character outside the whilelist into their
  hexadecimal form.

15
Fixing XSS

• ltc if testparam.sayHellogt
• lt! Lets welcome the user param.name --gt
• lt
• String name request.getParameter(name)
• if (!ID_REGEX.matcher(name).matches())
• throw new ValidationException(invalid name)
• gt
• Hello param.name!
• lt/c ifgt

16
HTTP Response Splitting

• Can be accomplished when the application allows
  user input in response headers and allows the
  input to contain CR-LF
• An attacker can then change any header or content
  as they wish
• It may confuse a proxy and the second response
  may get sent to another user.

17
Example

• String author request.getParameter(author)
• Cookie cookie new Cookie(author, author)
• cookie.setMaxAge(cookieExpiration)
• Response.addCookie(cookie)?
• If author is
• Wiley Hacker\r\n\r\nHTTP/1.1 200 OK\r\n
• Then the client sees 2 responses.

18
Open Redirect

• Open redirect means an application will issue a
  redirect to a site based on user input
• Open redirects can be used by phishing attacks to
  send a valid looking URL via email
• Valid looking URLs in phishing email makes it
  harder to detect filters and security software

19
Example of open Redirect

• String nextPage request.getParameter(next)
• If (nextPage.matches(a-zA-Z0-9/?_\\
• response.sendRedirect(nextPage)

20
Open Proxy

• Like open redirect, open proxy can be used by
  phishing schemes
• Open proxy can also be used to steal cookies
  (session cookies) and other information
• Open proxy can happen when an application fetches
  information from another website to display for
  the user.

21
Use POST not GET

• GET requests expose the parameters in the URL
• URLs get
• Stored in browser history
• Logged to the web server logs
• Sent to other sites are referer header
• POST requests are more secure.
• To protect the data applications should return an
  error when called with GET

22
Request Ordering

• HTTP protocol is stateless
• Applications should never assume the user will go
  through all the steps in order
• Applications that pass hidden fields from one
  request to the next are vulnerable to this type
  of attack

23
Error handling

• Errors can reveal information about the internals
  of the system if displayed to the end user
• Applications should catch all errors/exceptions
  and print a friendly message to the user.

24
Request Provenance

• ltform methodPOST action/new_usergt
• Name of new user ltinput typetext
  nameusernamegt
• Password for new user ltinput typepassword
  nameuser_passwordgt
• ltinput typesubmit nameaction valueCreate
  Usergt
• lt/formgt

25
Request Provenance

• ltform methodPOST actionhttps//www.example.com
  /new_usergt
• Name of new user ltinput typetext
  nameusernamegt
• Password for new user ltinput typepassword
  nameuser_passwordgt
• ltinput typesubmit nameaction valueCreate
  Usergt
• lt/formgt
• ltscriptgt
• document.usr_form.submit()
• lt/scriptgt

26
Request Provenance

• ltform methodPOST action/new_usergt
• Name of new user ltinput typetext
  nameusernamegt
• Password for new user ltinput typepassword
  nameuser_passwordgt
• ltinput typesubmit nameaction valueCreate
  Usergt
• ltinput typehidden namereq_id
  value87ae34d92ba7a1
• lt/formgt

27
Maintaining Session State

• Web applications need a session to maintain state
  using the HTTP stateless protocol
• Session identifiers can be passed either as a
  parameter, part of the URL or in cookies
• Most application contents provide session
  management via cookies.
• Programmers should utilize web application
  containers to manage sessions
• A good session management chooses session
  identifiers that cannot be guessed.

28
Session Timeouts

• A session timeout is necessary to protect against
  session hijacking
• Idle timeout reduces the possibility of somebody
  taking over an idle session
• A max session life makes it impossible for an
  attacker to keep a session live forever.
• Servlet specification does not mandate a max
  session life. It can be implemented using Servlet
  filters.

29
Session managment

• Begin a new session after authentication
• Attacker creates a session in a public terminal
  and waits for the user to login
• Do not accept session identifier supplied as a
  parameter
• Example http//www.example.com/index.jsp?jsessioni
  dabc123
• If session id is using cookies enforce set the
  cookie to secure only.
• Do not set the cookie domain to the top-level