Топ-10 уязвимостей безопасности веб-приложений, начиная с XSS

Вы можете использовать OWASP
WebGoat, чтобы узнать больше об уязвимостях безопасности OWASP Top Ten. WebGoat — это пример веб-приложения, в котором есть уроки, показывающие, «что не нужно делать в коде», как использовать код и как исправлять код для каждой уязвимости.

Вы можете использовать
OWASP Enterprise Security API Toolkit для защиты от уязвимостей безопасности OWASP Top Ten.

ESAPI Swingsetэто веб-приложение, которое демонстрирует множество применений API-интерфейса Enterprise Security.

OWASP Top 10 номер 1: XSS = межсайтовый скриптинг

Межсайтовый скриптинг (XSS) является одной из наиболее распространенных проблем безопасности в современных веб-приложениях. Согласно данным
SANS Top Cyber ​​Security Risk , 60% от общего числа попыток атак в Интернете направлены против веб-приложений, а на внедрение SQL и межсайтовый скриптинг приходится более 80% обнаруженных уязвимостей. Вы подвергаетесь риску XSS-атаки в любое время, когда размещаете контент, который может содержать сценарии от кого-то, кому не доверяют, на ваши веб-страницы.

Существует 3 типа межсайтового скриптинга:

• 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, in a servlet 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 : это когда JavaScript использует входные данные или данные с сервера для записи динамических элементов HTML (DOM), опять же без очистки, экранирования / фильтрации HTML.

XSS может использоваться для:

• портить веб-страницы
• захватить пользовательские сессии
• проводить фишинговые атаки
• выполнить вредоносный код в контексте сеанса пользователя
• распространять вредоносное ПО

Защита от XSS

Для защиты от XSS все параметры в приложении должны быть проверены и / или закодированы перед выводом на HTML-страницы.

• Всегда проверяйте на стороне сервера целостность и безопасность данных:
  
  • Проверьте все входные данные в приложении для типа, формата, длины, диапазона и контекста перед сохранением или отображением.
  • Используйте белый список (что разрешено), отклоните, если он недействителен, вместо того, чтобы отфильтровывать черный список (что не разрешено).
• Выходная кодировка:
  
  • 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}"/>

  @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:

• Bean Validation — The Java EE 6 Tutorial, Volume I
• JSF 2.0 validation
• XSSed
• Top 10 most critical web application security vulnerabilities
• Open Web Application Security Project (OWASP)
• OWASP Enterprise Security API