Introducción

Este artículo proporciona un modelo positivo simple para evitar que XSS utilice
la salida de escape / codificación correctamente. Si bien hay una gran cantidad
de vectores de ataque XSS, seguir algunas reglas simples puede defenderse
completamente de este ataque grave.

Este artículo no explora el impacto técnico o comercial de XSS. Baste decir

que puede llevar a un atacante a obtener la capacidad de hacer cualquier cosa
que una víctima pueda hacer a través de su navegador.

Tanto el XSS reflejado como el almacenado pueden abordarse realizando la

validación adecuada y escapando del lado del servidor. El XSS basado en
DOM se puede abordar con un subconjunto especial de reglas

Puede encontrar más información sobre la seguridad del navegador y los

distintos navegadores en el Manual de seguridad del navegador .

Antes de leer esta hoja de trucos, es importante tener una comprensión

fundamental de la teoría de la inyección .

Un modelo de prevención XSS positivo

Este artículo trata una página HTML como una plantilla, con espacios en los
que un desarrollador puede poner datos no confiables. Estas ranuras cubren
la gran mayoría de los lugares comunes en los que un desarrollador puede
desear colocar datos no confiables. No se permite colocar datos no confiables
en otros lugares del HTML. Este es un modelo de "lista blanca", que niega todo
lo que no está específicamente permitido.

Dada la forma en que los navegadores analizan HTML, cada uno de los
diferentes tipos de ranuras tiene reglas de seguridad ligeramente
diferentes. Cuando coloca datos no confiables en estas ranuras, debe seguir
ciertos pasos para asegurarse de que los datos no se rompan de esa ranura
en un contexto que permita la ejecución del código. En cierto modo, este
enfoque trata un documento HTML como una consulta de base de datos
parametrizada: los datos se mantienen en lugares específicos y se aíslan de
los contextos de código con escape.

Este documento establece los tipos más comunes de ranuras y las reglas para
colocar datos no confiables en ellas de forma segura. Según las diversas
especificaciones, los vectores XSS conocidos y una gran cantidad de pruebas
manuales con todos los navegadores populares, hemos determinado que las
reglas propuestas aquí son seguras.

Los espacios están definidos y se proporcionan algunos ejemplos de cada

uno. Los desarrolladores NO DEBEN poner datos en ninguna otra ranura sin
un análisis muy cuidadoso para garantizar que lo que están haciendo sea
seguro. El análisis del navegador es extremadamente complicado y muchos
personajes de aspecto inocuo pueden ser significativos en el contexto
correcto.
¿Por qué no puedo simplemente codificar
la entidad HTML de datos no confiables?
La codificación de entidad HTML está bien para los datos no confiables que
coloque en el cuerpo del documento HTML, como dentro de
una <div>etiqueta. Incluso funciona para datos no confiables que entran en
atributos, especialmente si eres religioso acerca del uso de citas alrededor de
tus atributos. Pero la codificación de entidad HTML no funciona si está
colocando datos no confiables dentro de una <script> etiqueta en cualquier
lugar, o un atributo de controlador de eventos como onmouseover, o dentro de
CSS, o en una URL. Entonces, incluso si usa un método de codificación de
entidad HTML en todas partes, es muy probable que sea vulnerable a
XSS. DEBE utilizar la sintaxis de escape para la parte del documento
HTML en la que está colocando datos no confiables. De eso se tratan las
siguientes reglas.

Necesita una biblioteca de codificación de

seguridad
Escribir estos codificadores no es tremendamente difícil, pero hay bastantes
trampas ocultas. Por ejemplo, puede tener la tentación de usar algunos de los
atajos de escape como \"en JavaScript. Sin embargo, estos valores son
peligrosos y pueden ser mal interpretados por los analizadores anidados en el
navegador. También puede olvidarse de escapar del personaje de escape, que
los atacantes pueden usar para neutralizar sus intentos de estar a
salvo. OWASP recomienda usar una biblioteca de codificación centrada en la
seguridad para asegurarse de que estas reglas se implementen
correctamente.
Microsoft proporciona una biblioteca de codificación denominada Biblioteca de
secuencias de comandos de sitios de Microsoft Anti-Cross para la plataforma
.NET y ASP.NET Framework tiene una función ValidateRequest incorporada
que proporciona desinfección limitada .

El proyecto OWASP Java Encoder proporciona una biblioteca de codificación

de alto rendimiento para Java.

Reglas de prevención de XSS

Las siguientes reglas están destinadas a evitar todos los XSS en su
aplicación. Si bien estas reglas no permiten una libertad absoluta para colocar
datos no confiables en un documento HTML, deben cubrir la gran mayoría de
los casos de uso comunes. No tiene que permitir todas las reglas en su
organización. Muchas organizaciones pueden encontrar que permitir solo la
Regla # 1 y la Regla # 2 son suficientes para sus necesidades . Agregue
una nota a la página de discusión si hay un contexto adicional que a menudo
se requiere y se puede asegurar con escape.
NO escapes simplemente de la lista de caracteres de ejemplo que se
proporcionan en las distintas reglas. NO es suficiente escapar solo de esa
lista. Los enfoques de la lista negra son bastante frágiles. Las reglas de la lista
blanca aquí se han diseñado cuidadosamente para proporcionar protección
incluso contra futuras vulnerabilidades introducidas por los cambios del
navegador.

REGLA # 0 - Nunca inserte datos no

confiables, excepto en ubicaciones
permitidas
La primera regla es negar todo : no coloque datos que no sean de confianza
en su documento HTML a menos que estén dentro de uno de los espacios
definidos en la Regla # 1 a la Regla # 5. La razón de la Regla # 0 es que hay
tantos contextos extraños dentro de HTML que la lista de reglas de escape se
vuelve muy complicada. No podemos pensar en ninguna buena razón para
poner datos no confiables en estos contextos. Esto incluye "contextos
anidados" como una URL dentro de un JavaScript: las reglas de codificación
para esas ubicaciones son difíciles y peligrosas.

Si insiste en poner datos no confiables en contextos anidados, realice muchas

pruebas entre navegadores y díganos lo que descubra.

Directamente en un script:
<script>...NEVER PUT UNTRUSTED DATA HERE...</script>
Dentro de un comentario HTML:
<!--...NEVER PUT UNTRUSTED DATA HERE...-->
En un nombre de atributo:
<div ...NEVER PUT UNTRUSTED DATA HERE...=test />
En un nombre de etiqueta:
<NEVER PUT UNTRUSTED DATA HERE... href="/test" />
Directamente en CSS:
<style>
...NEVER PUT UNTRUSTED DATA HERE...
</style>
Lo más importante, nunca acepte código JavaScript real de una fuente no
confiable y luego ejecútelo. Por ejemplo, un parámetro llamado "devolución de
llamada" que contiene un fragmento de código JavaScript. Ninguna cantidad
de escape puede arreglar eso.

REGLA # 1 - Escape HTML antes de

insertar datos no confiables en el
contenido del elemento HTML
La regla n. ° 1 es para cuando desee colocar datos no confiables directamente
en el cuerpo HTML en alguna parte. Esto incluye dentro de las etiquetas
normales, como div, p, b, td, etc. Los marcos web tienen un método para
HTML de escape para los caracteres que se detallan a continuación. Sin
embargo, esto no es absolutamente suficiente para otros contextos
HTML. También debe implementar las otras reglas detalladas aquí.
<body>
...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...
</body>
<div>
...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...
</div>
Escape los siguientes caracteres con codificación de entidad HTML para evitar
cambiar a cualquier contexto de ejecución, como script, estilo o controladores
de eventos. Se recomienda el uso de entidades hexadecimales en la
especificación. Además de los 5 caracteres significativos en XML ( &, <, >, ", '),
se incluye la barra diagonal, ya que ayuda a poner fin a una entidad HTML.
& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;
/ --> &#x2F;

&apos; not recommended because its not in the HTML spec (See: section 24.4.1)
&apos; is in the XML and XHTML specs.

Forward slash is included as it helps end an HTML entity

REGLA # 2: escape de atributos antes de

insertar datos no confiables en atributos
comunes HTML
Regla # 2 es para poner datos no confiables en valores de atributos típicos
como width, name, value, etc. Esto no se debe utilizar para los atributos
complejos como href, src, style, o cualquiera de los controladores de eventos
onmouseover gusta. Es extremadamente importante que los atributos del
controlador de eventos sigan la Regla # 3 para los valores de datos HTML
JavaScript.
Dentro del atributo sin comillas :
<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content
Atributo entre comillas simples:
<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content
Atributo entre comillas dobles:
<div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content
A excepción de los caracteres alfanuméricos, escape todos los caracteres con
valores ASCII inferiores a 256 con el &#xHH;formato (o una entidad con nombre
si está disponible) para evitar el cambio del atributo.
La razón por la que esta regla es tan amplia es que los desarrolladores con
frecuencia dejan atributos sin comillas. Los atributos correctamente citados
solo se pueden escapar con la cotización correspondiente.

Los atributos sin comillas se pueden dividir con muchos caracteres,

incluidos [space] % * + , - / ; < = > ^y |.

REGLA # 3 - Escape de JavaScript antes

de insertar datos no confiables en valores
de datos de JavaScript
La regla n. ° 3 se refiere al código JavaScript generado dinámicamente, tanto
los bloques de script como los atributos del controlador de eventos. El único
lugar seguro para colocar datos no confiables en este código es dentro de un
"valor de datos" citado. Incluir datos no confiables dentro de cualquier otro
contexto de JavaScript es bastante peligroso, ya que es extremadamente fácil
cambiar a un contexto de ejecución con caracteres que incluyen (entre otros)
punto y coma, igual, espacio, más y muchos más, así que úselo con precaución
.

Dentro de una cadena citada:

<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script>
Un lado de una expresión citada:
<script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script>
Controlador de eventos entre comillas:
<div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div>
Tenga en cuenta que hay algunas funciones de JavaScript que nunca pueden
usar de forma segura datos no confiables como entrada, ¡ INCLUSO SI
JAVASCRIPT ESCAPÓ!

Por ejemplo:
<script>
window.setInterval('...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED
HERE...');
</script>
A excepción de los caracteres alfanuméricos, escape todos los caracteres
menores de 256 con el \xHHformato para evitar cambiar el valor de los datos al
contexto del script o a otro atributo. NO use atajos de escape como \"porque
el carácter de comillas puede coincidir con el analizador de atributos HTML
que se ejecuta primero. Estos atajos de escape también son susceptibles a los
ataques de escape donde el atacante envía \"y el código vulnerable convierte
aquello \\"que permite la cotización.
Si un controlador de eventos se cotiza correctamente, el desglose requiere la
cotización correspondiente. Sin embargo, hemos hecho esta regla
intencionalmente bastante amplia porque los atributos del controlador de
eventos a menudo se dejan sin comillas. Los atributos sin comillas se pueden
dividir con muchos caracteres, incluidos [space] % * + , - / ; < = > ^y |.
Además, una </script>etiqueta de cierre cerrará un bloque de secuencia de
comandos aunque esté dentro de una cadena entre comillas porque el
analizador HTML se ejecuta antes que el analizador JavaScript. Tenga en
cuenta que esta es una política de escape agresiva que codifica en exceso. Si
hay una garantía de que se logra una cita adecuada, se necesita un conjunto
de caracteres mucho más pequeño. Consulte los ejemplos de escape de
JavaScript del codificador Java OWASP para ver ejemplos de uso adecuado
de JavaScript que requieren un escape mínimo.

REGLA # 3.1: valores JSON de escape HTML en un

contexto HTML y leer los datos con JSON.parse
En un mundo Web 2.0, la necesidad de tener datos generados dinámicamente
por una aplicación en un contexto de JavaScript es común. Una estrategia es
hacer una llamada AJAX para obtener los valores, pero esto no siempre es
eficaz. A menudo, un bloque inicial de JSON se carga en la página para actuar
como un solo lugar para almacenar múltiples valores. Estos datos son difíciles,
aunque no imposibles, de escapar correctamente sin romper el formato y el
contenido de los valores.

Asegúrese de que el Content-Typeencabezado devuelto sea application /

json y no text / html. Esto le indicará al navegador que no comprenda mal el
contexto y ejecute el script inyectado
Mala respuesta HTTP:
HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
Content-Type: text/html; charset=utf-8 <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI
'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens<script>alert(1)</script>&AddressLine2=foxlodge+woods&TownName=
Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!
Buena respuesta HTTP:
HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
Content-Type: application/json; charset=utf-8 <--good
.....
Un antipatrón común se vería:
<script>
// Do NOT do this without encoding the data with one of the techniques listed
below.
var initData = <%= data.to_json %>;
</script>
Serialización JSON
Un serializador JSON seguro permitirá a los desarrolladores serializar JSON
como una cadena de JavaScript literal que se puede incrustar en un HTML en
el contenido de la <script>etiqueta. Los caracteres HTML y los terminadores
de línea de JavaScript deben escaparse. Considere el serializador de
JavaScript de Yahoo para esta tarea.

Codificación de entidad HTML

Esta técnica tiene la ventaja de que el escape de entidades html es
ampliamente compatible y ayuda a separar los datos del código del lado del
servidor sin cruzar ningún límite de contexto. Considere colocar el bloque
JSON en la página como un elemento normal y luego analizar el innerHTML
para obtener el contenido. El javascript que lee el lapso puede vivir en un
archivo externo, lo que facilita la implementación de la aplicación de CSP .
<div id="init_data" style="display: none">
<%= html_escape(data.to_json) %>
</div>
// external js file
var dataElement = document.getElementById('init_data');
// decode and parse the content of the div
var initData = JSON.parse(dataElement.textContent);
Una alternativa a escapar y no literal de JSON directamente en JavaScript, es
la normalización del lado del servidor JSON mediante la
conversión <a \u003cantes de entregarlo al navegador.

REGLA # 4: CSS Escape y validar

estrictamente antes de insertar datos no
confiables en valores de propiedades de
estilo HTML
La regla n. ° 4 es para cuando desea colocar datos no confiables en una hoja
de estilo o una etiqueta de estilo. CSS es sorprendentemente poderoso y
puede usarse para numerosos ataques. Por lo tanto, es importante que solo
use datos no confiables en un valor de propiedad y no en otros lugares en los
datos de estilo. Usted debe permanecer lejos de poner datos no confiables en
propiedades complejas como url, behaviory la costumbre ( -moz-binding).
Tampoco debe poner datos no confiables en el valor de propiedad de
expresión de IE que permite JavaScript.

El valor de la propiedad:
<style>
selector { property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...; }
</style>
<style>
selector { property : "...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE..."; }
</style>
<span style="property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING
HERE...">text</span>
Tenga en cuenta que hay algunos contextos CSS que nunca pueden usar de
forma segura datos no confiables como entrada, ¡ INCLUSO SI ES
CORRECTAMENTE CSS ESCAPADO! Deberá asegurarse de que las URL
solo comiencen con httpnot javascripty que las propiedades nunca
comiencen con "expresión".
Por ejemplo:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE
Excepto los caracteres alfanuméricos, escape todos los caracteres con valores
ASCII inferiores a 256 con el formato de escape \ HH. NO use atajos de escape
como \"porque el carácter de comillas puede coincidir con el analizador de
atributos HTML que se ejecuta primero. Estos atajos de escape también son
susceptibles a los ataques de escape donde el atacante envía \"y el código
vulnerable convierte aquello \\"que permite la cotización.
Si se cita el atributo, la ruptura requiere la cotización correspondiente. Todos
los atributos deben estar entre comillas, pero su codificación debe ser lo
suficientemente fuerte como para evitar XSS cuando los datos no confiables
se colocan en contextos sin comillas.

Los atributos sin comillas se pueden dividir con muchos caracteres,

incluidos [space] % * + , - / ; < = > ^y |.
Además, la </style>etiqueta cerrará el bloque de estilo aunque esté dentro de
una cadena entre comillas porque el analizador HTML se ejecuta antes que el
analizador JavaScript. Tenga en cuenta que recomendamos una codificación
y validación CSS agresiva para evitar ataques XSS para los atributos entre
comillas y sin comillas.

REGLA # 5 - Escape de URL antes de

insertar datos no confiables en valores de
parámetros de URL HTML
La regla n. ° 5 es para cuando desea poner datos no confiables en el valor del
parámetro HTTP GET.
<a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE
PUTTING HERE...">link</a >
Excepto los caracteres alfanuméricos, escape todos los caracteres con valores
ASCII inferiores a 256 con el %HHformato de escape. data:No debe
permitirse incluir datos no confiables en las URL, ya que no hay una buena
manera de desactivar los ataques con escape para evitar el cambio de la URL.
Todos los atributos deben ser citados. Los atributos sin comillas se pueden
dividir con muchos caracteres, incluidos [space] % * + , - / ; < = > ^y |. Tenga
en cuenta que la codificación de entidad es inútil en este contexto.
ADVERTENCIA: ¡No codifique URL completas o relativas con codificación
URL! Si la entrada no es de confianza está destinado a ser colocado
en href, srcu otros atributos basados en URL, debe ser validado para
asegurarse de que no apunta a un protocolo inesperado, especialmente
 los javascriptenlaces. Las URL deben codificarse en función del contexto de
visualización como cualquier otro dato. Por ejemplo, las URL impulsadas por
el usuario en los HREFenlaces deben estar codificadas por atributos.
Por ejemplo:
String userURL = request.getParameter( "userURL" )
boolean isValidURL = Validator.IsValidURL(userURL, 255);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

REGLA # 6 - Desinfecte el marcado HTML

con una biblioteca diseñada para el
trabajo
Si su aplicación maneja el marcado, una entrada no confiable que se supone
que contiene HTML, puede ser muy difícil de validar. La codificación también
es difícil, ya que rompería todas las etiquetas que se supone que deben estar
en la entrada. Por lo tanto, necesita una biblioteca que pueda analizar y limpiar
texto con formato HTML. Hay varios disponibles en OWASP que son fáciles
de usar:

HtmlSanitizer

Una biblioteca .Net de código abierto. El HTML se limpia con un enfoque de

lista blanca. Todas las etiquetas y atributos permitidos se pueden
configurar. La biblioteca se prueba con la hoja de trucos de evasión del
filtro OWASP XSS
var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);
OWASP Java HTML Sanitizer
import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");
Para obtener más información sobre la construcción de políticas de OWASP
Java HTML Sanitizer, consulte aquí .

Ruby on Rails SanitizeHelper

El SanitizeHelpermódulo proporciona un conjunto de métodos para eliminar

texto de elementos HTML no deseados.
<%= sanitize @comment.body, tags: %w(strong em a), attributes: %w(href) %>
Otras bibliotecas que proporcionan desinfección HTML incluyen:

 Desinfectante HTML de la Biblioteca de cierre de Google (JavaScript / Node.js, docs )

 DOMPurify (JavaScript, requiere jsdom para Node.js)
 PHP HTML Purifier
 Blanqueador de pitón
REGLA # 7 - Evita las URL de JavaScript
URL no confiables que incluyen el protocolo javascript: ejecutará el código
javascript cuando se use en ubicaciones DOM de URL, como atributos HREF
de etiqueta de anclaje o ubicaciones src de iFrame. Asegúrese de validar todas
las URL no confiables para asegurarse de que solo contengan esquemas
seguros como HTTPS.

REGLA # 8 - Prevenir XSS basado en DOM

Para obtener detalles sobre qué es XSS basado en DOM y las defensas contra
este tipo de falla XSS, consulte el artículo de OWASP sobre la hoja de trucos
de prevención XSS basada en DOM .

Regla de bonificación n. ° 1: utilizar el

indicador de cookies HTTPOnly
Como puede ver, es difícil prevenir todos los defectos de XSS en una
aplicación. Para ayudar a mitigar el impacto de una falla XSS en su sitio,
OWASP también recomienda que establezca el indicador HTTPOnly en su
cookie de sesión y cualquier cookie personalizada que tenga a la que no
acceda ningún JavaScript que haya escrito. Este indicador de cookies suele
estar activado de forma predeterminada en las aplicaciones .NET, pero en
otros idiomas debe configurarlo manualmente. Para obtener más detalles
sobre el indicador de cookies HTTPOnly, incluido lo que hace y cómo usarlo,
consulte el artículo de OWASP en HTTPOnly .

Regla de bonificación n. ° 2: Implementar

la política de seguridad de contenido
Existe otra buena solución compleja para mitigar el impacto de una falla de
XSS llamada Política de seguridad de contenido. Es un mecanismo del lado
del navegador que le permite crear listas blancas de origen para los recursos
del lado del cliente de su aplicación web, por ejemplo, JavaScript, CSS,
imágenes, etc. CSP a través de un encabezado HTTP especial indica al
navegador que solo ejecute o procese recursos de esas fuentes.

Por ejemplo este CSP:

Content-Security-Policy: default-src: 'self'; script-src: 'self'
static.domain.tld
Le indicará al navegador web que cargue todos los recursos solo desde el
origen de la página y los archivos de código fuente JavaScript
adicionalmente static.domain.tld. Para obtener más detalles sobre la Política
de seguridad de contenido, incluido lo que hace y cómo usarla, consulte este
artículo sobre Política de seguridad de contenido .
Regla de bonificación n. ° 3: utilizar un
sistema de plantillas de escape
automático
Muchos marcos de aplicaciones web proporcionan una funcionalidad de
escape contextual automática, como el escape contextual estricto de
AngularJS y las plantillas Go . Use estas tecnologías cuando pueda.

Regla de bonificación n.º 4: utilice el

encabezado de respuesta de protección X-
XSS
Este encabezado de respuesta HTTP habilita el filtro de secuencias de
comandos entre sitios (XSS) integrado en algunos navegadores web
modernos. Este encabezado generalmente está habilitado de manera
predeterminada de todos modos, por lo que la función de este encabezado es
volver a habilitar el filtro para este sitio web en particular si el usuario lo
deshabilitó.

Tenga en cuenta que Firefox nunca admitió X-XSS-Protection y Chrome y

Edge han anunciado que dejarán de admitirlo.

Regla de bonificación n. ° 5: utilice

correctamente los marcos JS modernos
Los marcos de JavaScript modernos tienen una protección XSS bastante
buena incorporada. Por lo general, el API de marcos permite omitir esa
protección para representar HTML sin escapes o incluir código ejecutable.

Los siguientes métodos y accesorios de API en la tabla a continuación se

consideran peligrosos y al usarlos puede exponer a sus usuarios a una
vulnerabilidad XSS. Si realmente tiene que usarlos, recuerde que ahora todos
los datos deben ser desinfectados por usted mismo.

Marco de JavaScript Métodos / accesorios peligrosos

Angular (2+) bypassSecurityTrust

Reaccionar dangerouslySetInnerHTML

Esbelto {@html ...}

Vue (2+) v-html

Evite la inyección de plantillas en Angular construyendo con el --
prodparámetro ( ng build --prod).
También recuerde mantener su marco actualizado a la última versión con
todas las posibles correcciones de errores.

Resumen de reglas de prevención

XSS
Tipo
de Contexto Muestra de código Defensa
datos

Codificación de
Cuerpo
Cuerda entidad HTML
HTML <span>UNTRUSTED DATA </span>
(regla n. ° 1).

Codificación de
entidad HTML
agresiva (regla n. °
2), solo coloque
datos no
confiables en una
lista blanca de
Atributos
<input type="text" name="fname" atributos seguros
Cuerda HTML
value="UNTRUSTED DATA "> (enumerados a
seguros
continuación),
valide
estrictamente los
atributos inseguros
como el fondo, la
identificación y el
nombre.

<a
Obtener Codificación de
Cuerda href="/site/search?value=UNTRUSTED
parámetro DATA ">clickme</a>
URL (regla # 5).

Canonicalice la
entrada, la
URL no validación de URL,
confiable la verificación
en un <a href="UNTRUSTED URL ">clickme</a> segura de URL, la
Cuerda
atributo <iframe src="UNTRUSTED URL " />
lista blanca de http
SRC o y https solo (evite
HREF el protocolo
JavaScript para
abrir una nueva
 Tipo
de Contexto Muestra de código Defensa
datos

ventana),
codificador de
atributos.

Validación
estructural estricta
(regla # 4),
html <div style="width: UNTRUSTED
Cuerda Valor CSS codificación CSS
DATA ;">Selection</div>
Hex, buen diseño
de características
CSS.

Asegurar las
variables
JavaScript se
citan, JavaScript
<script>var currentValue='UNTRUSTED
Codificación Hex,
Variable DATA ';</script>
Cuerda JavaScript
JavaScript <script>someFunction('UNTRUSTED
DATA ');</script> codificación
Unicode, evite
barra invertida
codificación
( \"o \'o \\).

Validación HTML
Cuerpo (JSoup, AntiSamy,
HTML <div>UNTRUSTED HTML</div>
HTML HTML Sanitizer
...).

<script>document.write("UNTRUSTED Hoja de trucos de

Cuerda DOM XSS INPUT: " + document.location.hash prevención XSS
);<script/> basada en DOM

Los siguientes fragmentos de HTML demuestran cómo representar de forma

segura datos no confiables en una variedad de contextos diferentes.

Atributos segura HTML

incluyen: align , alink, alt, bgcolor, border, cellpadding, cellspacing, class, c
olor, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight,
marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, row
span, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vli
nk, vspace, width.

Resumen de reglas de codificación

de salida
El propósito de la codificación de salida (en lo que se refiere a Cross Site
Scripting) es convertir la entrada no confiable en una forma segura donde la
entrada se muestra como datos para el usuario sin ejecutar como código en
el navegador. Los siguientes cuadros detallan una lista de los métodos de
codificación de salida críticos necesarios para detener el Cross Site Scripting.

Tipo de
Mecanismo de codificación
codificación

Codificación de Convertir &a &amp;, Convertir <a &lt;, Convertir >a &gt;,
entidad HTML Convertir "a &quot;, Convertir 'a &#x27;, Convertir /a&#x2F;

Excepto los caracteres alfanuméricos, escape todos los caracteres

Codificación de
con el &#xHH;formato de entidad HTML , incluidos los
atributos HTML
espacios. ( HH = valor hexadecimal)

Codificación porcentual estándar, ver aquí . La codificación de

Codificación de
URL solo debe usarse para codificar valores de parámetros, no la
URL
URL completa o los fragmentos de ruta de una URL.

Codificación Excepto los caracteres alfanuméricos, escape todos los caracteres

JavaScript con el \uXXXXformato de escape unicode ( X = Entero).

Soportes de escape de CSS \XXy \XXXXXX. El uso de un escape de

dos caracteres puede causar problemas si el siguiente personaje
Codificación continúa la secuencia de escape. Hay dos soluciones (a) Agregue
CSS Hex un espacio después del escape CSS (será ignorado por el
analizador CSS) (b) use la cantidad total de escape CSS posible
rellenando con cero el valor.

Artículos relacionados
XSS Attack Cheat Sheet

El siguiente artículo describe cómo explotar diferentes tipos de

vulnerabilidades XSS que este artículo fue creado para ayudarlo a evitar:

 OWASP: XSS Filter Evasion Cheat Sheet - Basado en - RSnake's: "XSS Cheat
Sheet" .
 Descripción de vulnerabilidades XSS

 Artículo de OWASP sobre vulnerabilidades XSS .

Discusión sobre los tipos de vulnerabilidades XSS

 Tipos de secuencias de comandos entre sitios .

Cómo revisar el código para vulnerabilidades de secuencias de

comandos entre sitios

 Artículo de la Guía de revisión de código de OWASP sobre Revisión de código

para vulnerabilidades de secuencias de comandos entre sitios .

Cómo probar las vulnerabilidades de secuencias de comandos entre

sitios

 Artículo de la Guía de pruebas de OWASP sobre Pruebas para vulnerabilidades

de secuencias de comandos en sitios cruzados .
 Reglas de codificación mínima experimental de XSS