¿Por qué son lentas las aplicaciones web en el celular?

Un interesante análisis en Why mobile web apps are slow de los diferentes parámetros que afectan al comportamiento de aplicaciones web en el teléfono móvil.

Las cabeceras de seguridad para los sitios web más importantes

Aunque la entrada que yo guardé en su día era otra, en Security Headers on the Top 1,000,000 Websites: March 2014 Report se puede encontrar justamente eso: el resumen de un estudio sober el primer millón de sitios más importantes en la web (según Alexa) y las cabeceras relacionadas con la seguridad que envían desde sus páginas web.

Normalmente estas entradas nos pueden servir para bajar un poco los pies a la tierra sobre lo que realmente se está utilizando en la industria y también para echarle un vistazo a todas las cabeceras en las que deberíamos pensar si somos nosotros los que tenemos que tomar la decisión de cuáles enviar.

Si miramos la serie a lo largo de tiempo también pueden ser útiles para ver cómo van cambiando los usos y costumbres.

Finalmente, me gustan porque permiten ver todo lo que se puede saber en la red, con unas pocas herramientas y ganas de hacer los programitas adecuados.

Veo que también han publicado:
Security Headers on the Top 1,000,000 Websites: November 2013 Report.
Security Headers on the Top 1,000,000 Websites: March 2013 Report.
Security Headers on the Top 1,000,000 Websites (noviembre 2012).

Algunas medidas proactivas para la seguridad en aplicaciones web

En Top 10 Proactive Web Application Security Measures.

– Content-Security-Policy
– X-Frame-Options
– anti-CSRF cryptographic nonces
– DAL (data/database access layer)
– Unwritable file system
– Forensically secure logging
– Secure credential/passwd/secret questions and answers storage
– SSL, cookies with secure flags, cookies with httponly and STS
– Security frameworks
– autocomplete=”off” and strong passwords

Algunas debilidades de HTTPS

Como ya tiene un tiempo y además es algo especulativo (siempre que hablamos de romper métodos de cifra se trata de resultados que teóricamente nos hacen pensar que algo podría ir mal), viene bien traer aquí Has HTTPS finally been cracked? Five researchers deal SSL/TLS a biggish blow….

Se criticaban los algoritmos de generación de números aleatorios (ya hemos hablado del tema en Números aleatorios y seguridad, por ejemplo):

The problem is that although RC4 is a cryptographic PRNG, it’s not a very
high-quality one.

Y también sobre el ataque:

This result, incidentally, was the basis of the attack that broke WEP, the original encryption protocol used in Wi-Fi networking, and forced its replacement with a newer encryption system called WPA.

Los consejos?

If you can, ditch RC4 from the set of symmetric ciphers your web browser is willing to use, and your web servers to accept.

Go for AES-GCM instead.

¿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í.

URLs y Ajax

Cuando lo lei (y lo guardé para comentarlo aquí, hace ya algún tiempo) me gustó leer Must-Know URL Hash Techniques for AJAX Applications. Algunos de los ejemplos han quedado obsoletos, pero el concepto sigue siendo interesante.

También nos sirve para darnos cuenta de por qué, a veces, parece que al ordenador le cuesta ‘mover’ las páginas de GMail, Twitter, Facebook, … En realidad son aplicaciones en javascript que corren en nuestro computador y que solicitan determinados servicios al sitio web en cuestión.

Decididamente, vale la pena su lectura.

Polución de parámetros y cortafuegos de aplicaciones web

Igual es excesivamente técnico pero tiene que ver con cosas que ya habíamos comentado y por eso me gusta traerlo aquí: Bypassing WAF via HTTP Parameter Pollution. Y como recordatorio de que algunas herramientas nos ayudan, pero nada supera a haber hecho bien las cosas desde el principio.

Sobre polución de parámetros http: Contaminación de parámetros HTTP (HPP), Inyección de SQL a través de cabeceras HTTP y algunos más.

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.

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.