Leía hace unos días el artículo algorithmic complexity attacks and libc qsort() donde se hace un análisis del Quick Sort, lo que pueden costar algunas de sus implementaciones y fantasea con la posiblidad de utilizarlo para algún tipo de ataque de denegación de servicio (o al menos ralentización).
Son de esas cosas que nos trae el software libre e internet.
En why I don’t touch crypto explican un par de buenas razones para no tratar de inventar nada relacionado con la criptografía. Un buen recordatorio:
La generación de números (seudo)aleatorios es un problema difícil y hablan
de un fallo:
Last week’s issue in the random number generator in Cryptocat is a very good example.
The bug was an off-by-one error in their random number generator. The output of the function was still random numbers, looking at the output would clearly show random numbers. Given that fact, the natural bias for seeing code as being correct is only reinforced.
Comprender los conceptos no es suficiente, es muy fácil equivocarse:
I’m just plain not good enough. Crypto is a world where understanding the concepts, understanding the math and writing tests just isn’t good enough.
Ya hace mucho tiempo de aquellos tiempos en los que se hablaba de lo simple que era Firefox (Mozilla en aquel momento) frente a la complejidad del navegador de Microsoft (recuerden Software Complexity: Open Source vs Microsoft.
Por eso es interesante echarle un vistazo a How maintainable is the Firefox codebase? donde se mostraban varias medidas habituales. Se ve que no está mal del todo, aunque algunos módulos se estarían volviendo más y más complejos.
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
En How to build (and how not to build) a secure “remember me” feature Troy Hunt nos da ideas sobre el botoncito que tienen casi todas las aplicaciones web que permite que la próxima vez que volvamos a utilizarlas recuerden toda (o parte) de nuestra información a la hora de autentificarnos en el sistema.
Cosas que se pueden hacer mal, información que no sería necesaria pero que se almacena de alguna forma…. Y algunos ejemplos del ‘mundo real’ que parece que ya no deberían ser fáciles de encontrar.
Mucha gente no diferencia entre concurrencia y paralelismo, aunque ténicamente tienen sus diferencias, que podrían empezar a divisarse en:
Concurrent = Two queues and one coffee machine.
Parallel = Two queues and two coffee machines.
Aunque, según el autor la cosa va más allá. Dice, hacia el final:
We’ve discussed differences between parallel, computational systems and
concurrent, event handling systems. Areas of differences include:* Determinism: desirable vs impossible
* Sign of parallel safety: same results vs correct results
* Parallelism bugs: easy to pinpoint vs impossible to define
* Queues: implementation detail vs part of the interface
* Preemption: nearly useless vs nearly essential
Me gustó leerlo.
Un debate interesante en QoTW #43: Teaching a loved one about secure coding practices: ¿En qué momento del aprendizaje debemos pasar del ‘funciona’ a ‘es difícil que falle, incluso en malas condiciones’?
Y empezamos con algo que creo que no hacemos bien del todo: cuando enseñamos no tenemos en cuenta la seguridad (ni la robustez en muchos casos):
The very first link points towards w3schools.com.
A quick browse through the site looks good. Nice, simple, easy to follow tutorials on the basics of PHP and HTML. Wait, are they really teaching unparameterized queries? In 2013? Really? I’d like to point you to this website. In particular, this quote.
Alguna respuesta interesante, si aprendemos mal luego tendremos que ‘desaprender’:
The problem I see, is that secure programming is taught as an add on. Best practices should be taught from the beginning (including security). The lie people are taught is that practice makes perfect. The truth is practice makes permanent. So if you are doing it wrong, you have to unlearn what you have learned. That is a bassackwards approach. I would say that secure coding practices should be taught from day one. There’s no reason to learn how to do it, and then learn how to do it securely. It’s a waste of time and money…
Pero claro, cuando enseñamos necesitamos cierta ‘tranquilidad’ para poder mostrar los conceptos sin excesiva sobregarca:
It’s great to say “Secure coding practices should be taught from day one”, and very hard to demonstrate how that day-one “Hello World” program may be vulnerable, especially when “what is a computer program” is a new concept for the class.
Un camino, una vez que hayamos empezado:
Once a flaw has been found, have her rewrite the application to fix the flaw. Doing so will allow her to appreciate the effect of things like sanitation and validation of user inputs and parameterized queries. Take incremental steps. I wouldn’t jump straight into designing a new application with security in mind before truly understanding what type of codes result in security flaws.
El hilo original estaba en Teaching a loved one about secure coding practices.
De este tema no hablamos demasiado por aquí: no por falta de interés, sino porque tampoco hay mucha documentación que vaya más allá de las generalidades. En McGraw’s mobile app security strategy: Three legs of ‘trusted on busted’ un texto de los que son más bien generalistas.
Las tres patas serían:
En Dreams and Nightmares algunas ideas sobre un taller donde se analizaba la tensión permanente entre hacer cosas que tengan valor y la necesidad de invertir en crear una buena infraestructura que les de soporte. El debate entre la técnica y la economía.
Se propone incluir en la planificación escenarios terroríficos (la pesadilla) que pueden suceder si algo va mal y no se ha invertido suficiente en que la base sea sólida: se estima el coste, el esfuerzo necesario en caso de que algo vaya mal…
El problema de algunos requisitos no funcionales de este tipo es que no encajan siempre bien con las historias de usuario y por lo tanto son complicados de integrar en el proceso. Pero estos requisitos han de tenerse en cuenta y no perderse de vista en las sucesivas iteraciones.
Interesante.
Como ya llevamos años con el tema es agradable ver como, de vez en cuando, más gente lo dice. En este caso lo vi en Los desarrolladores de software necesitan saber hacer software seguro.
Yo estoy bastante convencido de eso, pero como dice el autor no todo el mundo lo tiene claro y en los equipos ágiles es fundamental:
La conclusión a la que se llegó es que los desarrolladores de software necesitan formación en seguridad para que puedan diseñar y desarrollar software seguro, al menos, en cuanto a unos requisitos mínimos se refiere. Y es que estamos hablando de calidad del software.
Mbpfernand0's Blog 