El día 26 de agosto de 2010 01:38, Diego Leonardo Revechini <[email protected]> escribió: > Si bien muchos ojos pueden mejorar lo que nadie ve, la realidad es que > muchos mas ojos pueden darse cuenta de > por donde atacar primero.
Es muy cierto lo que decís. Habría que agregar entonces que el banco tiene que comportarse correctamente y cuando se descubra un error debería corregirlo en cosa de minutos u horas como en el software libre, en lugar de buscar encarcelar al que descubrió el error. Casi siempre que se publica un error en algún software, lo hace gente que quiere que se corrija y si no se hace es porque las empresas se empecinan en cosiderar la reparación de errores de software como un gasto y no como una inversión. > Un banco es una entidad sensible. Si bien estoy > deacuerdo de que deberian usar > software visible, tambien entiendo que abrir de un dia para otro el software > de un banco para que todo el mundo > lo "vea" es francamente un disparate. Bueno, en realidad deberían haber usado desde el principio software que estuviera a la vista. Y si no lo hay deberían haberlo desarrollado a la vista, creando algún proyecto libre donde paso a paso durante el desarrollo la gente haya ido viendo y corrigiendo los errores. La conclusión que podríamos sacar es una que ya conocemos bien: que es un gran error invertir en software cerrado, y ese error se paga durante mucho tiempo porque después te quedás enganchado a él y te sale mucho más caro solucionarlo. > Y me baso en que cualquier software, > posee bugs, y por tanto es sensible a ser > explotado. Eso es una falacia muy utilizada para justificar los errores del software comercial. Se puede hacer software sin errores. Por ejemplo, ahora mismo podría escribirte un programa que suma los parámetros que le pasés y lo hace sin un sólo error. Lo que sí es cierto es que al aumentar la cantidad de líneas de código, aumenta la probabilidad de errores. Pero una probabilidad no es una certeza. Y por otro lado esa probabilidad disminuye muchísimo cuando el desarrollo es abierto como en el software libre porque los errores se encuentran y corrigen constantemente. > E inclusive las maneras mas locas salen de cosas de lo mas > elementales (recuerdo, no hace mucho como > usando campos de un formulario web, inyectaban codigo SQL dentro de bases de > datos) y para eso no es necesario > que se vea el codigo Es un error muy común. Hace unos meses en un software vergonzosamente caro que compró mi empresa, los vendedores decían que no se podían usar apóstrofes en los nombres. Yo me di cuenta instantáneamente de cuál era el error: faltaba escapar o limpiar las secuencias SQL, así que les escribí un mail avisándoles, diplomáticamente, que era un error grave y peligroso (permite justamente la inyección de SQL) y que deberían solucionarlo. Y adiviná qué? Si hubiera sido software libre me lo habrían agradecido y habrían solucionado el problema. Pero esta gente se limitó a contestarme descaradamente que no era un error suyo sino de Oracle. Ahí sí les contesté como se merecían, explicándoles como si fueran unos inútiles que no supieran lo que es una inyección de SQL (porque obviamente no lo sabían), cuáles son sus causas y cuáles los peligros, y que no se trata para nada de un problema de la base de datos sino del programa que la usa. Obviamente el problema sigue ahí, porque si querés que te arreglen un problema en un programa carísimo, también te sale carísimo. Obviamente, por caro que sea el sistema no venía con el código fuente, así que no puedo hacer nada para arreglarlo. Por si hay alguien que no tenga caro el peligro de una inyección de SQL en un programa, acá tienen: http://xkcd.com/327/ >:). Imaginate un hacker con algo de idea, con semejante > informacion. En 30 segundos fundio al > banco. Tremendo... Pero más miedo me da un sistema que tiene esos agujeros y nadie pueda examinarlo y mucho menos corregirlo.
