Trabajando con Datos en ASP.NET 2.0

Se han publicado una tonelada de artículos y tutoriales sobre trabajar con datos en ASP.NET 2.0. En este post destacamos algunos de ellos.

Serie de tutoriales sobre trabajo con datos en ASP.NET 2.0.

Scott Mitchell acaba de terminar de escribir su serie de  tutoriales sobre Trabajo con Datos en ASP.NET 2.0 para el sitio www.asp.net . Esta serie de tutoriales contiene más de 75 tutoriales sobre datos (y más de 750 páginas de contenido). Hay versiones disponibles tanto para VB como para C#, y podéis descargar los artículos en PDF. Si aún no los habéis leído, podéis hacerlo aquí.

Aquí tenéis la tabla de contenidos y los enlaces a los artículos publicados (en inglés):

Scott tiene 18 tutoriales más en la serie que serán publicados dentro de poco, y tratan sobre:

  • Caching. (4 tutoriales)
  • Datos y el Site Map Provider (1 tutorial)
  • Trabajando con Batched Data (incluyendo transacciones; 4 tutoriales).
  • Capas de acceso a datos avanzadas (9 tutoriales).

Podéis suscirbiros al RSS para enteraos de las actualizaciones cuando se publiquen estos tutoriales.

Usando los controles DataSource de ASP.NET 2.0

Además de publicar estos artículos en www.asp.net. Scott Mitchell también está escribiendo artículos geniales sobre datos y el uso de controles DataSource para el sitio www.4GuysFromRolla.com.

Si no habéis visitado www.4GuysFromRolla.com, os recomiendo que os paséis por allí. (tienen toneladas de contenidos buenos, y libres). También podéis subscribiros a su RSS de artículos aquí (si eres un desarrollador ASP.NET deberías hacerlo).

 Aquí tenéis un «puntero» a los artículos actuales sobre la serie de controles DataSource de ASP.NET 2.0 de la web 4GuysFromRolla:

Subsonic 2.0 Beta 3

Subsonic 2.0 Beta 3 está disponible para descarga. Subsonic es una genial herramienta (y libre) que os ayuda a crear rápidamente webs guiadas por datos (data driven web). Incluye un constructor DAL que nos permite crear colecciones fuertemente tipadas y un modelo de objetos para nuestros datos (lo construye en tiempo de compilación basándose en el esquema de nuestro website), así como una base muy rica para crear la interfaz de usuario (IU) sobre nuestros datos.

Jon Galloway tiene un pequeño resúmen de algunas de las nuevas características de Subsonic que podéis ver aquí.

Si vais a venir a las conferencias del MIX en dos semanas, aseguraos de saludar a Rob Conery, es el arquitecto jefe de Subsonic. También estará en un panel de Open Source junto a Miguel de Icaza (de Mono) y otros.

Buenas prácticas de NHibernate con ASP.NET, edición 1.2

Billy McCafferty ha actualizado su artículo «NHbiernate Best Practices with ASP.NET» este mes. Podéis leer la última versión aquí.

Este artículo cubre alguna de los temas principales en los que pensar cuando construyamos una capa de datos empresarial usando esta implementación para .NET de un ORM (totalmente libre). Echadle un vistazo al libro NHibernate in Action que será publicado en Julio.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos.

Trucos: Habilitar SSL en IIS 7.0 usando certificados firmados por nosotros

SSL permite que los navegadores se comuniquen con un servidor web sobre un canal seguro para evitar que nadie pueda «escuchar» la comunicación, interceptar y falsificar mensajes. Deberíamos usar SSL en las páginas de login donde los usuarios introducen sus nombres de usuario y contraseñas, así como en todas las web de un sitio que puedan ser «sensibles» (por ejemplo: páginas que muestren información financiera o personal).

Configurar SSL en Windows con versiones anteriores de IIS ha sido siempre un quebradero de cabeza. Hay que saber cómo instalar y administrar un certificado, y luego asociarlo a un sitio web, seguro que es algo que la mayoría de desarrolladores web no saben cómo habilitar.

Las buenas noticias son que IIS 7.0 hace radicalmente fácil configurar y habilitar SSL. IIS 7.0 además trae soporte de fábrica para crear nuestros propios certificados de forma sencilla para habilitar rápidamente un sitio web SSL para desarrollo o para test.

Con IIS 7.0 podemos habilitar un sitio web ya creado con SSL en tan sólo 30 segundos. El siguiente tutorial muestra cómo hacer eso.

Paso 1: Crear un nuevo sitio web.

Empezaremos creando un nuevo sitio web con la nueva herramienta de administración de IIS7.0. Esta herramienta de adminstración ha sido reescrita completamente a partir de la versión anterior (que fué escrita usando código manegado con Windows Forms), y provee una organización más lógica de características web. Da una experiencia de administración con una interfaz gráfica (GUI) para todas las configuraciones de ASP.NET e IIS:

SSLIISStep0

Para crear un nuevo sitio, clic con el botón derecho en el nodo «Web Sites» en el árbol del lado izquierdo y elegir la opción «Add Web Site» del menu contextual. Añadimos los detalles necesarios para crear el nuevo sitio web:

SSLIISStep1

Una gran característica de IIS7 en Windows Vista es que podemos tener un número ilimitado de sitios web en una caja (las versiones anteriores de IIS en clientes Windows sólo nos permitía un sitio). La limitacion de 10 peticiones simultaneas en las versiones de IIS para clientes Windows no existe ahora en IIS7.

Paso 2: Crear un certificado propio.

Antes de enlazar reglas SSL a nuestro sitio, necesitamos importar e instalar un certificado de seguridad para usarlo en el enlace SSL.

Los certificados se administran en IIS7 haciendo clic en el nodo root del árbol de la izquierda, y seleccionamos el icono «Server Certificates» en el lado derecho:

ssliisstep3

Esto nos mostrará una lista de todos los certificados registrados en la máquina, y nos permitirá importar y/o crear otros nuevos.

Opcionalmente, podemos irnos a una entidad emisora de certificados como Verisign y comprar un certificado para importarlo con esta herramienta de administración. O podermos crear nuestro propio certificado para que funcione como un certificado de prueba que podamos usar para el desarrollo y las pruebas en nuestro sitio. Para hacer esto, tenemos que hacer clic en el link «Create Self-Signed Certificate» en la parte derecha de la herramienta de administración:

ssliisstep4

Metemos el nombre para usar el certificado (por ejemplo: «test») y hacemos clic en ok. IIS7 creará automáticamente un nuevo certificado encriptado y lo registrará en la máquina:

Paso 3: Habilitar los enlaces HTTPS para nuestro nuevo sitio.

Para habilitar SSL en nuestro nuevo sitio web, seleccionamos el nodo del web side en el árbol de la izquierda, y hacemos clic en link «Bindings»del menú «actions» del lado derecho de la pantalla:

Esto nos mostrará un cuadro de dialogo que nos mostrará todas las reglas de enlace que dirigen el tráfico a este sitio (significando las combinaciones de cabeceras host/direcciones ip/puerto para el sitio):

Para habilitar SSL en el sitio, haremos clic en el boton «Add». Esto nos mostrará otro cuadro de dialogo  para añadir soporte para el protocolo HTTPS. Podemos seleccionar el certificado que hemos creado de la lista desplegable del diálogo, para indicar que queremos usar ese certificado cuando encriptemos contenido sobre SSL:

Hacemos clic en OK y ya tenemos habilitado SSL para nuestro sitio:

Paso 4: Probando nuestro sitio.

Añadimos una página «default.aspx» al sitio, e intentamos abrirla con el navegador escribiendo https://localhost/default.aspx (usamos «https» en lugar de «http» para indicar que queremos conectarnos a través de SSL).

Si usamos IE7, vereis el error de anti-phising:

No os alarméis si os pasa esto – tan sólo es el IE que nos advierte que un certificado creado por nosotros es sospechoso. Hacemos clic en el link «Continue to this website» para saltarnos este aviso de seguridad e ir al sitio. Encontraremos nuestra pagina default.aspx  corriendo sobre SSL:

Y ya está echo. 🙂

Apendice: Últimas notas sobre SSL.

  • La herramienta de administración de IIS7 tiene un nodo de configuración «SSL Settings» que podemos seleccionar para cada sitio, directorio o archivo que nos permite controlar cuándo, ese recurso particular (y por defecto a todos sus hijos), requiera peticiones SSL para ejecutarse. Esto es muy útil para páginas como login.aspx, cuando queremos garantizar que los usuarios metan sus credenciales cuando el canal esté encriptado. IIS 7 bloqueará a todos lo navegadores que intenten acceder a menos que lo hagan sobre SSL.
  • En una pagina ASP.NET, podemos saber programáticamente, cuándo la petición actual está usando SSL chequeando la propiedad Request.IsSecure (devolverá «true» si la petición viene por SSL).
  • Podemos poner el atributo «requireSSL» en la sección de configuración de <forms> en el web.config para tener el sistema de autentificación por formulario de ASP.NET y asegurarnos que las cookies sólo se usan en sitios con SSL. Esto evita el riesgo de que un hacker intercepte una cookie de autentificación en una página sin SSL, e intente usar el «ataque por repeticion» desde una máquina diferente para suplantar la identidad de un usuario.

 Para más información de IIS/, leeros mi anterior post sobre IIS7. También echadle un vistado a la web www.iis.net.

Para leer mas sobre mis post sobre trucos, visitad mi página sobre trucos

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos. Microsoft Student Partner.

Hijacking JSON y cómo previene ASP.NET AJAX 1.0 estos ataques.

Se han publicado algunos reportes de seguridad describiendo formas en las que los hackers podrían usar el formato de JSON usado por los frameworks de AJAX más populares para intentar lanzar ataques de cross site scripting. Concretamente, estos ataques usan peticiones HTTP GET invocados a través de HTML <script src=»» >para saltarse la política de «mismo origen» de los navegadores (que limita los objetos JavaScript como XmlHttpRequest llamando a urls en el mismo dominio desde donde fué cargada la pagina), y buscar formas para modificar el contenido de JSON.

ASP.NET AJAX 1.0 incluye un número de opciones y características activadas por defecto que le previenen de ser susceptible de este tipo de ataques JSON. Abajo tenéis algunos detalles sobre cómo se mitigan estos ataques:

Los métodos web (web methods) de ASP.NET AJAX no admiten llamadas HTTP GET por defecto.

Los archivos de script caragdos con elementos HTML <script src=»» > sólo pueden ser obtenidos con peticiones HTTP GET.

Por defecto, la capa de servicios web de ASP.NET AJAX no permite que los métodos web (web methods) sean invocados por peticiones HTTP GET. Por ejemplo, imaginemos que un desarrollador escribe un método de un servicio web como abajo:

<

p style=»background:#eeeeee;margin:0″ class=»MsoNormal»>[WebMethod]
public StockQuote[] GetQuotes(string symbol) {
}

ASP.NET sólo permitirá que el método GetQuotes sea llamado con HTTP POST, y rechazará todos los intentos que se hagan usando HTTP GET.

Para hacer que un web method ASP .NET AJAX sea llamable con un acceso HTTP GET, el desarrollador debe atribuir explícitamente cada método para que pueda ser llamado de esa forma. Usando el atributo ScriptMethod (y poniendo la propiedad UseHttpGet a true): 

[WebMethod]
[ScriptMethod(UseHttpGet
=true)]
public StockQuote[] GetQuotes(string symbol) {

Aunque esta modificación sea sencilla de hacer, requiere que el desarrollador habilite el servicio web para que funcione con el GET. Los servicios web ASP.NET AJAX nunca habilitarán eso por defecto, y la documentación de ASP.NET AJAX no recomienda que se habilite esta opción por una serie de razones .

Nota: El control «UpdatePanel» de ASP.NET AJAX,  como todos los controles que vienen con ASP.NET AJAX 1.0, no usan HTTP GET, sino que usan HTTP POST cuando hacen postbacks asíncronos.

Validación de cabeceras Content-Type en ASP.NET AJAX

Hay una capa de validación de proteccion que ASP.NET obliga para los web methods basados en ASP.NET AJAX para las peticiones GET y POST, por eso, aunque se usen llamadas HTTP, ASP.NET siempre requerirá que la cabecera HTTP Content-Type tenga el valor application/json. Si no se envía esta cabecera, ASP.NET AJAX rechazara la petición en el servidor.

Usando el web method escrito más arriba, una traza HTTP de una invocación GET de ASP.NET AJAX debe ser como esta:

GET /StockService/Stock.asmx/GetQuotes?symbol=%22msft%22 HTTP/1.1
Accept: /
Accept-Language: en-us,fr;q=0.5
Referer: http://xxxxxx/StockService/test.aspx
Content-Type: application/json; charset=utf-8
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2)
Host: xxxxxx
Proxy-Connection: Keep-Alive 

Aunque lo de arriba sea una petición GET, la pila JSON del cliente sigue insertando una cabecera HTTP Content-Type  que le dice al servidor que considere esa llamada como una petición a un servicio web AJAX. La pila de servicios web del servidor para ASP.NET AJAX 1.0 siempre chequean esta cabecera, y si no la encuentran rechazan la petición.

Si un desarrollador malicioso quiere hacer este tipo de ataque contra el servicio web, debería incluir un tag de script como el siguiente:

<script type=»text/javascript» srchttp://contoso.com/StockService/Stock.asmx/GetQuotes?symbol=msft« />   Sin embargo, los navegadores no pondrán el Content-Type con el valor application/json cuando parseen el elemento <script src=»» > y hagan la petición. Como resultado cuando ASP .NET reciba la petición hecha desde un <script />, no la reconocerán como una petición para un servicio web ASP.NET AJAX, y esto dará un error de declaración de ASP.NET que no reconocerá la url solicitada. Esto prevendrá los intentos de ataques de JSON (incluso cuando tengamos habilitado la opción GET en un servicio web).

Resumen

ASP.NET AJAX 1.0 por defecto sólo admite peticiones HTTP POST para invocar servicios web que usen JSON, lo que significa que no podemos permitir, sin darnos cuenta, que los navegadores invoquen servicios web con HTTP GET.

ASP.NET AJAX 1.0 requiere la cabecera Content-Type con el valor «application/json» para peticiones a servicios web AJAX con GET y POST. Las peticiones JSON que no contengan estas cabeceras serán rechazadas por el servidor ASP .NET. Esto significa que no podemos invocar servicios web ASP.NET AJAX con <script src=»»> ya que los navegadores no permiten añadir cabeceras content-type cuando solicitan un archivo de JavaScript como ese.

Espero que sirva,

Scott.

 Traducido por: Juan María Laó Ramos. Microsoft Student Partner.