Seguridad
Noticias y notas sobre seguridad
El equipo de patterns & practices ha publicado la versión beta de su guía de seguridad en Servicios Web titulada:
Improving Web Services Security: Scenarios and Implementation Guidance for WCF
En la cual se muestra cómo mejorar la seguridad de WCF mediante escenarios, guías directivas, Preguntas & Respuestas, listados Como-Se-Hace, etc... La guía está relacionada con el proyecto de seguridad: WCF Security Guidance Project.
Mayor información y descarga de la guía en:
WCF Web Services Security Guide.
Microsoft SQL Server 2005 proporciona servicios Web XML de forma nativa utilizando los siguientes estándares abiertos: HTTP, SOAP y WSDL. Con los Servicios Web XML nativos de SQL Server 2005 se pueden enviar solicitudes de mensajes SOAP a una instancia de SQL Server 2005 por HTTP para que se ejecute lo siguiente:
- Instrucciones Transact-SQL por lotes, con o sin parámetros.
- Procedimientos almacenados, procedimientos almacenados extendidos y funciones con valores escalares definidas por el usuario.
Los Servicios Web XML nativos de SQL Server 2005 se adaptan mejor a escenarios con los siguientes requisitos:
- Su aplicación devuelve o consume datos XML.
- Su aplicación depende en gran medida de procedimientos almacenados para la lógica empresarial.
- Desea integrar una aplicación de servicio Web alojada en SQL Server con otras aplicaciones de servicios Web como parte de su solución empresarial para lograr objetivos SOA.
- Como un reemplazo de mejor rendimiento para una solución de capa intermedia que utiliza SQLXML, para implementar Servicios Web en el mismo servidor.
- Para crear y publicar un informe estático para un sitio Web de una intranet en el que el conjunto de características enriquecidas y la sobrecarga adicional de SQL Server 2005 Reporting Services (SSRS) pueden sobrepasar sus requisitos.
De forma similar, no se recomenda utilizar servicios Web XML nativos de SQL Server 2005 en los siguientes escenarios:
- Su aplicación se utiliza para insertar o recuperar datos de objetos binarios grandes (BLOB), como valores de binary image o text grandes.
- Su aplicación requiere el procesamiento de transacciones en tiempo real y tiempos de respuesta de misión crítica.
- Está utilizando SQL Server en combinación con otras aplicaciones de procesamiento intensivo, como aplicaciones TPC Benchmark C (TPC-C).
- Como sustituto del nivel intermedio (middle-tier) donde la arquitectura de la aplicación tiene unas demandas de lógica empresarial a gran escala que se acomodan mejor en componentes intermedios.
Prácticas recomendadas de seguridad.
Tenga en cuenta las siguientes prácticas recomendadas de seguridad cuando implemente Servicios Web XML nativos de SQL Server 2005:
- Utilice la autenticación Kerberos: Cuando utilice CREATE ENDPOINT, seleccione AUTHENTICATION=KERBEROS o AUTHENTICATION = INTEGRATED para permitir que se use la seguridad integrada de Windows en Kerberos como el tipo de autenticación utilizado en un Endpoint. Para obtener más información, vea Registrar nombres principales de servicio de Kerberos mediante Http.sys.
- Limite los permisos de conexión de extremo a grupos o usuarios específicos: Protéja los Endpoints estableciendo permisos de conexión de extremo utilizando instrucciones Transact-SQL, como GRANT CONNECT y ALTER ON ENDPOINT. No se recomienda otorgar acceso a la función public. En su lugar, se recomienda comprender totalmente el modelo de permisos para SQL Server para controlar el acceso al extremo razonablemente. Para obtener más información, vea GRANT (permisos de endpoint de Transact-SQL).
- Utilice SSL para intercambiar datos importantes: El protocolo SSL proporciona soporte para el cifrado y descifrado de datos en una interfaz de socket TCP/IP seguro. Para que los endpoints de SQL Server proporcionen cifrado SSL, primero debe configurar un certificado. Para obtener más información, vea Configurar certificados para su uso con SSL.
- Utilice SQL Server detrás de un firewall: Asegúrese de que, cuando configura endpoints, todos los puertos TCP que utilice para proporcionar acceso HTTP estén protegidos por un firewall. Para obtener más información, vea Consideraciones de seguridad para una instalación de SQL Server.
- Verifique si la cuenta de invitado de Windows está deshabilitada en el servidor: Para reducir el riesgo de ataques de superficie cuando se usan Endpoints, debe asegurarse de que la cuenta de invitado está deshabilitada en el servidor en el que se ejecuta SQL Server. Para obtener más información, vea el tema "Para deshabilitar o activar una cuenta de usuario local" en la ayuda de Windows.
- Controle y actualice el estado del extremo según sea necesario: Cuando cree un Endpoint utilizando CREATE ENDPOINT, el estado predeterminado es detenido (STOPPED) a menos que se inicie explícitamente especificando STATE = STARTED. Para controlar el estado de un Endpoint existente, utilice ALTER ENDPOINT para especificar STOPPED, STARTED o DISABLED. Para quitar un extremo, utilice DROP ENDPOINT.
- Utilice los valores predeterminados de Endpoint seguro siempre que sea posible: Cuando cree o modifique un Endpoint se aplicarán las siguientes opciones predeterminadas, a menos que lo establezca explícitamente de otra manera:
- BATCHES = DISABLED: Transact-SQL El modo batch se deshabilita para el extremo.
- LOGIN_TYPE = WINDOWS: Sólo se permite la autenticación de Windows para usuarios de extremos.
Utilice esas opciones predeterminadas siempre que sea posible.
Para obtener información acerca de la elección de un algoritmo de cifrado, vea Elegir un algoritmo de cifrado.
Para mayor información acerca de todo ésto consulte:
SQL Server 2005: Prácticas recomendadas para utilizar servicios Web XML nativos.
Billy Hoffman dio una charla sobre seguridad AJAX “avanzada” en la pasada conferencia de Google Web Toolkit. Hoffman gestiona los Laboratorios de Seguridad de HP, que fuera SPIDynamics hasta que HP la comprara este año. Él se centra en el descubrimiento automatizado de las vulnerabilidades de aplicaciones Web y las tecnologías de Web Crawling. Su investigación incluye áreas tales como web sampling, el análisis estático de JavaScript, y cross-site scripting (XSS). Sin embargo, menciona que XSS no es necesario para el hacking AJAX; hay varias frutas más bajas que cuelgan.
En su charla, Hoffman mostró avanzados ataques contra aplicaciones AJAX, incluyendo la manipulación de la lógica del lado cliente, derrotando técnicas de protección de lógica, hijacking de funciones, hijacking de JSON (JavaScript Object Notation), hijacking y ataques de denegación de servicio (DOS). Discutió la susceptibilidad de las aplicaciones GWT a éste tipo de ataques y comparó las características de seguridad de GWT a la de otros frameworks AJAX, tales como Prototype y Dojo. Terminó hablando acerca del hacking a Google Gears, una extensión del navegador de código abierto que permite a los desarrolladores crear aplicaciones Web que se pueden ejecutar fuera de línea.
En general, Hoffman dice que si se quieren aplicaciones AJAX seguras se tienen que hacer seis cosas:
- Realizar verificaciones de autenticación/autorización tanto en las páginas Web como en los Servicios Web
- Agrupar las bibliotecas de código por función
- Validar todas las entradas de la aplicación, incluidas las cabeceras HTTP, cookies, cadenas de consulta y datos POST
- Verificar el tipo, la longitud y el formato de los datos
- Siempre utilizar consultas parametrizadas
- Siempre codificar (encode) apropiadamente la salida
De hecho nada nuevo, las prácticas de siempre, pero mas sin embargo muchos no las conocen y/o no las siguen…
Leer la nota completa en: Advanced AJAX Security.
El equipo de Seguridad del CLR del Microsoft .NET Framework ha anunciado que existen ciertas inconsistencias en los resultados de las implementaciones de los algoritmos HMAC-SHA-512 y HMAC-SHA-384 con respecto a los resultados de otras implementaciones. Por este motivo se recomienda no utilizar los mismos mientras no salga el próximo Service Pack para el .NET Framework 2.0.
Para evitar problemas de compatibilidad (una vez liberado el SP1) con el código que esté utilizando alguno de los mencionados algoritmos “sin parchar”, han dispuesto una serie de medidas tales como una propiedad y claves en archivos de configuración para indicar que “versión” del algoritmo deberá emplear.
Mayor información en: Please do not use the .NET 2.0 HMACSHA512 and HMACSHA384 Classes.
Ante una pregunta de Ambrosio recordé una serie de cuatro Webcast que presencié el pasado 8 de Junio. Dado que en su momento no pude comentar al respecto lo hago ahora, toda vez que aún se pueden ver los Webcast "bajo demanda". Los Webcast abordan el tema de los Application Blocks, que son bloques de código reutilizable generados por el equipo de patterns & practices de Microsoft. En dicha serie se analizaron los bloques de código del Enterprise Library 2.0 y los bloques para Smart Client.
Enterprise Library 2.0: Bloques de Código de Caching & Acceso a Datos
El Bloque de Código de Caching provee un mecanismo flexible y extensible para el manejo de caché en tus aplicaciones, que puedes utilizar tanto del lado del cliente como del lado del servidor. El Bloque de Código de Acceso a Datos es un componente que reduce la cantidad de código que necesitas para crear, probar y mantener la capa de acceso de datos en aplicaciones .NET.
