Morton 29 de octubre de 2009 a las 09.04
   Imprimir artículo
elWebmaster.com

Qu茅 son y c贸mo combatir las vulnerabilidades XSS


javascriptwide2El XSS (o Cross-site Scripting) es uno de los problemas m谩s importantes en las aplicaciones web de hoy en d铆a, basado en la explotaci贸n de las vulnerabilidades del sistema de validaci贸n HTML.

Te arriesgas a un ataque XSS cada vez que pones contenido que pudiera contener scripts de alguien que no sea de confianza en tu p谩gina web. En esta nota te contamos de qu茅 se trata.
Existen tres tipos de Cross-Site Scripting:

  • El XSS reflejado: es cuando una p谩gina HTML refleja informaci贸n ingresada por el usuario, por ejemplo, desde un formulario HTML hasta el navegador, sin desinfectar de forma adecuada la respuesta. A continuaci贸n hay un ejemplo de esto en un servlet:
  1. out.writeln(鈥淵ou searched for:+request.getParameter(鈥渜uery鈥);
  • XSS almacenado: es cuando un script ingresado por un atacante se almacena en el servidor y luego se muestra en las p谩ginas html del servidor web, sin filtro HTML apropiado. Ejemplos de esto ocurren mucho en blogs o foros. A continuaci贸n hay un ejemplo de esto en un servlet que es pedido desde la base de datos y devuelto en la p谩gina HTML sin validac铆on alguna:
  1. out.writeln("
  2. " + guest.name + " " + guest.comment);
  • DOM XSS: es cuando JavaScript utiliza informaci贸n ingresada o informaci贸n del servidor para escribir de forma din谩mica elementos HTML (DOM), nuevamente, sin desinfecci贸n/filtraci贸n HTML.

XSS puede usarse para:

  • Desfigurar p谩ginas web
  • Hijack de sesiones de usuarios
  • Conducir ataques phishing
  • Ejecutar c贸digo malicioso en el contexto de la sesi贸n de usuario
  • Desparramar malware

Protegernos contra XSS

Para protegernos contra XSS todos los par谩metros de la aplicaci贸n deber铆an estar validados y/o codificados antes de darles salida en una p谩gina HTML.

  • Siempre valida en el lado del servidor para mantener la integridad y seguridad de la informaci贸n:
    • Valida toda la informaci贸n ingresada en la aplicaci贸n para tipo, formato, rango y contexto antes de almacenarla o mostrarla.
    • Utiliza white-listing (lo que se permite), rech谩zalo si es inv谩lido, en lugar de filtrarlo con una black-list (lo que no se permite).
  • Codificaci贸n de salida:
    • Configura de forma expl铆cita la codificaci贸n de caracteres para todas las p谩ginas web (ISO-8859-1 or UTF 8):
      <%@ page contentType=”text/html;charset=ISO-8859-1″ language=”java” %>
    • Toda la informaci贸n suministrada por el usuario deber铆a ser codificada por HTML o XML antes de rendirse.

Protecci贸n Java espec铆fica contra XSS

Validando entradas con Java:

  • Puedes utilizar las expresiones Corrientes de Java para validar entradas, este ejemplo de WebGoat permite espacios en blanco, a-zA-Z_0-9, y los caracteres – y ,
  1. String regex = "[\\s\\w-,]*";
  2. Pattern pattern = Pattern.compile(regex);
  3. validate(stringToValidate, pattern);
  • Utiliza validadores de frameworks (Struts, JSF, Spring…). Con Java EE 6 puedes utilizar el Framework Bean Validation para definir de forma centrada las limitaciones de validaci贸n en los objetos modelos y JSF 2.0 para extender la validaci贸n modelo a la UI. Por ejemplo, aqu铆 hay un campo de entrada de JSF 2.0:
  1.  

Un Managed Bean JSF 2.0 de reserva utilizando el Framework Bean Validation:

  1. @ManagedBean
  2. public class Booking {
  3. ...
  4. @NotNull(message = "Credit card number is required")
  5. @Size(min = 16, max = 16,
  6. message = "Credit card number must 16 digits long")
  7. @Pattern(regexp = "^\\d*$",
  8. message = "Credit card number must be numeric")
  9. public String getCreditCardNumber() {
  10. return creditCardNumber;
  11. }
  12. }

Adem谩s, hay nuevos validadores JSF 2.0:

    • <f:validateBean> es un validador que delega la validaci贸n del valor local a la aplicaci贸n Bean Validation.
    • <f:validateRequired> provee la validaci贸n de campo requerida.
    • <f:validateRegexp> provee la validaci贸n com煤n basada en expresi贸n.
  • Utiliza la interface del kit de herramientas Java OWASP Enterprise Security API:
  1. ESAPI.validator().getValidInput(String context,String input,String type,int maxLength,
  2. boolean allowNull,ValidationErrorList errorList)

ESAPI.validator().getValidInput() devuelve las entadas canonizadas y validadas como un String. Las entradas inv谩lidas generar谩n un ValidationErrorList descriptivo, y aquellas que son claramente un ataque generar谩n un IntrusionException descriptivo.

Codificaci贸n de salida con Java

  • Puedes utilizar mecanismos Struts de salida tales como <bean:write… >, o utilizar el atributo por defecto JSTL escapeXML=”true” en <c:out … >
  • Los componentes JSFde salida filtran la salida y escape de caracteres peligrosos como entidades XHTML.<h:outputText value=”#{param.name}”/>
  • Puedes utilizar el m茅todo del kit de herramientas Java OWASP Enterprise Security API de ESAPI Encoder.encodeForHTML() para codificar informaci贸n y utilizarla en contenido HTML. El m茅todo encodeForHTML() utiliza un algoritmo codificador de entidad “whitelist” HTML para asegurarse de que la informaci贸n codificada no sea interpretada como script. Este llamado deber铆a utilizarse para envolver cualquier ingreso de los usuarios que est谩 siendo rendido en el elemento de contenido HTML. Por ejemplo:
  1. Hello, &lt;%=ESAPI.encoder().encodeForHTML(name)%&gt;

Fuente: Java Lobby


Enviar a Del.icio.us Enviar a Meneame Enviar a Digg Enviar a Fresqui Enviar a Enchilame

Deja tu opinión

© 2007 - 2008 elWebmaster.com | Powered by Wordpress | Diseño CSS y XHTML válido. | Algunos íconos basados en FamFamFam Mini
Acceder