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).

Anuncios

Las cookies y la seguridad

Todo va cambiando, aparecen nuevas opciones y a veces no estamos al tanto de las novedades en temas que nos interesan. No es tan nuevo pero en C is for cookie, H is for hacker – understanding HTTP only and Secure cookies hay bastante información interesante sobre las cookies y los aspectos relacionados con la seguridad.

Interesante.

Inyección de SQL a través de cabeceras HTTP

Todo lo que viene del exterior es (potencialmente) inseguro. En SQL Injection through HTTP Headers nos recuerdan que las cabeceras del protocolo HTTP las proporciona el visitante y que pueden venir con ‘regalos’:

Cookies and other stored HTTP headers should be treated by developers as another form of user input and be subjected to the same validation routines.

Ya hablamos hace algún tiempo del tema de forma un poco más técnica, en:

Polución de parámetros del protocolo HTTP
PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP?
Contaminación de parámetros Http
Contaminación de parámetros HTTP (HPP)

¿En qué idioma habla tu web?

Un artículo curioso en Language Detection: A Witch’s Brew? donde nos dan pistas de cómo comportarnos (nuestra aplicación, claro) cuando alguien se conecta y tenemos un sistema en varios idiomas:

* Use Accept-Language – it just works
* Use IP detection as a fallback for language, or a separate test to determine jurisdiction
* Cookie your visitors’ language preferences, so you are consistent
* Provide a simple way to switch language, everywhere
* Treat language and compliance issues as two entirely separate problems

A mi me parece especialmente relevante la cuarta, porque siempre es mejor un buen original en inglés que una mala traducción y algunos sitios se empeñan en mostrarte tu idioma (aunque no lo hablen muy bien o no ofrezcan todas las características) y/o en preguntarte cada vez que entras por el idioma (caducan las cookies, cambian el mecanismo …).