Este documento describe varios aspectos de la seguridad en aplicaciones web ASP.NET, incluyendo autenticación, autorización, amenazas comunes como suplantación y manipulación, y ejemplos de cómo implementar la autenticación mediante formularios almacenando credenciales en el archivo web.config.

1. UNIVERSIDAD GERARDO BARRIOS
SAN MIGUEL
INTEGRANTES:
GERARDO STEVEN MEJIA PERDOMO
RENE ALFREDO ARGUETA ARGUETA
JOSE ALFREDO JOYA CASTRO
RAUL ENRIQUE HERNANDEZ
QUINTEROS
MANUEL ALEJANDRO RAMIREZ
CARIAS
DOCENTE:
ING. GISELA ESPINOZA
CARRERA:
ING EN SISTEMAS
CICLO:
02-2016

2. INTRODUCCION
Eltema de la creación de una aplicación Web segura esmuy amplio ya que requiere realizar un estudio para comprender
los puntos vulnerables de la seguridad. También es necesario familiarizarse con las posibilidades de seguridad que
ofrecen Windows, .NET Framework y ASP.NET. Finalmente, resulta vital entender cómo utilizar estas funciones de
seguridad para contrarrestar las amenazas.
Es decir, lo que nosotros necesitamos como programadores no podemos entregar una aplicación o una página web sin
seguridad, pero a que nos referimos cuando hablamos de seguridad hablamos técnicamente sobre los ataques que pueda
sufrir nuestra maquina por otros programadores conocidos como hackers o incluyendo un bug donde cualquier persona
se podría aprovechar de ese fallo del sistema como y que podríamos hacerpara evitar todo esto.
Acontinuación, mostraremos que podrimos aplicar para fortalecer esasvulnerabilidades de nuestras futuras aplicaciones
o sitios webs.

3. Seguridad en ASP.NET
La seguridad de los sitios Web es una cuestión de importancia fundamental, además de compleja, para los
desarrolladores de sitios Web.La protección de un sitio requiere la elaboración cuidadosa de un plan; porconsiguiente,
los programadores y administradores de sitios Web deben comprender perfectamente las opciones para proteger los
sitios.
ASP.NET funciona junto con Microsoft .NET Framework y Servicios de Microsoft Internet Information Server (IIS)
para ayudara proporcionaraplicaciones Web seguras.Para ayudara protegerla seguridad de una aplicación ASP.NET,
se deben llevar a cabo las dos funciones principales
 Autenticación:
Ayuda a comprobar que el usuario es precisamente quien dice ser. La aplicación obtiene las
credenciales (diversas formas de identificación, como nombre y contraseña) de un usuario, y las
valida consultando a una autoridad determinada.
 Autorización:
Limita los derechos de acceso mediante la concesión o negación de permisos específicos a una
identidad autenticada.
Arquitectura de seguridad de ASP.NET
Como se muestra en la ilustración, todos los clientes Web se comunican con las aplicaciones ASP.NET a través de
Microsoft Internet Information Services (IIS). IIS autentica la solicitud si fuera necesario y, a continuación, busca el
recurso solicitado (como una aplicación ASP.NET). Si el cliente está autorizado, el recurso estará disponible.
Cuando se está ejecutando una aplicación ASP.NET, puede utilizar las características de seguridad de ASP.NET
integradas. Además, una aplicación ASP.NET puede utilizar las características de seguridad de .NET Framework.

4. Modelo de amenazas
Una fase importante en el proceso de programación de aplicaciones más seguras consiste en sercapaz de anticipar
las amenazas que se puede sufrir. En las secciones siguientes se describen brevemente estas amenazas y cómo
afectan a las aplicaciones Web.
Suplantación
Suplantar (spoof) es utilizar los datos de identificación de otro usuario o proceso de forma no autorizada. En su
versión más simple, la suplantación consistiría en introducir las credenciales de un usuario diferente. Un usuario
malintencionado podría también cambiar el contenido de una cookie para fingir que es otra persona o que la cookie
proviene de un servidor diferente.
En general, es posible contribuir a evitar la suplantación mediante una autenticación estricta. Siempre que alguien
solicita acceso a información privada, es preciso asegurarse de que es quien dice ser.
Manipulación
Manipular significa cambiar o eliminar un recurso sin autorización. El ejemplo típico consiste en desfigurar una
página Web, para lo cual, el usuario malintencionado logra acceso al sitio y cambia algunos archivos. Un modo
indirecto de manipulación son los ataques mediante secuencias de comandos. Un usuario malintencionado consigue
que se ejecute código (secuencia de comandos) enmascarándolo como la entrada de datos de un usuario en una
página o como un vínculo.
Una defensa fundamental contra la manipulación consiste en usar la seguridad de Windows para bloquear los
archivos, directorios y otros recursos de Windows
Repudio
Una amenaza de repudio implica llevar a cabo una transacción de manera que no haya pruebas fehacientes de los
actores principales de la transacción.En una aplicación Web, esto puede significar que se está suplantando a un
usuario inocente usando sus credenciales.Contribuir a la protección contra el repudio es posible, de nuevo,
aplicando una autenticación estricta.
Revelación de información
Revelación de información significa simplemente robar o desvelar información que se supone que es confidencial.
Un ejemplo típico es el robo de contraseñas,pero la revelación de información también incluye el acceso a cualquier
archivo o recurso del servidor.
La mejor protección contra la revelación de información es no tener información que revelar. Por ejemplo, si se
evita el almacenamiento de contraseñas,ningún usuario malintencionado podrá robarlas.
Denegación de servicio
Un ataque de denegación de servicio consiste en hacer deliberadamente que una aplicación esté menos disponible de
lo que debería. Un ejemplo típico es sobrecargar una aplicación Web de forma que no pueda servir a los usuarios
normales. Como alternativa, los usuarios malintencionados pueden intentar simplemente bloquear el servidor.
Concesión de privilegio
Un ataque de concesión de privilegio consiste en usarmedios malintencionados para obtenermás permisos de los
asignados normalmente. Por ejemplo, en un ataque de concesión de privilegio que tenga éxito, un usuario
malintencionado consigue obtenerprivilegios administrativos para el servidor Web,lo que le proporciona acceso a
todos los datos del servidor, así como el control de las funciones de éste.

5. Flujo de datos de seguridad en ASP.NET
Existen varias maneras de diseñar la seguridad en las aplicaciones ASP.NET. En este tema se describe el flujo de
datos de seguridad en dos escenarios comunes: la suplantación y la autenticación de formularios mediante cookies.
Escenario 1: suplantación
El escenario de suplantación se basa en la autenticación de Servicios de Microsoft Internet Information Server (IIS)
y en la seguridad de acceso a archivos de Microsoft Windows para minimizar la programación de la seguridad en la
propia aplicación ASP.NET. El flujo de datos se muestra en la ilustración siguiente.
Suplantación
En esta ilustración se muestra la siguiente secuencia de eventos:
1. Una solicitud de un cliente de red llega a IIS.
2. IIS autentica al cliente utilizando la seguridad básica, implícita o integrada de Windows (NTLM o
Kerberos).
3. Si se autentica al cliente, IIS pasa la solicitud autenticada a ASP.NET.
4. La aplicación ASP.NET suplanta al cliente que realiza la solicitud utilizando el símbolo (token) de acceso
pasado desde IIS, y se basa en los permisos de archivo NTFS para conceder acceso a los recursos.La
aplicación ASP.NET sólo necesita comprobar que la suplantación está establecida en true en el archivo de
configuración de ASP.NET; no se requiere ningún código de seguridad de ASP.NET.
Si la suplantación no está habilitada, la aplicación se ejecuta con la identidad de proceso de ASP.NET. En
Microsoft Windows 2000 Server y Windows XP Professional, la identidad predeterminada es una cuenta

6. local denominada ASPNET que se crea automáticamente al instalar ASP.NET. En Microsoft Windows
Server 2003, la identidad predeterminada es la del grupo de aplicaciones correspondiente a la aplicación IIS
(de manera predeterminada, la cuenta Servicio de red).
5. Si se concede el acceso,la aplicación ASP.NET devuelve el recurso solicitado a través de IIS.
Escenario 2 – Autenticación de formularios
En el escenario de autenticación de formularios, una aplicación obtiene las credenciales, como el nombre y la
contraseña,directamente del usuario y determina por sí misma su autenticidad. La aplicación no utiliza la
autenticación de IIS, pero la configuración de la autenticación de IIS puede afectar a la autenticación de formularios.
Como norma, cuando se utiliza la autenticación de formularios, se habilita el acces o anónimo en IIS. Por otra parte,
si los usuarios no pasan la autenticación de IIS, no pueden ponerse en contacto con la aplicación para proporcionar
un nombre de usuario y una contraseña para la autenticación de formularios.
El flujo de datos de este escenario se muestra en la ilustración siguiente.
En esta ilustración se muestra la siguiente secuencia de eventos:
1. Un usuario genera una solicitud de un recurso protegido.
2. IIS recibe la solicitud y, dado que el acceso anónimo de IIS está habilitado, IIS no realiza ninguna
autenticación del usuario y la solicitud se pasa a la aplicación ASP.NET.
3. Dado que el modo de autenticación de ASP.NET se ha establecido en formularios, la aplicación ASP.NET
examina la solicitud para obtenerun vale de autenticación de formularios (una cookie concreta). Si no hay

7. ningún vale de autenticación asociado a la solicitud, ASP.NET redirige la solicitud a la página de inicio de
sesión especificada en el archivo de configuración de la aplicación.
4. En la página de inicio de sesión,el usuario escribe las credenciales requeridas, normalmente un nombre y
una contraseña.El código de aplicación comprueba las credenciales para confirmar su autenticidad.Si se
autentican las credenciales, el código de aplicación asocia a la respuesta un vale de autenticación que
representa las credenciales del usuario. (No se incluye la contraseña.)Si se produce un error en la
autenticación, la respuesta se devuelve con un mensaje de acceso denegado o se vuelve a mostrar el
formulario de inicio de sesión.
El vale de autenticación emitido se incluirá en las solicitudes que se realicen a la aplicación ASP.NET con
posterioridad. ASP.NET examina la validez del vale mediante una comprobación de la autenticación de
mensajes (MAC).
5. Si se autentica al usuario, ASP.NET comprueba la autorización y puede conceder acceso al recurso
solicitado inicialmente, redirigir la solicitud a alguna otra página o redirigirla a un módulo de autorización
personalizado, donde se comprueba si las credenciales están autorizadas a tener acceso al recurso
protegido. Si se produce un error de autorización, ASP.NET redirige al usuario a la página de inicio de
sesión.
Si se autoriza al usuario, se concede el acceso al recurso protegido la aplicación puede requerir una prueba
adicional de las credenciales antes de autorizar el acceso al recurso protegido, dependiendo del diseño de la
aplicación.
Ejemplo
Almacenar credenciales en el archivo Webconfig
En este método toda la información del usuario se almacena en la parte <credentials> del archivo web.config que se
encuentra en el directorio raíz de la aplicación. Almacenar credenciales en el archivo Web.config es adecuado y
conveniente sólo para autenticación simple. No es adecuado si se permite a los usuarios crear y mantener sus propias
cuentas.En estos casos se debe almacenar el nombre de usuario y contraseña en una base de datos o un archivo
XML.
Se debe configurar el archivo de configuración Web.config de la siguiente manera y debe estar en el directorio raíz
de la aplicación (el directorio en el que reside default.aspx).
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".ASPXFormAuth" loginUrl="login.aspx" protection="All" timeout="15" path ="/">
<credentials passwordFormat="Clear">
<user name="Susam" password="Admin"/>
<user name="Michelle" password="User"/>
</credentials>
</forms>
</authentication>

8. <authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Si el usuario no está autenticado,se redirige al archivo login.aspx. Dicha página debe lucir como se muestra en la
Figura 1. El código de login.aspx es el siguiente.
private void Button1_Click(object sender, System.EventArgs e){
if (FormsAuthentication.Authenticate(Userid.Text, Passid.
Text)){
FormsAuthentication.RedirectFromLoginPage(Userid.Text,false);
}
else{
Passid.Text = "";
Label3.Text = "Usuario o contraseña incorrecto!";
}
}
Aquí, FormsAuthentication.Authenticate(Userid.Text, Passid.Text) devuelve un valor booleano true si las
credenciales son válidas y false si las credenciales no son válidas. Si devuelve true, se crea una cookie de
autenticación, se añade a la respuesta de salida, y se redirige la solicitud a la página solicitada inicialmente mediante
FormsAuthentication.RedirectFromLoginPage(Userid.Text,false). En este método el segundo parámetro
especifica si la autenticación debe ser una cookie de sesión (false) o una "cookie" (true).
El archivo default.aspxes el solicitado originalmente. En dicha página simplemente mostraremos un mensaje de
bienvenida, como se muestra en la Figura 2. Al emplear FormsAuthentication.SignOut(), s e
puede fácilmente eliminar o invalidar las cookies de autenticación.El código de default.aspx es el siguiente:
private void Page_Load(object sender,System.EventArgs e){
Label1.Text = "Le damos la bienvenida " + User.Identity.Name;
}
private void SignOut_Click(object sender,System.EventArgs e){
FormsAuthentication.SignOut();
Response.Redirect("login.aspx");
}