¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo

Cómo: Evitar secuencias de comandos entre sitios en ASP.NET

Mayo de 2005

Publicado: 21 de Diciembre de 2005

patterns & practices Developer Center (en inglés)

J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley
Microsoft Corporation

Este artículo se aplica a:
ASP.NET versión 1.1
ASP.NET versión 2.0

Resumen: En este artículo se describe cómo puede proteger las aplicaciones ASP.NET de ataques de secuencias de comandos entre sitios mediante una validación de entradas y una codificación de salidas apropiadas. También se describen una serie de mecanismos de protección que puede utilizar junto con estas dos contramedidas principales.
Los ataques de secuencias de comandos entre sitios (XSS) se aprovechan de las vulnerabilidades en la validación de páginas Web mediante la inyección de código de secuencias de comandos del cliente. Entre las vulnerabilidades más frecuentes que hacen que las aplicaciones Web sean susceptibles de ataques de secuencias de comandos entre sitios están no validar correctamente las entradas, no codificar los resultados y confiar en los datos extraídos de una base de datos compartida. Para proteger la aplicación contra ataques de secuencias de comandos entre sitios, considere todas las entradas como malintencionadas. Restrinja y valide todas las entradas. Codifique todos los resultados que, potencialmente, puedan incluir caracteres HTML. Esto incluye los datos que se leen de archivos y bases de datos.

En esta página

Objetivos Objetivos
Descripción general Descripción general
Resumen de los pasos Resumen de los pasos
Paso 1. Comprobación de la habilitación de la validación de solicitudes de ASP.NET Paso 1. Comprobación de la habilitación de la validación de solicitudes de ASP.NET
Paso 2. Revisión del código ASP.NET que genera resultados HTML Paso 2. Revisión del código ASP.NET que genera resultados HTML
Paso 3. Determinación de la presencia de parámetros de entrada en el HTML resultante Paso 3. Determinación de la presencia de parámetros de entrada en el HTML resultante
Paso 4. Revisión de etiquetas y atributos HTML potencialmente peligrosos Paso 4. Revisión de etiquetas y atributos HTML potencialmente peligrosos
Paso 5. Evaluación de contramedidas Paso 5. Evaluación de contramedidas
Factores adicionales Factores adicionales
Comentarios Comentarios
Soporte técnico Soporte técnico
Comunidad y grupos de noticias Comunidad y grupos de noticias
Colaboradores y revisores Colaboradores y revisores

Objetivos

  • Entender las vulnerabilidades habituales de secuencias de comandos entre sitios en la validación de páginas Web.

  • Aplicar contramedidas para ataques de secuencias de comandos entre sitios.

  • Restringir las entradas mediante el uso de expresiones regulares, comprobaciones de tipos y los controles del validador de ASP.NET.

  • Restringir el resultado para asegurar que el explorador no ejecute etiquetas HTML que contengan código de secuencias de comandos.

  • Revisar las etiquetas y atributos HTML potencialmente peligrosos y evaluar contramedidas.

Descripción general

Los ataques de secuencias de comandos entre sitios se aprovechan de las vulnerabilidades en la validación de páginas Web mediante la inyección de código de secuencias de comandos del cliente. El código de secuencia de comandos se incrusta en los datos de repuesta que, a su vez, son devueltos a un usuario desprevenido. A continuación, el explorador del usuario ejecuta el código de secuencia de comandos. Ya que el explorador descarga el código de secuencia de comandos de un sitio de confianza, éste no puede determinar si el código es legítimo; además, las zonas de seguridad de Microsoft Internet Explorer no suponen una defensa. Los ataques de secuencias de comandos entre sitios también funcionan en conexiones HTTP y HTTPS (SSL).

Uno de los ejemplos más serios de ataque de secuencia de comandos entre sitios es un intruso que escribe secuencias de comandos para extraer la cookie de autenticación que da acceso a un sitio de confianza y, a continuación, envía la cookie a una dirección Web conocida por el intruso. Esto permite que el intruso simule la identidad del usuario legítimo y obtenga acceso ilícito al sitio Web.

Entre las vulnerabilidades habituales que hacen que la aplicación Web sea susceptible de ataques de secuencia de comandos entre sitios se incluyen:

  • Error al restringir y validar las entradas.

  • Error al codificar los resultados.

  • La confianza en datos extraídos de una base de datos compartida.

Instrucciones

Las dos contramedidas más importantes para evitar los ataques de secuencias de comandos entre sitios son:

  • Restricción de entradas

  • Codificación de resultados.

Restricción de entradas

Primero, dé por sentado que todas las entradas son malintencionadas. Valide el tipo, la longitud, el formato y el intervalo de la entrada.

  • Para restringir las entradas proporcionadas por los controles del servidor, utilice los controles del validador de ASP.NET, como RegularExpressionValidator y RangeValidator.

  • Para restringir las entradas proporcionadas a través de los controles de entrada HTML del cliente o de las entradas de otros orígenes como cadenas de consulta o cookies, utilice la clase System.Text.RegularExpressions.Regex del código del servidor para comprobar las expresiones regulares del tipo "using" esperadas.

  • Para validar tipos como enteros, dobles, fechas y cantidades en moneda, convierta los datos de entrada al tipo de dato .NET Framework equivalente y resuelva los errores de conversión que se produzcan.

Para obtener más información y ejemplos sobre la restricción de entradas, consulte Cómo: Proteger ASP.NET de los ataques de inyección.

Codificación de resultados

Utilice el método HttpUtility.HtmlEncode para codificar el resultado si contiene entradas del usuario o de otros orígenes como bases de datos. El método HtmlEncode reemplaza caracteres que tengan un significado especial en HTML por variables HTML que representen a esos caracteres. Por ejemplo, se reemplaza < por < y " por ". Los datos codificados no hacen que el explorador ejecute código. En su lugar, los datos se procesan como HTML inofensivo.

De la misma forma, utilice HttpUtility.UrlEncode para codificar las URL resultantes si están construidas a partir de entradas.

Resumen de los pasos

Para evitar las secuencias de comandos entre sitios, realice los siguientes pasos:

  • Paso 1. Comprobación de la habilitación de la validación de solicitudes de ASP.NET.

  • Paso 2. Revisión del código ASP.NET que genera resultados HTML.

  • Paso 3. Determinación de la presencia de parámetros de entrada en el HTML resultante.

  • Paso 4. Revisión de etiquetas y atributos HTML potencialmente peligrosos.

  • Paso 5. Evaluación de contramedidas.

Paso 1. Comprobación de la habilitación de la validación de solicitudes de ASP.NET

De forma predeterminada, la validación de solicitudes está habilitada en Machine.config. Compruebe que la validación de solicitud esté actualmente habilitada en el archivo Machine.config del servidor y que la aplicación no omite esta configuración en el archivo Web.config. Compruebe que validateRequest esté establecido en true, tal y como se muestra en el siguiente ejemplo de código.

<system.web> 
  <pages buffer="true" validateRequest="true" /> 
</system.web>

Puede deshabilitar la validación de solicitudes página a página. Compruebe que las páginas no desactiven esta característica a menos que sea necesario. Por ejemplo, tal vez necesite deshabilitar esta característica en una página si contiene un campo de entrada de texto enriquecido en formato libre diseñado para aceptar un intervalo de caracteres HTML como entrada. Para obtener más información sobre cómo manejar con seguridad este tipo de páginas, consulte Paso 5. Evaluación de contramedidas.

Para comprobar si la validación de solicitudes de ASP.NET está habilitada

  1. Cree una página ASP.NET en la que esté deshabilitada la validación de solicitudes. Para ello, establezca ValidateRequest="false", tal y como se muestra en el siguiente ejemplo de código.

    <%@ Page Language="C#" ValidateRequest="false" %> 
    <html> 
     <script runat="server"> 
      void btnSubmit_Click(Object sender, EventArgs e) 
      { 
        // If ValidateRequest is false, then 'hello' is displayed 
        // If ValidateRequest is true, then ASP.NET returns an exception 
        Response.Write(txtString.Text); 
      } 
     </script> 
     <body> 
      <form id="form1" runat="server"> 
        <asp:TextBox id="txtString" runat="server"  
                     Text="<script>alert('hello');</script>" /> 
        <asp:Button id="btnSubmit" runat="server"    
                    OnClick="btnSubmit_Click"  
                    Text="Submit" /> 
      </form> 
     </body> 
    </html>
    
  2. Ejecute la página. Se mostrará Hello en un cuadro de mensaje porque la secuencia de comandos de txtString se pasa y se procesa como una secuencia de comandos del cliente en el explorador.

  3. Establezca ValidateRequest="true" o quite el atributo de página ValidateRequest y vuelva a la página. Compruebe que se muestra el siguiente mensaje de error.

    A potentially dangerous Request.Form value was detected from the client 
    (txtString="<script>alert('hello...").
    

    De este modo se indica que la validación de solicitudes de ASP.NET está activa y que ha rechazado la entrada porque incluye caracteres HTML potencialmente peligrosos.

    Nota: No debe confiar en la validación de solicitudes de ASP.NET. Considérela una medida de precaución adicional a su propia validación de entradas.

Paso 2. Revisión del código ASP.NET que genera resultados HTML

ASP.NET escribe HTML como resultado de dos formas, que se muestran en los siguientes ejemplos de código.

Response.Write 
<% =

Busque en las páginas el lugar en el que se devuelven al cliente los HTML y URL resultantes.

Paso 3. Determinación de la presencia de parámetros de entrada en el HTML resultante

Analice el diseño y el código de página para determinar si se incluyen parámetros de entrada en el resultado. Estos parámetros pueden proceder de distintos orígenes. En la siguiente lista se incluyen orígenes de entrada comunes:

  • Campos de formulario, como los siguientes:

    Response.Write(name.Text); 
    Response.Write(Request.Form["name"]); 
    Query Strings 
    Response.Write(Request.QueryString["name"]);
    
  • Cadenas de consulta, como las siguientes:

    Response.Write(Request.QueryString["username"]);
    
  • Bases de datos y métodos de acceso a datos, como los siguientes:

    SqlDataReader reader = cmd.ExecuteReader(); 
    Response.Write(reader.GetString(1));
    

    Debe tener bastante cuidado con los datos que se leen en bases de datos si éstas están compartidas con otras aplicaciones.

  • Colecciones de cookies, como las siguientes:

    Response.Write( 
    Request.Cookies["name"].Values["name"]);
    
  • Variables de aplicación y sesión, como las siguientes:

    Response.Write(Session["name"]); 
    Response.Write(Application["name"]);
    

Además del análisis del código fuente, también puede realizar una sencilla prueba si escribe texto como "XYZ" en los campos de formulario y prueba el resultado. Si en el explorador se muestra "XYZ" o si ve "XYZ" cuando visualice el código fuente del HTML, la aplicación Web es vulnerable a secuencias de comandos entre sitios.

Para ver algo más dinámico, inyecte <script>alert('hello');</script> en un campo de entrada. Puede que esta técnica no funcione siempre porque depende del modo en el que se utiliza la entrada para generar el resultado.

Paso 4. Revisión de etiquetas y atributos HTML potencialmente peligrosos

Si crea dinámicamente etiquetas HTML y construye atributos de etiqueta con entradas potencialmente no seguras, asegúrese de codificar como HTML los atributos antes de escribirlos.

En la siguiente página .aspx se muestra cómo escribir HTML directamente en la página de devolución utilizando el control <asp:Literal>. El código utiliza la entrada de usuario de un nombre de color, la inserta en el HTML devuelto y muestra el texto en el color introducido. La página utiliza HtmlEncode para asegurarse de que el texto insertado es seguro.

<%@ Page Language="C#" AutoEventWireup="true"%> 
 
<html> 
  <form id="form1" runat="server"> 
    <div> 
      Color:&nbsp;<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox><br /> 
      <asp:Button ID="Button1" runat="server" Text="Show color"  
         OnClick="Button1_Click" /><br /> 
      <asp:Literal ID="Literal1" runat="server"></asp:Literal> 
    </div> 
  </form> 
</html> 
 
<script runat="server"> 
  private void Page_Load(Object Src, EventArgs e) 
  { 
    protected void Button1_Click(object sender, EventArgs e) 
    { 
      Literal1.Text = @"<span style="color:"  
        + Server.HtmlEncode(TextBox1.Text) 
        + @">Color example</span>"; 
    }            
  } 
</Script>

Etiquetas HTML potencialmente peligrosas

Aunque no se trata de una lista completa, las siguientes etiquetas HTML que se utilizan con frecuencia podrían permitir que un usuario malintencionado inyectase código de secuencia de comandos:

  • <applet>

  • <body>

  • <embed>

  • <frame>

  • <script>

  • <frameset>

  • <html>

  • <iframe>

  • <img>

  • <style>

  • <layer>

  • <link>

  • <ilayer>

  • <meta>

  • <object>

Un intruso puede utilizar atributos HTML como src, lowsrc, style y href junto con las etiquetas anteriores para inyectar secuencias de comandos entre sitios. Por ejemplo, el atributo src de la etiqueta <img> puede ser un origen de inyecciones, tal y como se muestra en los siguientes ejemplos.

<img src="javascript:alert('hello');"> 
<img src="java&#010;script:alert('hello');"> 
<img src="java&#X0A;script:alert('hello');">

Un intruso también puede utilizar la etiqueta <style> para inyectar una secuencia de comandos cambiando el tipo MIME, tal y como se muestra a continuación.

<style TYPE="text/javascript"> 
  alert('hello'); 
</style>

Paso 5. Evaluación de contramedidas

Cuando se encuentre con código ASP.NET que genere HTML utilizando entradas, necesita evaluar las contramedidas adecuadas para la aplicación en cuestión. Las contramedidas incluyen:

  • Codificación del HTML resultante.

  • Codificación de URL resultantes.

  • Filtrado de entradas del usuario.

Codificación del HTML resultante

Si escribe texto como resultado de una página Web y no sabe si contiene caracteres HTML especiales (como <, > y &), realice un procesamiento previo del texto a través del método HttpUtility.HtmlEncode, tal y como se muestra en el siguiente ejemplo de código. Hágalo si el texto procedía de entradas del usuario, una base de datos o un archivo local.

Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));

No sustituya la codificación de los resultados para comprobar si la entrada está bien formada y es correcta. Utilícela como precaución adicional.

Codificación de URL resultantes

Si devuelve al cliente cadenas URL que contengan entradas, utilice el método HttpUtility.UrlEncode para codificar las cadenas URL tal y como se muestra en el siguiente ejemplo de código.

Response.Write(HttpUtility.UrlEncode(urlString));

Filtrado de entradas del usuario

Si tiene páginas que necesitan aceptar un intervalo de elementos HTML, por ejemplo, a través de un tipo de campo de entrada de texto enriquecido, debe deshabilitar la validación de solicitudes de ASP.NET en la página. Si tiene varias páginas que hagan esto, cree un filtro que permita sólo los elementos HTML que desee aceptar. Una práctica habitual consiste en restringir el formato a elementos HTML seguros como negrita (<b>) y cursiva (<i>).

Para permitir entradas HTML restringidas con seguridad

  1. Agregue el atributo ValidateRequest="false" a la directiva @ Page con el fin de deshabilitar la validación de solicitudes de ASP.NET.

  2. Codifique la entrada de cadenas con el método HtmlEncode.

  3. Utilice un control StringBuilder y llame al método Replace para quitar de forma selectiva la codificación de los elementos HTML que desee permitir.

En el siguiente código de página .aspx se refleja este enfoque. La página deshabilita la validación de solicitudes de ASP.NET al establecer el valor ValidateRequest="false". Codifica la entrada como HTML y permite de forma selectiva los elementos HTML <b> e <i> con el fin de permitir el formato de texto sencillo.

<%@ Page Language="C#" ValidateRequest="false"%> 
 
<script runat="server"> 
 
  void submitBtn_Click(object sender, EventArgs e) 
  { 
    // Encode the string input 
    StringBuilder sb = new StringBuilder( 
                            HttpUtility.HtmlEncode(htmlInputTxt.Text)); 
    // Selectively allow  <b> and <i> 
    sb.Replace("&lt;b&gt;", "<b>"); 
    sb.Replace("&lt;/b&gt;", "); 
    sb.Replace("&lt;i&gt;", "<i>"); 
    sb.Replace("&lt;/i&gt;", "); 
    Response.Write(sb.ToString()); 
  } 
</script> 
 
<html> 
  <body> 
    <form id="form1" runat="server"> 
      <div> 
        <asp:TextBox ID="htmlInputTxt" Runat="server"  
                     TextMode="MultiLine" Width="318px" 
                     Height="168px"></asp:TextBox> 
        <asp:Button ID="submitBtn" Runat="server"  
                     Text="Submit" OnClick="submitBtn_Click" /> 
      </div> 
    </form> 
  </body> 
</html>

Factores adicionales

Además de las técnicas expuestas previamente en este artículo, utilice las siguientes contramedidas como salvaguardas adicionales para evitar la secuencia de comandos entre sitios:

  • Establecimiento de la codificación correcta de caracteres.

  • Desconfianza del saneamiento de las entradas.

  • Uso de la opción de cookie HttpOnly

  • Uso del atributo de seguridad <frame>.

  • Uso de la propiedad innerText en lugar de innerHTML.

Establecimiento de la codificación correcta de caracteres

Para restringir datos válidos para las páginas Web correctamente, debería limitar las formas en las que pueden representarse los datos de entrada. De este modo se evita que los usuarios malintencionados puedan utilizar el método Canonicalization y secuencias de escape de múltiples bytes para engañar a las rutinas de validación de entradas. Un ataque de secuencia de escape de múltiples bytes es una manipulación sutil que se aprovecha del hecho de que las codificaciones de caracteres, como UTF-8 (uniform translation format-8), utilizan secuencias de múltiples bytes para representar caracteres que no sean ASCII. Algunas secuencias de bytes no son UTF-8 legítimos, pero puede que algunos decodificadores de UTF-8 las acepten, lo que supone una brecha en la seguridad de la que se pueden aprovechar los intrusos.

ASP.NET permite especificar el conjunto de caracteres en el nivel de página o de aplicación mediante el elemento <globalization> del archivo Web.config. En los siguientes códigos de ejemplo se muestran los dos enfoques y se utiliza la codificación de caracteres ISO-8859-1, que es la predeterminada en las primeras versiones de HTML y HTTP.

Para establecer la codificación de caracteres en el nivel de página, utilice el elemento <meta> o el atributo en el nivel de página ResponseEncoding de la siguiente manera:

<meta http-equiv="Content Type"  
      content="text/html; charset=ISO-8859-1" /> 
 
OR 
<% @ Page ResponseEncoding="iso-8859-1" %>

Para establecer la codificación de caracteres en el archivo Web.config, utilice la siguiente configuración.

<configuration> 
   <system.web> 
      <globalization  
         requestEncoding="iso-8859-1" 
         responseEncoding="iso-8859-1"/> 
   </system.web> 
</configuration>

Validación de caracteres Unicode

Utilice el siguiente código para validar caracteres Unicode en una página.

using System.Text.RegularExpressions; 
. . . 
 
public class WebForm1 : System.Web.UI.Page 
{ 
  private void Page_Load(object sender, System.EventArgs e) 
  { 
    // Name must contain between 1 and 40 alphanumeric characters 
    // and (optionally) special characters such as apostrophes   
    // for names such as O'Dell 
 
    if (!Regex.IsMatch(Request.Form["name"], 
               @"^[\p{L}\p{Zs}\p{Lu}\p{Ll}\']{1,40}$")) 
      throw new ArgumentException("Invalid name parameter"); 
 
    // Use individual regular expressions to validate other parameters 
    . . . 
  } 
}

A continuación se explican las expresiones regulares utilizadas en el ejemplo anterior:

  • ^ indica que se empieza a mirar en esta posición.

  • \p{ ..} coincide con los caracteres de la clase de caracteres con nombre especificada por {..}.

  • {L} realiza coincidencias de izquierda a derecha.

  • {Lu} realiza una coincidencia de mayúsculas.

  • {Ll} realiza una coincidencia de minúsculas.

  • {Zs} hace que el separador y el espacio coincidan.

  • ' hace que el apóstrofe coincida.

  • {1,40} especifica el número de caracteres: no menos de 1 y un máximo de 40.

  • $ indica que se deja de mirar esta posición.

Desconfianza del saneamiento de las entradas

Una práctica habitual del código es intentar sanear las entradas mediante el filtrado de los caracteres que se sabe que no son seguros. No confíe en este enfoque porque los usuarios malintencionados habitualmente saben buscar formas alternativas de saltarse la validación. En lugar de eso, el código debería comprobar las entradas que se consideran como seguras. En la tabla 1 se muestran varias formas seguras de representar algunos caracteres habituales.

Tabla 1: representación de caracteres

Caracteres

Decimal

Hexadecimal

Conjunto de caracteres HTML

Unicode

" (comillas dobles)

&#34

&#x22

"

\u0022

' (comillas simples)

&#39

&#x27

&apos;

\u0027

& (símbolo de y comercial)

&#38

&#x26

&

\u0026

< (menor que)

&#60

&#x3C

<

\u003c

> (mayor que)

&#62

&#x3E

>

\u003e

Uso de la opción de cookie HttpOnly

Service Pack 1 de Internet Explorer 6 y versiones posteriores permiten un atributo de cookie HttpOnly que evita que las secuencias de comandos del cliente tengan acceso a una cookie desde la propiedad document.cookie. En lugar de eso, la secuencia de comandos devuelve una cadena vacía. La cookie se envía al servidor siempre que el usuario se desplace hasta un sitio Web en el dominio actual.

Nota

Los exploradores Web que no admitan el atributo de cookie HttpOnly, o bien ignoran la cookie, o ignoran el atributo, lo que quiere decir que sigue siendo vulnerable a ataques de secuencias de comandos entre sitios.

La clase System.Net.Cookie de la versión 2.0 de Microsoft .NET Framework admite una propiedad HttpOnly. Puede establecer esta propiedad mediante programación o utilizando el elemento <httpCookies> del archivo Web.config de la aplicación. De forma predeterminada, la propiedad de cookie HttpOnly no está establecida. Esto puede verse si se examina el siguiente valor predeterminado de Machine.config.comments.

<httpCookies httpOnlyCookies="false" requireSSL="false" domain=" />

Para ajustar la propiedad HttpOnly de la cookie, agregue la siguiente entrada al archivo Web.config de la aplicación.

<system.web>
 ...
  <httpCookies httpOnlyCookies="true" requireSSL="false" domain=" />
 ...
</system.web>

Las primeras versiones de .NET Framework (versiones 1.0 y 1.1) requieren que se agregue código como el siguiente al controlador de eventos Application_EndRequest del archivo Global.asax de la aplicación para establecer explícitamente el atributo HttpOnly.

protected void Application_EndRequest(Object sender, EventArgs e) 
{
  string authCookie = FormsAuthentication.FormsCookieName;
  foreach (string sCookie in Response.Cookies) 
  {
    // Just set the HttpOnly attribute on the Forms 
    // authentication cookie. Skip this check to set the attribute 
    // on all cookies in the collection

    if (sCookie.Equals(authCookie))
    { 
      // Force HttpOnly to be added to the cookie header
      Response.Cookies[sCookie].Path += ";HttpOnly";
    }
  }
}

Uso del atributo de seguridad <frame>

Internet Explorer 6 y versiones posteriores admiten un nuevo atributo security para los elementos <frame> e <iframe>. Puede utilizar el atributo security para aplicar la configuración de zona de seguridad de sitios restringidos de Internet Explorer del usuario a un elemento frame o iframe. De forma predeterminada, la zona de sitios restringidos no permite la ejecución de secuencias de comandos.

Si utiliza el atributo security, debe establecerse como "restricted", tal y como se muestra a continuación.

<frame security="restricted" src="http://www.somesite.com/somepage.htm"></frame>

Uso de la propiedad innerText en lugar de innerHTML

Si utiliza la propiedad innerHTML para crear una página y el HTML se basa en entradas que son potencialmente no seguras, debe utilizar HtmlEncode para que éste sea seguro. Para no tener que recordar esto, utilice innerText. La propiedad innerText procesa el contenido con seguridad y garantiza que no se ejecutan las secuencias de comandos.

En el siguiente ejemplo se muestra este enfoque para dos controles <span> HTML. El código del método Page_Load establece el texto que se muestra en el elemento Welcome1 <span> utilizando la propiedad innerText, por lo que no es necesaria la codificación como HTML. El código establece el texto en el elemento Welcome2 <span> mediante la propiedad innerHtml; por tanto, antes debe aplicarle HtmlEncode para que sea seguro.

<%@ Page Language="C#" AutoEventWireup="true"%>

<html>
  <body>
    <span id="Welcome1" runat="server"> </span>
    <span id="Welcome2" runat="server"> </span>
  </body>
</html>

<script runat="server">
  private void Page_Load(Object Src, EventArgs e)
  {
    // Using InnerText renders the content safe–no need to HtmlEncode
    Welcome1.InnerText = "Hello, " + User.Identity.Name;

    // Using InnerHtml requires the use of HtmlEncode to make it safe
    Welcome2.InnerHtml = "Hello, " + 
                        Server.HtmlEncode(User.Identity.Name);
  }
</Script>

Comentarios

Si desea enviar comentarios puede utilizar la wikipedia (en inglés) o el correo electrónico:

Nos interesan especialmente sus comentarios sobre los aspectos siguientes:

  • Problemas técnicos relacionados con nuestras recomendaciones

  • Problemas de aprovechamiento y utilidad

Soporte técnico

Los servicios de soporte de Microsoft ofrecen el soporte técnico de los productos y tecnologías de Microsoft a los que se hace referencia en esta guía. Para obtener información sobre soporte, visite el sitio Web de soporte de Microsoft en http://msdn.microsoft.com/security/default.aspx?pull=/isapi/gosupport.asp?Target=/.

Comunidad y grupos de noticias

El soporte técnico de la comunidad se ofrece en los foros y grupos de noticias:

Para sacar el mayor partido de estos foros, busque el grupo de noticias correspondiente a su tecnología o problema. Por ejemplo, si tiene un problema con las características de seguridad de ASP.NET, debería utilizar el foro de seguridad de ASP.NET (ASP.NET Security).

Colaboradores y revisores

  • Colaboradores y revisores externos: Andy Eunson; Chris Ullman, Content Master; David Raphael, Foundstone Professional Services, Rudolph Araujo, Foundstone Professional Services; Manoranjan M. Paul

  • Colaboradores y revisores de PSS y Microsoft Consulting Services: Wade Mascia, Tom Christian, Adam Semel, Nobuyuki Akama, Microsoft Corporation

  • Colaboradores y revisores de Microsoft Product Group: Stefan Schackow, Vikas Malhotra, Microsoft Corporation

  • Colaboradores y revisores de MSDN: Kent Sharkey, Microsoft Corporation

  • Colaboradores y revisores de Microsoft IT: Eric Rachner, Shawn Veney (ACE Team), Microsoft Corporation

  • Equipo de pruebas: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Sameer Tarey, Infosys Technologies Ltd.

  • Equipo de edición: Nelly Delgado, Microsoft Corporation; Sharon Smith, Tina Burden McGrayne, Linda Werner & Associates Inc.

  • Dirección de publicación: Sanjeev Garg, Satyam Computer Services

Mostrar:
© 2015 Microsoft