¿Qué son los tokens anti-CSRF?

La primera vez que leímos sobre estos temas fue en un documento que todavía tiene bastante vigencia, HTML Code Injection and Cross-site scripting junto con Web Based Session Management. Best practices in managing HTTP-based client sessions.

Entonces sonaban como medidas bastate extremas (y que había que implementar prácticamente a mano). Aunque seguimos viendo sitios que no utilizan este tipo de medidas, las cosas han cambiado un poco y los lenguajes y diversos proyectos proporcionan herramientas para gestionarlo de manera más o menos sencilla. Y sigue siendo necesario explicar estas cosas, claro. Por ejemplo, en What Are Anti Cross-site Request Forgery Tokens And What Are They Good For? lo explicaban con ejemplos para .Net.

Ya hemos hablado unas cuantas veces sobre CSRF aquí.

Una introducción a la seguridad web

En [PDF] Website Security 101. Real-World Examples, Tools & Techniques for Protecting & Securing Websites. un documento introductorio de los que nos vienen tan bien para los que empiezan y también de recordatorio para los demás.

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.

La inseguridad en el uso de los protocolos seguros

Internet está lleno de datos esperando a que los busquemos y les demos sentido (también los malos, claro). En Companies Using Secure Protocols in an Insecure Manner podemos leer sobre un sondeo basado en preguntar directamente a los servidores (en lugar de a los responsables de la empresa).

First step, I found companies listed in this year’s Fortune 500. This was pretty straightforward; I entered something like “Fortune 500” in Google and found they are listed on: http://money.cnn.com/magazines/fortune/global500/2011/full_list/index.html.

Then I had to find these companies primary website, and that wasn’t too hard either. At the url mentioned above, you just click a company’s name in the index and the company’s website is mentioned on the next page. This way I discovered the 500 websites for all companies listed in this years Fortune 500.

Next thing was to find which of those sites could be visited using the https-protocol. Again, no rocket science here. 259 hosts were listening on port 443 /tcp, the default port for https. It turned out that 3 of them did not talk https on that port, or at least not to me… Another 20 servers did not provide me their (public) SSL certificate details (most of them would probably have provided the details if I had been more persistent, but I wasn’t).

From the remaining 236 systems, these are the (anonymized) facts:

109 systems were willing to exchange data using SSL version 2
149 systems were willing to use encryption keys of 56 bits or less
160 systems were willing to use either SSLv2 or short encryption keys
7 systems were willing to use 0 bit encryption keys (meaning no encryption)
129 certificates had public keys of 1024 bits or less (one as short as 512 bits)
12 certificates were expired (one as old as May 2008)
9 certificates will expire after more than 3 years (one as late as in August 2023)

Como dice el autor, seguramente los datos no son tan precisos como deberían. Pero pintan un buen (mal) panorama que, además, cualquier intersado puede encontrar por su cuenta.

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.

Lo que tu telefonera hace por ti

Interesante trabajo de Zhaoguang Wang y otros de la Universidad de Michigan y también de Microsoft: diseñaron un app para teléfonos móviles que medía algunos parámetros de red, con el objetivo de conocer si las telefoneras lo alteran o adaptan de alguna forma y la conclusión es que, en general, lo hacen. Primero, una justificación de por qué puede ser y los problemas que pueden introducirse:

To better utilize their limited network resources while securing the network and protecting client devices, the carriers have already deployed various network policies that influence traffic behavior. Today, these policies are mostly opaque, though they directly impact application designs and may even introduce network vulnerabilities.

Tantas veces hemos visto eso… Por necesidades propias, o incluso en nuestro beneficio, terminan perjudicándonos.

Algún ejemplo:

… in more than 100 cellular ISPs, we identified the key NAT and firewall policies which have direct implications on performance, energy, and security. For example, NAT boxes and firewalls set timeouts for idle TCP connections, which sometimes cause significant energy waste on mobile devices. Although most carriers today deploy sophisticated firewalls, they are still vulnerable to various attacks such as battery draining and denial of service.

Pero hay bastantes más ‘actividades’.

Vale la pena echarle un ojo en [PDF] An Untold Story of Middleboxes in Cellular Networks o echarle un ojo al resumen que puede verse en el material utilizado en la presentación [PDF] An Untold Story of Middleboxes in Cellular Networks (slides).,

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.

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.