¿Cómo funciona un navegador moderno?

Probablemente excesivamente técnico para la mayoría, pero nunca viene mal para futura referencia: How Browsers Work: Behind the scenes of modern web browsers.

Cross site requets forgery con Oauth2

En Cross Site
Request Forgery and OAuth2 algunas ideas sobre lo que puede ir mal
utilizando Oauth2 para proteger recursos en la web.

Conclusions
We’ve taken a look at some CSRF attacks on an OAuth2 system and some measures that can be taken to defend against them. The general conclusion is that there are plenty of opportunities to defeat such attacks, some of which come from the specification and come which do not. As with any security vulnerability, whether or not a system is well defended against CSRF depends on the details of the implementation as well as the quality of passwords and secrets. Even a system which meets the specification can be attacked, but there are some measures that can be taken by careful implementations to make those attacks unlikely to succeed.

Aplicaciones web, herramientas y seguridad

En [PDF] Exploring the Relationship Between Web Application. Development Tools and Security un documento interesante que trata justamente de eso: cómo las diversas herramientas disponibles para el desarrollo de una web afectan desde el punto de vista de seguridad.

Mediante una revisión manual del código y una herramienta de penetración automatizada comprobaron 9 implementaciones de la misma aplicación web realizada en tres lenguajes de programación diferentes:

Our findings are:
(1) we do not find a relationship between choice of programming language and application security,
(2) automatic framework protection mechanisms, such as for CSRF and session management, appear to be effective at precluding vulnerabilities, while manual protection mechanisms provide little value, and
(3) manual source code review is more effective than automated black-box testing, but testing is complementary.

Los lenguajes elegidos fueron Perl, PHP y Java.

El número mayor de fallos:

One of the Perl implementations has by far the most vulnerabilities, primarily due to its complete lack of XSS protection. This does not seem to be related to the fact that Perl is the language used, however, since the other two Perl implementations have only a handful of vulnerabilities, and few XSS vulnerabilities.

Que parece tener más bien que ver con la habilidad de los desarrolladores.

Sobre el tipo de fallos detectados:

Manual review is the clear winner for authentication and authorization bypass and stored XSS vulnerabilities, while black-box testing finds more reflected XSS and SQL injection vulnerabilities.

Naturalmente, es un estudio limitado y pequeñito (y a la vez grande, teniendo en cuenta la idea de 9 equipos desarrollando la aplicación) del que no se pueden sacar conclusiones estadísticas, pero aporta algo de luz al tema.

Sobre certificados digitales y seguridad

Me declaro fan de Una al día de Hispasec. En general no son ni excesivamente técnicos, ni tampoco tan ligeros que no te enteras de nada. En Conversaciones sobre certificados, seguridad y pornografía el tono es bastante didáctico y nos avisa de los problemas que existen con los certificados digitales, incluso para sitios muy importantes, y lo cuidadosos que deberíamos de ser cuando navegamos por la red.

Está claro que el sistema no es el más amigable del mundo, y no es de extrañar que la gente termine mirando hacia otro lado en estas cuestiones.

INTECO: sobre la seguridad de sitios web

Revisando el baúl de los recuerdos (esas lecturas que se quedan en el kindle pendientes de algo) rescato este informe del INTECO: [PDF] Seguridad en sitios web con consejos a tres niveles:

- Detección de los ataques
- Minimizar los daños producidos por un ataque
- Puesta en marcha de medidas preventivas para evitar que un sistema llegue a estar comprometido

Seguridad en aplicaciones de colaboración según Google

En [PDF] Security Whitepaper. Google Apps Messaging and Collaboration Products. Introduction un documento de Google con directrices generales, con su declaración inicial:

The security of online services is a topic of increasing interest to enterprises as the number of third party hosted service offerings has expanded in recent years. The emergence of various “cloud computing” concepts and definitions has highlighted not only questions about data ownership and protection, but also how various vendors of cloud computing technologies build and implement their services. Security experts, end-users and enterprises alike are all considering the security implications of the cloud computing model.

Y los consejos ya vistos tantas veces, pero que no se si están calando:

… the Google Security Team maintains an engineering outreach and education program that currently includes:
- Security training for new engineers.
- The creation and maintenance of extensive documentation on secure design and coding practices.

Entrenamiento sobre diseño seguro para los nuevos ingenieros.

¿Nuevo estándar para la gestión de estado en la web?

Después de hablar el otro día sobre si ¿Llegó el momento de arreglar HTTPs? nos encontrábamos con ‘HTTP State Management Mechanism’ to Proposed Standard donde se referencia al HTTP State Management Mechanism draft-ietf-httpstate-cookie-23 y que podría marcar el nuevo mecanismo de gestión de Cookies para la web. Debería arreglar (si se aprueba) algunos de los defectos que se comentaban en Sobre las cookies.
Como es natural, es bastante técnico y no aporta mucho a nivel de ideas
generales pero, al menos pondrá un poco de orden en la gestión de este
mecanismo:

This spec is a milestone in that HTTP “cookie” syntax and behavior has been effectively a matter of undocumented folklore all these years. Getting this finally explicitly documented will be a key underlying piece of moving “the Web”, and the wider Internet its built upon, on towards its next stage(s).

5 decisiones de diseño que afectan a la seguridad de aplicaciones web

En 5 Key Design Decisions That Affect Security in Web Applications algunos puntos para tener en cuenta. Ya he dicho en vidas anteriores que a mi las listas me asustan mucho (sobre todo por lo que puedan dejarse; también porque fijan la atención en unas cosas y, por lo tanto, la alejan de otras) pero estoy seguro de que algunos aprenderán cosas con esta y otros las recordarán:

• Replicación de sesiones
• Contexto de autorización
• Etiquetas vs código en las vistas
• Elección del entorno de desarrollo
• Registro y monitorización

PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP?

Ya hablamos hace algún tiempo de Polución de parámetros del protocolo HTTP. Sus autores han seguido trabajando en el tema y ahora presentan un servicio para comprobar si somos vulnerables: HTTP Parameter Pollution. So how many flawed applications exist out there?! We go online with a new service.

El servicio está en PAPAS: PArameter Pollution Analysis System (Beta) y hay un artículo que lo explica en [PDF] Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications.

Sobre las cookies

En HTTP cookies, or how not to design protocols un repaso histórico de la evolución de las especificaciones relativas a las cookies, ese mecanismo que utilizan los navegadores para que sea posible desarrollar aplicaciones web al añadir al protocolo HTTP la posibilidad de gestionar el estado, y por lo tanto relacionar entre sí varias peticiones consecutivas de páginas web.

Se centra en los problemas que las diferentes versiones de la especificación han podido causar.