Cómo: Proteger la autenticación de formularios en ASP.NET 2.0

Agosto 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 2.0

Resumen: En este artículo se describe cómo configurar y utilizar de forma segura la autenticación de formularios con aplicaciones ASP.NET 2.0. Algunos factores principales que es preciso considerar son la protección adecuada del vale de autenticación y del almacén de identidades de usuario, así como del acceso a este almacén. No proteger los vales de autenticación es una vulnerabilidad habitual que puede traducirse en la suplantación no autorizada de la identidad, el secuestro de sesión y la elevación de privilegios. Otras vulnerabilidades comunes son no proteger el almacén de usuario o no utilizar contraseñas seguras. En este artículo se describe cómo aplicar contramedidas adecuadas.

En esta página

Objetivos Objetivos
Descripción general Descripción general
Resumen de los pasos Resumen de los pasos
Paso 1. Configuración de -forms protection="All" - Paso 1. Configuración de -forms protection="All" -
Paso 2. Utilización de SHA1 para la generación de HMAC y de AES para el cifrado Paso 2. Utilización de SHA1 para la generación de HMAC y de AES para el cifrado
Paso 3. Protección de los vales de autenticación con SSL Paso 3. Protección de los vales de autenticación con SSL
Factores adicionales Factores adicionales
Recursos adicionales Recursos 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

  • Conocer las contramedidas necesarias para proteger la autenticación de formularios.

  • Cifrar y firmar vales de autenticación de formularios.

  • Proteger el almacén de usuario.

  • Proteger la autenticación de formularios en implementaciones de un único servidor y de una batería de servidores Web.

Descripción general

Las aplicaciones Web ASP.NET versión 2.0 configuradas para la autenticación de formularios utilizan un vale de autenticación que se transmite entre el servidor Web y el explorador en una cookie o en una cadena de consulta URL. El vale de autenticación se genera cuando el usuario inicia sesión por primera vez y se utiliza en ocasiones posteriores para representar al usuario autenticado. Contiene un identificador de usuario y, con frecuencia, el conjunto de las funciones a las que pertenece el usuario. El explorador transmite al servidor Web el vale de autenticación en todas las solicitudes posteriores que forman parte de la misma sesión. Además del almacén de identidades de usuario, también debe proteger este vale para no poner en peligro el mecanismo de autenticación.

No proteger debidamente la autenticación de formularios es una vulnerabilidad habitual que puede traducirse en:

  • Elevación de privilegios: un intruso puede elevar los privilegios de su aplicación actualizando el nombre de usuario o la lista de funciones contenida en el vale y enviando a continuación la información actualizada al servidor. Un intruso capaz de insertar código malintencionado en su aplicación (en una nueva página ASPX, por ejemplo), también será capaz de crear y modificar los vales de autenticación de formularios

  • Secuestro de sesión: puede ocurrir que un intruso se haga con el vale de autenticación de otro usuario y lo utilice para obtener acceso a su aplicación. Esto puede suceder de varias maneras:

    • Como consecuencia de una vulnerabilidad de secuencias de comandos entre sitios.

    • Si el transporte no se protege mediante un mecanismo de seguridad como Secure Sockets Layer (SSL).

    • Si el vale se almacena en la caché del explorador.

  • Utilización de la sesión después de cerrarla: incluso después de que el usuario haya cerrado la sesión de la aplicación y el desarrollador haya llamado a FormsAuthentication.SignOut, el vale de autenticación sigue siendo válido hasta que caduca su tiempo de vida (TTL), de manera que cabe la posibilidad de que un intruso lo utilice para suplantar la identidad de otro usuario.

  • Interceptación: puede ocurrir que un intruso mire el contenido de un vale de autenticación para obtener información confidencial y utilizar esta información para poner en peligro la aplicación.

  • Exposición del almacén de identidades de usuario: un intruso con acceso al almacén de identidades de usuario puede obtener acceso a los nombres de usuario y contraseñas, directamente desde el almacén de datos o mediante un ataque de inyección SQL.

Para proteger el sistema de estas amenazas, la autenticación de formularios en ASP.NET ofrece las contramedidas siguientes:

  • Algoritmos hash MAC (HMAC): utilizan SHA1 o MD5 para proporcionar protección frente a posibles alteraciones. Cualquier cambio realizado en el vale de autenticación se detecta en el servidor y se genera una excepción si se ha modificado.

  • Cifrado: el cifrado convierte los datos de texto sin cifrar contenidos en el vale de autenticación de formularios en texto cifrado ilegible. ASP.NET versión 2.0 utiliza el cifrado simétrico AES para impedir que cualquiera pueda ver el contenido del vale de autenticación de formularios.

  • Restricción de la duración de la sesión: puede aplicar restricciones de la duración para reducir la ventana de tiempo durante la cual un intruso puede suplantar la identidad de otro usuario utilizando para ello el vale de autenticación de éste.

  • Transmisión obligatoria a través de HTTPS: puede impedir que los vales de autenticación se transmitan a través de conexiones HTTP. Esto impide que un intruso pueda ver o modificar el contenido del vale de autenticación mientras éste atraviesa la red.

Resumen de los pasos

Para proteger los vales de autenticación de formularios de la aplicación, siga los pasos descritos a continuación:

  • Paso 1. Configuración de <forms protection="All">.

  • Paso 2. Utilización de SHA1 para la generación de HMAC y de AES para el cifrado.

  • Paso 3. Protección de los vales de autenticación con SSL.

Paso 1. Configuración de -forms protection="All" -

Asegúrese de que los vales de autenticación de formularios están cifrados y compruebe su integridad definiendo protection="All" en el elemento <forms>. Ésta es la configuración predeterminada y puede verla en el archivo de comentarios Machine.config.

<forms protection="All" ... />

Asegúrese de que el archivo Web.config específico de la aplicación no sobrescribe esta configuración predeterminada.

Paso 2. Utilización de SHA1 para la generación de HMAC y de AES para el cifrado

Revise la configuración de <machineKey> para ver el algoritmo hash y los algoritmos de cifrado que se utilizan. Se recomienda utilizar los valores predeterminados SHA1 y AES respectivamente. Si se configura SHA1, se utiliza el algoritmo HMACSHA1. Es mejor utilizar SHA1 que MD5 ya que el primero produce un tamaño de hash mayor y, por tanto, se considera más seguro. Es mejor utilizar AES que DES o 3DES debido al tamaño mayor de la clave.

ASP.NET versión 2.0 utiliza SHA1 y AES de forma predeterminada. Las siguientes configuraciones predeterminadas están documentadas en el archivo de comentarios Machine.config.

<machineKey 
   validationKey="AutoGenerate,IsolateApps"
   decryptionKey="AutoGenerate,IsolateApps"
   decryption="Auto" 
   validation="SHA1" />

Si se utilizan los valores predeterminados Auto para el atributo decryption y AutoGenerate,IsolateApps para el atributo decryptionKey, los vales se cifran con el cifrado simétrico AES. En la medida de lo posible, asegúrese de que las claves validation y decryption estén definidas en AutoGenerate, en lugar de estar codificadas mediante un método no modificable.

El indicador IsolateApp debe definirse en true para garantizar que ninguna aplicación Web malintencionada en un entorno de alojamiento compartido pueda poner en peligro el mecanismo de autenticación de otras aplicaciones. De igual modo, los redireccionamientos entre aplicaciones deben desactivarse por motivos similares. Para hacerlo, defina el atributo EnableCrossAppRedirects del elemento <forms> en false.

La configuración de <machineKey> mencionada anteriormente se recomienda para las implementaciones de un único servidor, y no debe modificarse.

Factores de batería de servidores Web

En el caso de las implementaciones de una batería de servidores Web, debe generar manualmente los valores de las claves y asegurarse de que son los mismos en todos los servidores de la batería de servidores Web. Para obtener más información sobre la configuración del elemento <machineKey>y sobre la generación manual de claves, consulte How To: Configure the MachineKey in ASP.NET 2.0 (en inglés).

Paso 3. Protección de los vales de autenticación con SSL

Para impedir que las cookies de autenticación de formularios puedan capturarse y alterarse mientras atraviesan la red, asegúrese de que utiliza SSL con todas aquellas páginas que requieran acceso autenticado y restrinja los vales de autenticación de formularios a canales SSL al establecer requireSSL="true" en el elemento <forms>.

Para restringir las cookies de autenticación de formularios a canales SSL

Establezca requireSSL="true" en el elemento <forms>, tal y como se muestra en el código siguiente.

<forms loginUrl="Secure\Login.aspx"
       requireSSL="true" ... />

Al definir requireSSL="true", establece la propiedad de cookie secure que determina si el explorador debe devolver la cookie al servidor. Si se establece la propiedad secure, el explorador envía la cookie únicamente a una página segura, que se solicita utilizando una dirección URL HTTPS.

Nota

Si utiliza sesiones que no utilizan cookies, debe asegurarse de que el vale de autorización no se transmite nunca a través de un canal sin protección

Factores adicionales

Además de las medidas anteriores, considere las medidas enumeradas a continuación para ofrecer protección adicional:

  • Considerar la posibilidad de realizar particiones en el sitio Web.

  • No conservar cookies de autenticación de formularios.

  • Considerar la posibilidad de reducir la duración de los vales.

  • Considerar la posibilidad de utilizar una caducidad fija.

  • Aplicar directivas seguras de administración de usuarios.

  • Aplicar reglas de complejidad de contraseñas.

  • Adoptar un método eficaz de validación de datos.

  • Utilizar nombres y rutas de acceso exclusivos para las cookies.

  • Guardar las cookies de autenticación y de personalización en ubicaciones diferentes.

  • Utilizar direcciones URL absolutas para la exploración.

Considerar la posibilidad de realizar particiones en el sitio Web

Para eliminar la necesidad de utilizar SSL en todo el sitio, estructure el sitio Web de modo que las páginas seguras que requieran acceso autenticado se guarden en un subdirectorio distinto al de las páginas que permiten el acceso anónimo. Este enfoque se muestra en la figura 1.

Figura 1. Explorador de soluciones de Visual Studio .NET que muestra un sitio Web con particiones

En la figura 1, las páginas seguras, incluida la página de inicio de sesión de la aplicación, se encuentran en la carpeta protegida Secure, en el directorio raíz virtual de la aplicación.

Para guardar las páginas seguras en una subcarpeta diferente

  1. En Servicios de Internet Information Server (IIS) de Microsoft, configure la carpeta protegida para que requiera SSL. Esto define el atributo AccessSSL=true de la carpeta en la metabase de IIS. Las solicitudes de las páginas contenidas en las carpetas protegidas únicamente tienen éxito si se utiliza HTTPS para la dirección URL de solicitud.

  2. Utilice un elemento <authorization> para asegurarse de que sólo usuarios autenticados tienen acceso a las páginas protegidas. Agregue este elemento debajo de la etiqueta de cierre </system.web>, tal y como se muestra a continuación.

    <!-- The secure folder is for authenticated and SSL access only. -->
    <location path="Secure" >
      <system.web>
        <authorization>
          <deny users="?" />
        </authorization>
      </system.web>
    </location>
    

    Además, la configuración siguiente garantiza que los usuarios no autenticados puedan tener acceso a las páginas contenidas en el directorio raíz de la aplicación. Aplique esta configuración al elemento </system.web> principal.

    <system.web>
      <!-- The virtual directory root folder contains general pages.
           Unauthenticated users can view them and they do not need 
           to be secured with SSL. -->
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
    

    Nota

    Si utiliza este tipo de estructura de sitio, la aplicación no debe confiar en la identidad del usuario en las páginas no SSL. En la configuración anterior, no se envía ningún vale de autenticación para las solicitudes de páginas no SSL. Como consecuencia, el usuario se considera anónimo. Esto afecta a características relacionadas, como la personalización, que requieren el nombre de usuario.

No conservar cookies de autenticación de formularios

No conserve las cookies de autenticación ya que se almacenan en el perfil del usuario del equipo cliente y, si un intruso obtiene acceso físico al equipo del usuario, puede robarlas.

Para garantizar una cookie no persistente, defina la propiedad DisplayRememberMe del control Login en false. Si no está utilizando los controles de inicio de sesión, puede especificar una cookie no persistente cuando llama a los métodos RedirectFromLoginPage o SetAuthCookie de la clase FormsAuthentication una vez validadas las credenciales del usuario. Esta situación se refleja en el siguiente ejemplo de código (cuando se utilizan controles independientes para nombre de usuario, contraseña, botón de inicio de sesión y mensaje de error).

Public Sub Login_Click(sender As Object, e As EventArgs e)
' Is the user valid?
 If (Membership.ValidateUser(userName.Text, password.Text)) Then
     ' Parameter two set to false indicates non-persistent cookie
   FormsAuthentication.RedirectFromLoginPage(username.Text, false)
 Else
   Status.Text = "Invalid credentials. Please try again."
 End If
End Sub

Considerar la posibilidad de reducir la duración de los vales

Considere la posibilidad de reducir la duración de la cookie para reducir la ventana de tiempo durante la cual un intruso puede utilizar una cookie capturada para obtener acceso a la aplicación con una identidad suplantada. Esta medida es especialmente importante cuando no se puede utilizar SSL. El tiempo de validez predeterminado de una cookie de autenticación es de 30 minutos. Considere la posibilidad de reducir este tiempo a 10 minutos, tal y como se muestra a continuación.

<forms 
    timeout="10" 
    slidingExpiration="true"... />

Considerar la posibilidad de utilizar una caducidad fija

En los casos en los que no pueda utilizar SSL, considere la posibilidad de establecer slidingExpiration="false". Esta configuración garantiza que existe un período de caducidad absoluto y que, una vez transcurrido este período, el vale de autenticación dejará de ser válido. Si slidingExpiration="true", el período de caducidad se restablece tras cada solicitud Web.

Aplicar directivas seguras de administración de usuarios

Utilice y aplique contraseñas seguras en todas las cuentas de usuario para garantizar que nadie pueda adivinar la contraseña de otra persona y para mitigar el riesgo que plantean los ataques de diccionarios. Las directivas de contraseña segura incluyen restricciones de la longitud y requisitos de complejidad de las contraseñas tales como:

  • Las contraseñas no pueden contener el nombre completo de la cuenta de usuario ni parte de éste.

  • Las contraseñas deben tener una longitud mínima de seis caracteres.

  • Las contraseñas deben contener caracteres de tres de las cuatro categorías siguientes:

    • Mayúsculas (de la A a la Z)

    • Minúsculas (de la a a la z)

    • Dígitos en base 10 (del 0 al 9)

    • Caracteres no alfanuméricos (por ejemplo, !, $, #, %)

Asimismo, se debe definir el período de vigencia de las contraseñas para garantizar que se cambian en intervalos regulares. Es preciso mantener un historial de contraseñas para asegurarse de que, cuando las contraseñas se cambian, el cambio entre las antiguas y las nuevas contraseñas es suficiente. Esto contribuye a impedir que los usuarios utilicen de nuevo la misma contraseña o una variación de ésta.

Igualmente, las credenciales en ningún caso deben almacenarse en texto sin cifrar en una ubicación fácilmente accesible como el archivo Web.config. El almacén de datos de credenciales debe protegerse debidamente para permitir el control y auditoría de todo acceso. Por ejemplo, la cadena de conexión no debe proporcionar el nombre de usuario y contraseña utilizados para conectarse a la base de datos y, por tanto, debe cifrarse en caso de que los contenga. Las contraseñas de usuario no deben almacenarse como texto sin cifrar; en su lugar, deben almacenarse utilizando un algoritmo salt y una función hash unidireccional. El almacén de datos debe protegerse de modo que un usuario normal no pueda obtener acceso directo a los datos contenidos en él. Esto se puede hacer, por ejemplo, mediante el uso de diferentes funciones de servidor de base de datos para el acceso a los datos de credenciales y a otra información no confidencial.

Aplicar reglas de complejidad de contraseñas

El proveedor de pertenencia que utilizan los controles CreateUserWizard y Login determina los requisitos de complejidad de contraseñas. Por ejemplo, de forma predeterminada, el proveedor de pertenencia de SQL Server requiere contraseñas de una longitud mínima de 7 caracteres que incluya al menos 1 carácter no alfanumérico.

Para configurar contraseñas seguras exigidas por el proveedor

Para configurar las reglas de complejidad de contraseñas específicas de su proveedor, puede definir los atributos adicionales siguientes:

  • passwordStrengthRegularExpression: el valor predeterminado es ".

  • minRequiredPasswordLength: el valor predeterminado es 7.

  • minRequiredNonalphanumericCharacters: el valor predeterminado es 1.

    Nota

    Estos valores predeterminados corresponden a los proveedores de pertenencia a SQL Server y Active Directory

La configuración siguiente constituye un ejemplo de configuración del proveedor de pertenencia a SQL Server que incluye una expresión regular personalizada para restringir las contraseñas utilizadas por el proveedor de pertenencia.

<membership defaultProvider="MySqlMembershipProvider">
  <providers>
    <add name="MySqlMembershipProvider" 
         connectionStringName="MyLocalSQLServer" 
         applicationName="MyAppName"
         passwordStrengthRegularExpression=
                    "^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$" 
         type="System.Web.Security.SqlMembershipProvider, System.Web, 
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
  </providers>
</membership>

La expresión regular incluida en el ejemplo de código anterior limita la contraseña a 8-10 caracteres. Además, debe contener una combinación de caracteres en mayúscula y minúscula y caracteres numéricos, sin caracteres especiales. (.*\d) se refiere a caracteres numéricos, (.*[a-z]) a minúsculas y *[A-Z|] a mayúsculas, y {8,10} limita la longitud a 8-10 caracteres.

Para obtener más información sobre expresiones regulares, consulte How To: Use Regular Expressions to Constrain Input in ASP.NET (en inglés).

Tenga en cuenta que los proveedores de SQL Server y Active Directory siempre evalúan la contraseña en función de los atributos minRequiredPasswordLength y minRequiredNonalphanumericCharacters en primer lugar. Si desea que la expresión regular tenga prioridad, debe establecer los otros dos atributos en valores menos estrictos, por ejemplo, una longitud mínima de 1 y 0 caracteres no alfanuméricos.

La configuración siguiente utiliza los atributos minRequiredPasswordLength y minRequiredNonalphanumericCharacters para restringir la contraseña.

<membership defaultProvider="MySqlMembershipProvider">
  <providers>
    <add name="MySqlMembershipProvider" 
         connectionStringName="MyLocalSQLServer" 
         applicationName="MyAppName"
         minRequiredPasswordLength="8"
         minRequiredNonalphanumericCharacters="2"
         type="System.Web.Security.SqlMembershipProvider, System.Web, 
		 Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
  </providers>
</membership>

Validación de contraseñas seguras

También puede utilizar una expresión regular con el control CreateUserWizard para aplicar reglas de complejidad de contraseñas. De este modo, aprovecha las ventajas de la validación tanto de cliente como de servidor.

Para validar una contraseña especificada a través del control CreateUserWizard, defina la propiedad PasswordRegularExpression como una expresión regular apropiada como la que se muestra a continuación.

^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$

Adoptar un método eficaz de validación de datos

Es posible utilizar secuencias de comandos en sitios cruzados e inyección SQL para suplantar la identidad de un usuario legítimo en el sistema obteniendo el vale de autenticación o las credenciales reales. Por este motivo, es importante adoptar un método estricto de validación de datos para reducir al máximo estas vulnerabilidades.

Asegúrese de que el atributo ValidateRequest está establecido en true, tal y como se muestra en el ejemplo de código siguiente, para evitar los ataques mediante secuencias de comandos en sitios cruzados.

<%@ Page language="c#" Codebehind="LoginForm.aspx.cs" 
    ValidateRequest="true"  ... %>

De forma similar, asegúrese de que las cookies de autenticación de formularios estén marcadas como HttpOnly para impedir el acceso a ellas mediante secuencias de comandos del cliente. Esto no sustituye a la validación de los datos pero contribuye a implementar una estrategia eficaz de defensa exhaustiva. Asimismo, desactive los comandos HTTP no utilizados, como los verbos TRACE y OPTIONS.

Evite el uso de consultas SQL dinámicas creadas a partir de la concatenación de cadenas de datos de entrada. En su lugar, utilice procedimientos almacenados y la sustitución de parámetros para mitigar el riesgo de inyección SQL.

Para obtener más información sobre cómo impedir ataques de inyección, consulte Cómo: Proteger ASP.NET de los ataques de inyección.

Utilizar nombres y rutas de acceso exclusivos para las cookies

Utilice valores exclusivos para los atributos name y path del elemento <forms>, tal y como se muestra a continuación.

<forms name="YourAppName"
       path="/FormsAuth" ... />

Si asigna valores exclusivos a los atributos name y path, evita posibles problemas derivados del alojamiento de diversas aplicaciones en el mismo servidor. Por ejemplo, si no utiliza nombres exclusivos, un usuario autenticado en una aplicación puede realizar una solicitud a otra aplicación sin que el sistema le remita a la página de inicio de sesión de esa otra aplicación. Si utiliza particiones y rutas de acceso específicas, puede evitar que el vale de autenticación se transmita en los casos en que no sea necesario y, por tanto, reducir la ventana de ataque.

Normalmente, las sesiones que no utilizan cookies implican un mayor riesgo ya que no es posible proteger de forma nativa el vale de autenticación mediante mecanismos como requireSSL y HttpOnly, descritos anteriormente. Por lo tanto, se recomienda utilizar siempre cookies para el vale de autenticación, en lugar de utilizar la cadena de consulta.

Guardar las cookies de autenticación y de personalización en ubicaciones diferentes

Guarde las cookies de personalización, que contienen preferencias específicas del usuario e información no confidencial, en una ubicación diferente a la de las cookies de autenticación. Una cookie de personalización robada no constituye una amenaza de seguridad; sin embargo, un intruso puede utilizar una cookie de autenticación robada para obtener acceso a la aplicación.

Utilizar direcciones URL absolutas para la exploración

La exploración entre las áreas públicas y restringidas de su sitio (es decir, entre páginas HTTP y HTTPS) plantea un problema ya que el redireccionamiento siempre utiliza el protocolo (HTTPS o HTTP) de la página actual, no el de la página de destino.

Una vez que un usuario inicia la sesión y visita las páginas de un directorio protegido mediante SSL, el uso de los vínculos relativos como "..\publicpage.aspx" o los redireccionamientos a páginas HTTP tiene como resultado que las páginas se presenten utilizando el protocolo HTTPS, que requiere una sobrecarga de rendimiento innecesaria. Para evitar esto, utilice vínculos absolutos como "http://nombreservidor/nombreaplicación/publicpage.aspx" para el redireccionamiento de una página HTTPS a una página HTTP.

De forma similar, para el redireccionamiento a una página protegida (por ejemplo, la página de inicio de sesión) desde un área pública del sitio, debe utilizar una ruta HTTPS absoluta, como "https://nombreservidor/nombreaplicación/secure/login.aspx", en lugar de una ruta relativa como, "restricted/login.aspx". Por ejemplo, si la página Web utiliza un botón de inicio de sesión, utilice el código siguiente para redirigir a la página de inicio de sesión protegida.

private void btnLogon_Click( object sender, System.EventArgs e )
{
  // Form an absolute path using the server name and v-dir name
  string serverName = 
         HttpUtility.UrlEncode(Request.ServerVariables["SERVER_NAME"]);
  string vdirName = Request.ApplicationPath;
  Response.Redirect("https://" + serverName + vdirName + 
                    "/Restricted/Login.aspx");
}

Recursos adicionales

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: