Chapter 9 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.

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

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.

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);

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

Assume the browser is an open book Don’t send data to the browser that you don’t 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.

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.

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.

Example Hello ${param.name}! Hello Walter Hello !

XSS attack Attacker creates a malicious URL and uses an inviting 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.

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.

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.

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 tag by default escapes >,<, &,’ –Java.net.URLEncoder object transforms any character outside the whilelist into their hexadecimal form.

Fixing XSS <% String name = request.getParameter(“name”); if (!ID_REGEX.matcher(name).matches()) { throw new ValidationException(“invalid name”); } %> Hello ${param.name}!

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.

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/ OK\r\n … Then the client sees 2 responses.

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 Valid looking URLs in phishing makes it harder to detect filters and security software

Example of open Redirect String nextPage = request.getParameter(“next”); If (nextPage.matches(“a-zA-Z0-9/:?&_\\+]+” { response.sendRedirect(nextPage); }

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.

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

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

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.

Request Provenance Name of new user: Password for new user:

Request Provenance Name of new user: Password for new user: document.usr_form.submit();

Request Provenance Name of new user: Password for new user: <input type=“hidden” name=“req_id” value=“87ae34d92ba7a1”

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.

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.

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 If session id is using cookies enforce set the cookie to secure only. Do not set the cookie domain to the top-level