Si disponemos de un servicio Web en nuestro servidor que está destinado a ser utilizado por nuestras aplicaciones pero no queremos facilitar que otros programadores le puedan sacar partido: ¿para qué queremos dejar publicado su archivo de descripción WSDL? El WSDL (Web Services Description Language) describe cómo es un servicio Web: qué tipos usa, qué métodos expone, etc… y es lo que usan Visual Studio y otras herramientas para crear un proxy que nos permita usar un determinado servicio. Se puede visualizar para cualquier servicio de .NET añadiendo ?wsdl al final de su URL, por ejemplo: http://www.miservidor.com/Servicios/miServicio.asmx?wsdl Cuando añadimos una nueva referencia Web a nuestro proyecto, en el diálogo que aparece podemos inspeccionar el servicio gracias a su descripción WSDL: Sin ese WSDL no podríamos inspeccionarlo ni tampoco añadir la clase proxy correspondiente. Un proxy es una serie de clases .NET que actúan de intermediarias entre nuestro código y el servi... [Más]

Esta es una cuestión bastante habitual y es que es muy útil, siendo administrador de una aplicación, poder entrar como cualquier otro usuario para ver lo mismo que éste ve y poder hacer cosas en su nombre. Sobre todo a la hora de dar soporte técnico, poder atender mejor a los usuarios, ayudarles o detectar posibles problemas en sus cuentas. La idea es la de poder entrar haciéndonos pasar por otros usuarios, como si fuésemos ellos, pero sin conocer sus credenciales. El otro día un alumno de mi curso de Desarrollo Web con ASP.NET me preguntó  precisamente esto, por lo que me he decidido a grabar un vídeo práctico explicando como hacerlo. Como verás es muy fácil, pero interesante. Dejo el vídeo a continuación y te recomiendo que, antes, te leas este post que escribí hace tiempo sobre el funcionamiento de las cookies de autenticación. ¡Espero que te resulte &... [Más]

Entre los Web Clips para mostrar en la barra superior de GMail, tengo añadidas las noticias de Baquia.com. Me parece una publicación on-line muy interesante y me acabé de aficionar definitivamente a ellos cuando tuve oportunidad de conocerlos en persona hace unos meses, que estuve en sus oficinas para entrevistarme para su televisión. Mparecieron muy profesionales y las noticias y artículos resultan casi siempre de interés. Hace un rato, leyendo mi cuenta de GMail, me he fijado en una cosa que por poco se me pasa inadvertida y es que una de las noticias de la barra de Web Clips era de Baquia pero se veía "rara": Bufff, parece un hacking clarísimo. Si pulsas en el enlace te lleva a una página que no existe ya: O sea, que los amigos de Baquia han andado rápidos por fortuna. Pero por rápido que seas, Google estos días parece que lo es mucho más: http://www.google.es/search?hl=es&source=hp&q=ozzmadark+site%3Abaquia.com si bien parece que, en e... [Más]

Por si alguno no estaba convencido aún de la importancia de escribir código pensando en la seguridad que se lea este artículo sobr eel último fallo de seguridad de Internet Explorer: http://blogs.msdn.com/sdl/archive/2009/07/28/atl-ms09-035-and-the-sdl.aspx Y si el tema te interesa de verdad: ya sabes.   Foto por Gui Tavares, Flickr

Ya he hablado en otras ocasiones de aplicaciones Web de gran impacto y que están rematadamente mal hechas y sin pensar en el usuario. Ésta vez me toca hablar de la Oficina Virtual de Correos.es, el operador nacional de correo en España. Hace unos días tuve que enviar un Burofax y me dije: "Ya que esta gente tiene una oficina on-line que incluso ha llevado premios, vamos a hacerlo directamente por Internet, que será coser y cantar". ¡Qué error cometí!. El problema más grave fue sin duda el que se refiere a los pagos on-line. Resulta que estableces los parámetros del servicio que quieres utilizar y cuando ya lo tienes en el carrito de la compra te da la opción depagarlo on-line inmediatamente. Para ello debes introducir el número de tu tarjeta de crédito y, en teoría, se procesa el pago y el servicio queda listo para ser gestionado or un atento funcionario (perdón, ahora desde que no son monopolio del Estado son "personal laboral fijo",aunque algún funcionario queda). El problema es qu... [Más]

En los  últimos posts he estado hablando sobre la seguridad de ASP.NET basada en Forms. Esto ha traído algunas preguntas por parte de los visitantes. Una de ellas, bastante común, es la de cómo almacenar información adicional atada a los usuarios que hemos autenticado.La API de Membership que viene con ASP.NET, y en concreto el proveedor de Membership para trabajo contra SQL Server (SqlMembershipProvider) nos provee de los medios suficientes para almacenar la información básica sobre los usuarios, esto es, el nombre, su login y su clave, que es lo mínimo necesario para trabajar. En este gráfico puedes ver la estructura completa creada por ASP.NET (más bien por aspnet_regsql.exe) en nuestra base de datos para dar soporte a SqlMembershipProvider y relacionados.Obviamente casi siempre necesitaremos almacenar mucha más información sobre ellos, relacionándola de manera directa y sencilla para poder extraerla. Así, por ejemplo, podemos necesitar almacenar sus datos de contacto, infromac... [Más]

En mi anterior post hablaba sobre el funcionamiento de las cookies en los navegadores y de cómo podíamos usar una extensión estándar (HttpOnly) para intentar impedir que las cookies sean accesibles desde el lado cliente y sólo se puedan manejar desde el servidor. No obstante se trata de una medida que, de funcionar, complica un poco a los posibles piratas, pero no es una verdadera barrera de seguridad. Para empezar ni siquiera está soportada por todos los navegadores. Las cookies residen en el disco duro del usuario por lo que son fáciles de manipular por cualquiera. Además se envían al servidor en cada petición, por lo que cualquiera con un proxy estilo Fiddler puede leerlas y manipularlas antes de enviarlas al servidor. Es decir, las cookies son elementos realmente inseguros. A raíz de estas disquisiciones alguien me escribió preguntándome por la seguridad de la autenticación Forms de ASP.NET (la más habitual). Ésta se basa precisamente en la existencia de una cookie que identific... [Más]

Una de las técnicas de hacking de páginas web más conocidas es la de Cross-Site-Scripting o XSS. Mediante esta técnica, las aplicaciones Web vulnerables pueden ser atacadas para multitud de propósitos: servir de zombies para atacar a otras Webs inundándolas con peticiones, ejecutar código en zonas de seguridad menos restrictivas (como la local) o, sobre todo, robar la identidad de los usuarios del sitio vulnerable. Ha sido utilizado tradicionalmente en combinación con correos electrónicos maliciosos para entrar en sitios Web protegidos suplantando la identidad de usuarios autenticados. En mi curso de Desarrollo de aplicaciones seguras y seguridad de .NET monto un ejemplo completo de cómo utilizarlo en un supuesto sitio de banca electrónica (muy mal hecha y vulnerable), para robar la sesión del usuario y entrar en su cuenta. Este robo de sesiones se basa en la obtención mediante XSS de la cookie de sesión de un usuario, enviándola a un servidor bajo el control del atacante. Éste al rec... [Más]

Ya de regreso por España aprovecho para comentar un truquillo que he aprendido estos días sobre como configurar el cortafuegos para que admita FTP pasivo. Resulta que en una máquina instalamos un servidor FTP, el cual admite los modos de trabajo Activo y Pasivo. En el modo Activo los clientes se conectan al puerto 21 del servidor FTP usando un puerto cualquiera no privilegiado. Tras hacerlo el cliente se pone a escuchar peticiones a través del puerto inmediatamente superior al que ha usado para la conexión, recibiendo datos a través del puerto 20 del servidor  (es decir el 21 es un puerto para comandos y el 20 el puerto para datos). El problema de esto es que si el cliente se encuentra a su vez detrás de un cortafuegos la conexión no será posible y fallará. En el modo Pasivo todas las conexiones son del cliente al servidor, por lo que no hay problemas con los cortafuegos en el lado cliente, y es el modo más habitual de funcionar. Puedes econtrar todos los detalles en el ar... [Más]

Esta es de las cosas que me deja "flipado" leer. Y lo cierto es que no pasa sólo con Adobe sino con otras empresas muy conocidas. Si hubiese salido una noticia similar con Microsoft ya se habría liado. El caso es que la Shadow Server Foundation avisó el pasado día 19 de una vulnerabilidad en Acrobat Reader que permite la ejecución de código arbitrario en el equipo de los usuarios, dando algunos detalles más el día 21. Por lo visto no se trata de algo realmente nuevo. Ellos simplemente lo han hecho público destacando además que está siendo ampliamente aprovechado en Internet para realizar ataques a usuarios. Adobe reconoció el fallo sacando un artículo en su KB unas horas después. El parche afecta a todas las versiones de Acrobat Reader y en todas las plataformas. El caso es que Adobe ha dicho que no va a tener disponible ningún parche para este problema hasta por lo menos el 11 de marzo. Y eso para la versión 9 del producto. Para las otras tardará aún más, sin especificar cuando... [Más]