Tarea 5
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Tarea 5 as PDF for free.
More details
- Words: 808
- Pages: 4
GRUPO 70 Itziar Uranga Martín David Pablos González
Seguridad en aplicaciones web • ¿Qué es un identificador de sesión? El identificador de sesión es un número único que un servidor Web asigna a un usuario específico por la duración de la visita (sesión) de este usuario. http://www.gestiopolis.com/delta/term/TER366.html
• ¿Cuáles son las diferentes maneras por medio de las cuáles intercambian cliente y servidor el identificador de sesión? La identificación de la sesión se puede almacenar como un cookie, escribiéndola en campos ocultos o una URL (dirección Web) recogiéndolo con el método GET http://www.gestiopolis.com/delta/term/TER366.html
• ¿Qué ventajas e inconvenientes pueden tener asociados cada una de estas maneras desde la perspectiva de seguridad?
En una cookie: o Ventajas: El objeto SessionID se almacena, de forma predeterminada, en una cookie sin caducidad de la sesión, por lo tanto es lo mas cómodo. o Inconvenientes: Los valores de la propiedad P:System.Web.SessionState.HttpSessionState.SessionID se envían en texto no cifrado. Un origen no deseado podría obtener acceso a la sesión de otro usuario al obtener el valor de SessionID e incluirlo en las solicitudes que se envían al servidor. No podemos
estar seguros que todos los usuarios acepten cookies de sesión en sus navegadores.
En una variable pasada por parámetro en la URL: o Ventajas: Es más fiable que las cookies, porque pasar el identificador por la URL es posible siempre, independientemente del navegador cliente o su configuración. o Inconvenientes: Los valores de la propiedad P:System.Web.SessionState.HttpSessionState.SessionID se envían en texto no cifrado como parte de la dirección URL. Un origen no deseado podría obtener acceso a la sesión de otro usuario al obtener el valor de SessionID e incluirlo en las solicitudes que se envían al servidor.
http://support.microsoft.com http://msdn.microsoft.com/es-es/library/ms178582(VS.80).aspx
• ¿Quién y cómo genera los identificadores de sesión? ¿Qué forma/aspecto pueden tener? ¿Qué consecuencias puede tener esa forma sobre la seguridad de una aplicación web? Los identificadores de sesión son un número aleatorio de 120 bits representado por una cadena de 20 caracteres que se crea en el servidor. Como ejemplo tendríamos lit3py55t21z5v55vlm25s55. Ejemplo extraído de: http://msdn2.microsoft.com/eses/library/ms178582(VS.80).aspx Permite especificar que características tendrá cada tipo de usuario. Por ejemplo en nuestra aplicación si inicias sesión como usuario o como profesor tendrás una distinta interfaz y funcionalidades
• ¿Cuál es el ciclo de vida de una sesión? ¿Cómo, cuándo y por qué forzar la terminación/abandono de una sesión?
El ciclo de vida de una sesión dura hasta que el usuario termine la sesión o hasta que venza el plazo que se le da con session.timeout. Se puede forzar a abandonar una sesión por medio del sesión.abandon o tras acabar el plazo de tiempo que se le dé con el sesión.timeout. Esto se hace para evitar que un usuario distinto consiga los privilegios de una sesión abierta.
• ¿Para qué, cuándo y dónde se cifran las cookies? Las cookies pueden contener datos privados que no conviene que nadie sea capaz de ver (nombre de usuario, password, etc), sin embargo, al estar almacenadas en los ordenadores de los usuarios, podrían ser fácilmente accesibles por terceras personas. Por ello se cifran las cookies, para garantizar que la información no pueda ser leída aunque alguien acceda a la cookie en cuestión. La cookie se cifra al crearla, cuando introducimos los datos en el formulario de login. Para que esto se lleve a cabo así, debemos configurar el archivo web.config. Más concretamente, tendremos que centrarnos en la parte de authentication. La cookie se cifra en el servidor (donde se crea) usando el tipo de protección especificada en el web.config. Si se desea, pueden enviarse los datos del formulario al servidor por https, ya que en ese trayecto la información no está todavía cifrada. www.elguille.info
• ¿Para qué sirve https y en qué se diferencia de http? ¿De qué responsabilidad/tareas descarga al responsable de seguridad de una aplicación web el trabajar con https?
Hypertext Transfer Protocol Secure, más conocido por sus siglas HTTPS, es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP. El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado (cuyo nivel
de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no puede ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar HTTP. Es aquí, cuando nuestro navegador nos advertirá sobre la carga de elementos no seguros (HTTP), estando conectados a un entorno seguro (HTTPS). http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure
Seguridad en aplicaciones web • ¿Qué es un identificador de sesión? El identificador de sesión es un número único que un servidor Web asigna a un usuario específico por la duración de la visita (sesión) de este usuario. http://www.gestiopolis.com/delta/term/TER366.html
• ¿Cuáles son las diferentes maneras por medio de las cuáles intercambian cliente y servidor el identificador de sesión? La identificación de la sesión se puede almacenar como un cookie, escribiéndola en campos ocultos o una URL (dirección Web) recogiéndolo con el método GET http://www.gestiopolis.com/delta/term/TER366.html
• ¿Qué ventajas e inconvenientes pueden tener asociados cada una de estas maneras desde la perspectiva de seguridad?
En una cookie: o Ventajas: El objeto SessionID se almacena, de forma predeterminada, en una cookie sin caducidad de la sesión, por lo tanto es lo mas cómodo. o Inconvenientes: Los valores de la propiedad P:System.Web.SessionState.HttpSessionState.SessionID se envían en texto no cifrado. Un origen no deseado podría obtener acceso a la sesión de otro usuario al obtener el valor de SessionID e incluirlo en las solicitudes que se envían al servidor. No podemos
estar seguros que todos los usuarios acepten cookies de sesión en sus navegadores.
En una variable pasada por parámetro en la URL: o Ventajas: Es más fiable que las cookies, porque pasar el identificador por la URL es posible siempre, independientemente del navegador cliente o su configuración. o Inconvenientes: Los valores de la propiedad P:System.Web.SessionState.HttpSessionState.SessionID se envían en texto no cifrado como parte de la dirección URL. Un origen no deseado podría obtener acceso a la sesión de otro usuario al obtener el valor de SessionID e incluirlo en las solicitudes que se envían al servidor.
http://support.microsoft.com http://msdn.microsoft.com/es-es/library/ms178582(VS.80).aspx
• ¿Quién y cómo genera los identificadores de sesión? ¿Qué forma/aspecto pueden tener? ¿Qué consecuencias puede tener esa forma sobre la seguridad de una aplicación web? Los identificadores de sesión son un número aleatorio de 120 bits representado por una cadena de 20 caracteres que se crea en el servidor. Como ejemplo tendríamos lit3py55t21z5v55vlm25s55. Ejemplo extraído de: http://msdn2.microsoft.com/eses/library/ms178582(VS.80).aspx Permite especificar que características tendrá cada tipo de usuario. Por ejemplo en nuestra aplicación si inicias sesión como usuario o como profesor tendrás una distinta interfaz y funcionalidades
• ¿Cuál es el ciclo de vida de una sesión? ¿Cómo, cuándo y por qué forzar la terminación/abandono de una sesión?
El ciclo de vida de una sesión dura hasta que el usuario termine la sesión o hasta que venza el plazo que se le da con session.timeout. Se puede forzar a abandonar una sesión por medio del sesión.abandon o tras acabar el plazo de tiempo que se le dé con el sesión.timeout. Esto se hace para evitar que un usuario distinto consiga los privilegios de una sesión abierta.
• ¿Para qué, cuándo y dónde se cifran las cookies? Las cookies pueden contener datos privados que no conviene que nadie sea capaz de ver (nombre de usuario, password, etc), sin embargo, al estar almacenadas en los ordenadores de los usuarios, podrían ser fácilmente accesibles por terceras personas. Por ello se cifran las cookies, para garantizar que la información no pueda ser leída aunque alguien acceda a la cookie en cuestión. La cookie se cifra al crearla, cuando introducimos los datos en el formulario de login. Para que esto se lleve a cabo así, debemos configurar el archivo web.config. Más concretamente, tendremos que centrarnos en la parte de authentication. La cookie se cifra en el servidor (donde se crea) usando el tipo de protección especificada en el web.config. Si se desea, pueden enviarse los datos del formulario al servidor por https, ya que en ese trayecto la información no está todavía cifrada. www.elguille.info
• ¿Para qué sirve https y en qué se diferencia de http? ¿De qué responsabilidad/tareas descarga al responsable de seguridad de una aplicación web el trabajar con https?
Hypertext Transfer Protocol Secure, más conocido por sus siglas HTTPS, es un protocolo de red basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP. El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado (cuyo nivel
de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no puede ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar HTTP. Es aquí, cuando nuestro navegador nos advertirá sobre la carga de elementos no seguros (HTTP), estando conectados a un entorno seguro (HTTPS). http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure
