Thursday Oct 15, 2009

The Top 10 Web Application security vulnerabilities


Yesterday I gave a talk at a the Jacksonville JUG about the  Top 10 most critical web application security vulnerabilities identified by the Open Web Application Security Project (OWASP).
beach.jpg

You can view or download the presentation here

Top 10 Web Security Vulnerabilities




References and More Information:



You can use OWASP's WebGoat to learn more about the OWASP Top Ten security vulnerabilties. WebGoat is an example web application, which has lessons showing "what not to do code", how to exploit the code, and corrected code for each vulnerability.




You can use the OWASP Enterprise Security API Toolkit to protect against the OWASP Top Ten security vulnerabilties.



The ESAPI Swingset is a web application which demonstrates the many uses of the Enterprise Security API.




Thursday Oct 08, 2009

OWASP Top 10 number 3: Malicious File Execution

Number 3 in the Top 10 most critical web application security vulnerabilities identified by the Open Web Application Security Project (OWASP) is Malicious File Execution, which occurs when attacker's files are executed or processed by the web server. This can happen when an input filename is compromised or an uploaded file is improperly trusted.

Examples

  • file is accepted from the user without validating content
  • filename is accepted from the user
In the example below a file name is accepted from the user and appended to the server's filesystem path.
// get the absolute file path on the server's filesystem 
String dir = servlet.getServletContext().getRealPath("/ebanking")
// get input file name
String file = request.getParameter(“file”); 
//  Create a new File instance from pathname string   
File f = new File((dir + "\\\\" + file).replaceAll("\\\\\\\\", "/")); 



If the filename was compromised to  ../../web.xml , it might allow access to web server properties

Malicious File Execution can result in:

  • files loaded from another server and executed within the context of the web server
  • modifying paths to gain access to directories on the web server
  • malicious scripts put into a directory with inadequate access controls

Protecting against Malicious File Execution

  • the Java EE Security Manager should be properly configured to not allow access to files outside the web root.
  • do not allow user input to influence the path name for server resources
    • Inspect code containing a file open, include, create, delete...
  • firewall rules should prevent new outbound connections to external web sites or internally back to any other server. Or isolate the web server in a private subnet
  • Upload files to a destination outside of the web application directory.
    • Enable virus scan on the destination directory.

Java specific Protecting against Malicious File Exection

Use the OWASP ESAPI  HTTPUtilities interface:

  • The ESAPI HTTPUtilities interface is a collection of methods that provide additional security related to HTTP requests, responses, sessions, cookies, headers, and logging.

    The HTTPUtilities getSafeFileUploads method uses the Apache Commons FileUploader to parse the multipart HTTP request and extract any files therein
    public class HTTPUtilities 
    
        public void getSafeFileUploads(java.io.File tempDir,
                                   java.io.File finalDir)
                            throws ValidationException
    


References and More Information:




Tuesday Sep 29, 2009

The Top 10 Web Application security vulnerabilities starting with XSS

This and the next series of blog entries will highlight the Top 10 most critical web application security vulnerabilities identified by the Open Web Application Security Project (OWASP).

You can use OWASP's WebGoat to learn more about the OWASP Top Ten security vulnerabilties. WebGoat is an example web application, which has lessons showing "what not to do code", how to exploit the code, and corrected code for each vulnerability.




You can use the OWASP Enterprise Security API Toolkit to protect against the OWASP Top Ten security vulnerabilities.



The ESAPI Swingset is a web application which demonstrates the many uses of the Enterprise Security API.



OWASP Top 10 number 1: XSS = Cross Site Scripting

Cross Site Scripting (XSS) is one of the most common security problems in today's web applications. According to the SANS Top Cyber Security Risks, 60% of the total attack attempts observed on the Internet are against Web applications and SQL injection and Cross-Site Scripting account for more than 80% of the vulnerabilities being discovered. You are at risk of an XSS attack any time you put content that could contain scripts from someone un-trusted into your web pages.
There are 3 types of cross site scripting:
  • Reflected XSS: is when an HTML page reflects user input data, e.g. from HTTP query parameters or a HTML form, back to the browser, without properly sanitizing the response. Below is an example of this in a servlet:
     out.writeln(“You searched for: “+request.getParameter(“query”);
                                        
  • Stored XSS: is when an Attacker’s input script is stored on the server (e.g. a database) and later displayed in the web server HTML pages, without proper HTML filtering. Examples of this are in blogs, or forums where users can input data that will be displayed to others. Below is an example of this in a servlet, where data is retrieved from the database and returned in the HTML page without any validation:
    out.writeln("<tr><td>" + guest.name + "<td>" + guest.comment); 
    
  • DOM XSS: is when JavaScript uses input data or data from the server to write dynamic HTML (DOM) elements, again without HTML sanitizing/escaping/filtering.

XSS can be used to:
  • deface web pages
  • hijack user sessions
  • conduct phishing attacks
  • execute malicious code in the context of the user's session
  • spread malware

Protecting against XSS

To protect against XSS all the parameters in the application should be validated and/or encoded before being output in HTML pages.
  • Always validate on the server side for data integrity and security:
    • Validate all input data to the application for type, format, length, range, and context before storing or displaying.
    • Use white-listing (what is allowed), reject if invalid, instead of filtering out black-list (what is not allowed).
  • Output encoding:
    • Explicitly set character encoding for all web pages (ISO-8859-1 or UTF 8):
      <%@ page contentType="text/html;charset=ISO-8859-1" language="java" %>
    • all user supplied data should be HTML or XML entity encoded before rendering.

Java specific Protecting against XSS

Validating Input with Java

  • You can use Java regular expressions to validate input, this example from WebGoat allows whitespace, a-zA-Z_0-9, and the characters - and ,
     
    String regex = "[\\\\s\\\\w-,]\*";
    Pattern pattern = Pattern.compile(regex);
    validate(stringToValidate, pattern);
    
    
  • Use Framework (Struts, JSF, Spring...) validators. With Java EE 6 you can use the Bean Validation Framework to centrally define validation constraints on model objects and with JSF 2.0 to extend model validation to the UI. For example here is a JSF 2.0 input field:
    <h:inputText id="creditCard" value="#{booking.creditCardNumber}"/>
    
    Here is the JSF 2.0 booking Managed Bean using the Bean Validation Framework :
    @ManagedBean
    public class Booking { 
     ... 
     @NotNull(message = "Credit card number is required") 
     @Size(min = 16, max = 16, 
     message = "Credit card number must 16 digits long") 
     @Pattern(regexp = "\^\\\\d\*$", 
     message = "Credit card number must be numeric") 
     public String getCreditCardNumber() { 
     return creditCardNumber; 
     } 
    }
    
    In addition there are new JSF 2.0 Validators:
    • <f:validateBean> is a validator that delegates the validation of the local value to the Bean Validation API.
    • <f:validateRequired> provides required field validation.
    • <f:validateRegexp> provides regular expression-based validation


  • Use the OWASP Enterprise Security API Java Toolkit's Validator interface:
    ESAPI.validator().getValidInput(String context,String input,String type,int maxLength,
       boolean allowNull,ValidationErrorList errorList)
    ESAPI.validator().getValidInput() returns canonicalized and validated input as a String. Invalid input will generate a descriptive ValidationErrorList, and input that is clearly an attack will generate a descriptive IntrusionException.

Output Encoding with Java

  • You can use Struts output mechanisms such as <bean:write… >, or use the default JSTL escapeXML="true" attribute in <c:out … > 
  • JSF output components filter output and escape dangerous characters as XHTML entities.
    <h:outputText value="#{param.name}"/>

  • You can use the OWASP Enterprise Security API Java Toolkit's ESAPI Encoder.encodeForHTML() method to encode data for use in HTML content. The encodeForHTML() method uses a "whitelist" HTML entity encoding algorithm to ensure that encoded data can not be interpreted as script. This call should be used to wrap any user input being rendered in HTML element content. For example:
    <p>Hello, <%=ESAPI.encoder().encodeForHTML(name)%></p>

References and More Information:


About

caroljmcdonald

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today