Seguridad en iOS según OWASP

Recomiendo con cierta frecuencia las chuletas del OWASP (OWASP Cheatsheets). Las hay de más nivel y menos, algunas que no se actualizan lo que deberían y no siempre está todo tan bien explicado como debería. Pero es una iniciativa muy interesante en la que normalmente contribuyen expertos que saben bastante de los temas de los que tratan y puede ser una puerta de entrada a más información.

En esta ocasión recomendamos: IOS Developer Cheat Sheet.
Por si alguna vez nos tenemos que acerca a un proyecto con estas tecnologías.

Actualización (2014-02-25): veo en Guía de Desarrollo Seguro de Apple un enlace justamente a eso: [pdf] Apple Secure Coding Guide y también Secure Coding Guide.

Protección contra CSRF sin estado

En Stateless CSRF Protection se dan algunas ideas sobre protección contra CSRF (Cross Site Request Forgery) cuando no tenemos la ayuda de las sesiones en el servidor. En el caso de que tengamos una sesión, los consejos hablan de utilizar algún identificador adicional que envía el servidor y hay que re-enviarle, de forma que si la petición no viene de donde debe, ese identificador no será correcto.

Traditional anti-CSRF techniques use tokens issued by the server that the client has to post back. The server validates the request by comparing the incoming token with it’s copy. But that small word «copy» means server-side state. Not good.

Cuando no tenemos estado en la aplicación (cosa rara, la verdad, porque parece que eso de tener unas galletitas y sesiones se hace hasta cuando no hace falta para nada), la idea se que el cliente calcule un identificador y lo envíe como cookie y dentro de la petición (de esa forma sería más difícil para un atacante obligar a un usuario a enviar esa petición).

The protective measure of double submit lies in the fact that a malicious site cannot read the cookie and include it as request parameter. That condition still holds if the cookie is generated by the client and never saved by the server.

So let the client generate the anti-CSRF value and only compare and check format of cookie and request parameter on the server. Ergo, stateless CSRF protection!

Glosario de ciberseguridad

Estas listas siempre tienen sus defectos. Fundamentalmente, muestran los sesgos de los que las hacen. No obstante, también nos dan una idea de por dónde van los tiros en cada momento. En The ABZs of Cybersecurity el punto de vista de Pete Herzog. El foco en:

As you will see, we put a lot of stress in responsibility and accountability rather than just listing bad things that can happen to them. This type of treatment has had great success in helping people with bad habits and phobias. The benefit of this is to help them to control things they can control yet not completely give up most the things they enjoy doing. That means changing how they do the things they do instead of what they do. Since a person’s nature is hard (impossible?) to actually change, we just want them to be aware of what the consequences are and how to avoid them even if just partially.

Trazabilidad, responsabilidad, contabilidad…

Las claves

Interesante el podcast de la OWASP sobre recuperación de claves ([mp3] forgot password) sobre la manera recomendada de recuperar una cuenta cuya clave hemos perdido (se pueden leer los consejos en: Forgot Password Cheat Sheet, aunque mucho me temo que es una visión parcial del problema, puesto que habla del bloqueo de cuentas y eso no siempre es factible/razonable y se ocupa de sitios con bastantes datos del interesado que tampoco es siempre el caso).
Escuchándolo, pensé en recopilar y poner los últimos enlaces sobre el tema que he ido recopilando. Por cierto, interesante el sitio Good Security Questions, que nos da una idea de buenas opciones para esta parte tan delicada (imagino que también habrá que prestar atención a las cuestiones culturales, así que convendrá tomarlas con una ‘pizca de sal’).

En The truth about passwords. Un análisis de las claves, la seguridad y la facilidad de uso bastante interesante. La conclusión:

It seems that the easy systems aren’t secure, and the recommended systems aren’t usable, because they take too long or require too much remembering.

En The Usability of Passwords que habla sobre seguridad razonable, alargando las claves mediante el uso de frases, más fáciles de recordar. Tiene sus detractores. Yo diría que la longitud ayuda pero que, seguramente, sería buena idea no utilizar sólo palabras que forman frases.

Por si acaso, A brief Sony password analysis:

La gente elige malas claves, pero sus propias malas claves, no hay muchas repeticiones:

However in the grand scheme of things, there weren’t a whole lot of instances of multiple people choosing the same password, in fact the 25 above boiled down to only 2.5%. Furthermore, 80% of passwords actually only occurred once so whilst poor password entropy is looking rampant, most people are making these poor choices independently and achieving different results.

Eso sí, la gente usa la misma clave (hay gente que lo hace en una cantidad
notable, al menos) entre diversos sitios:

Two thirds of people with accounts at both Sony and Gawker reused their passwords. Now I’m not sure how much crossover there was timeframe wise in terms of when the Gawker accounts were created versus when the Sony ones were. It’s quite possible the Sony accounts came after the Gawker breach (remember this was six months ago now), and people got a little wise to the non-unique risk. But whichever way you look at it, there’s an awful lot of reuse going on here.

Finalmente, con un ataque sencillo se adivinarían bastantes claves (y la importancia de la longitud de las claves):

82% of passwords would easily fall to a basic rainbow table attack. Not good, but you can see why the rainbow table approach can be so effective, not so much because of its ability to make smart use of the time-memory trade-off scenario, but simply because it only needs to work against a narrow character set of very limited length to achieve a high success rate

Y la conclusión: The only secure password is the one you can’t remember.

Para terminar, el aviso de que Hotmail: Microsoft bans the use of vulnerable passwords lo que redundara, seguramente, en una nueva generación de malas claves (es broma).

OWASP ¿hasta dónde?

Mark Curphey es uno de los creadores del proyecto OWASP. En OWASP – Has it Reached a Tipping Point ? hace un repaso de lo sucedido y por dónde cree que deberían ir los tiros en el futuro.

He seleccionado un par de parrafitos:

Ask your average OWASP member how to federate identity across the Internet
and reckon you will be met with a blank stare but ask them how to check for
XSS and I bet you would be greeted with a smile. Thats a problem. That is
not to say that people who live and breath HTTP security isn’t incredibly
valuable but it wasn’t what I wanted or what I really care about.

Que se preocupa, en definitiva, de si los conocimientos están llegando a
los lugares adecuados: no se trata de saber mucho de un tema, sino de que
las personas adecuadas se preocupen de ello.
Y la siguiente, en la misma línea:

We can’t have security people who know development. We must have developers who know security. There is a fundamental difference and it is important.

Es decir, la gente de seguridad ya conoce los problemas, pero es necesario
que los conozcan y se aproximen a ellos las personas adecuadas, los
desarrolladores:

1. Gestionar el porfolio de proyectos
2. Conseguir el interés de la industria y comunicar adecuadamente
3. Ética/Código de conducta
4. Atraer a los desarrolladores

Sobre el primer punto, ya ha conseguido que el promotor de uno de los proyectos lo cerrara.

Seis formas de empezar a programar software libre

Lo veo en 6 Easy Ways To Get Started Programming Open Source y habla de 6 Easy Ways To Get Started Programming Open Source:

1. Implicarse en los proyectos que utilizamos
2. Hacer lo que nos gusta
3. Aprender las herramientas
4. Fijarse en las dinámicas sociales del proyecto
5. Empezar por cosas pequeñas
6. Empezar nuestro propio proyecto

Promesas incumplidas de la seguridad

En Security engineering: broken promises Michal Zalewski comenta sobre los problemas que tienen las diversas aproximaciones a la seguridad informática y en qué han fallado.

Por un lado los métodos formales se enfrentan al problema de la dificultad de definir el comportamiento deseable para un sistema de tamaño suficientemente complejo; es difícil traducir los deseos en expresiones formales; es difícil analizar formalmente el comportamiento de los programas.

Por el otro, hablaríamos de algo más actual, el análisis de riesgos. Sus defectos: en un sistema interconectado las pérdidas no están aisladas, ni ligadas a un activo concreto; las predicciones estadísticas no nos informan de nuestros problemas concretos; la seguridad no es un sistema que pueda seguir el esquema de las empresas de seguros (no hay datos estadísticos suficientes para modelar los problemas y sus consecuencias monetarias).

Finalmente, la categorización tiene sus propios problemas y, hasta ahora, no ha aportado mucho orden ni claridad a la forma en que podemos enfrentarnos a los problemas.