El 26 de agosto de 2010 08:56, Diego Leonardo Revechini <
Post by Alejandro VargasEl día 26 de agosto de 2010 01:38, Diego Leonardo Revechini
Post by Alejandro VargasPost by Diego Leonardo RevechiniSi 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.
Desgraciadamente para los que manejan la batuta de muchas empresas, la
informatica
sigue siendo un gasto...
Un banco es una entidad sensible. Si bien estoy
Post by Alejandro VargasPost by Diego Leonardo Revechinideacuerdo 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.
De nuevo, quienes manejan la batuta, se mandan soberanas macanas que
despues
son insalvables en el tiempo.
Y me baso en que cualquier software,
Post by Alejandro VargasPost by Diego Leonardo Revechiniposee 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.
Mira, el ejemplo mas claro que puedo darte es Firefox y Microsoft
Internet Explorer.
Ambos nacieron del mismo proyecto. La concepcion es la misma, y los
problemas
(bugs) a la larga en muchos casos los mismos. Mientras IE se la pasa
arreglando bugs
Firefox ha, gracias a una mejor inteligencia colectiva, mejorado aspectos y
no caido
en los mismos bugs que su "hermano". Sin embargo, sigue teniendo (no
tantos) como
IE y seguira teniendo porque habra alguno que tarde o temprano se de cuenta
de
como hacer para reventar algun aspecto que no fue tenido en cuenta. Vos me
diste el
ejemplo de que podes hacerme un programa sin errores. Pero para hacerlo
deberas
PENSAR en todas las posibilidades que el usuario PODRIA no respetar. En tu
mismo
ejemplo, me decis de sumar dos parametros ¿de que manera? ¿numericos?
¿concatenados?
Si son numericos, entonces deberas limitar al usuario que no te ponga
letras y simbolos
(siempre hay algun guacho), porque el programa fallara. Tambien limitar la
cantidad a sumar
no valla a ser que puedas colapsar la memoria del programa traspasando al
SO (siempre
hay algun otro guacho), y entonces el programa crece y crece, y uno nunca
esta cubierto
porque nunca piensa las infinitas posibilidades que hay para reventar el
programa.
Y el tener el codigo fuente, a veces inclusive te da la posibilidad de
"crear" nuevos metodos...
En cuanto a la velocidad de resolucion de errores, si, quizas como decis,
lo abierto es
mas rapido de arreglar, y mas rapido de encontrar errores antes que
sucedan. En lo
cerrado es a prueba y error hasta que salta el problema, es como ir
caminando a ciegas y
de golpe te encontras con un pozo. De la otra manera, es la misma calle
pero encontras
los pozos y te evitas el porrazo.
E inclusive las maneras mas locas salen de cosas de lo mas
Post by Alejandro VargasPost by Diego Leonardo Revechinielementales (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/
Cierto, muy cierto. Yo tengo experiencias parecidas que van desde el
cifrado (medio
insulso, pero cifrado al fin) de tablas de datos, hasta el "flaco, te pago
para que
desarrolles tu producto y utilices un motor SQL neutro" y la respuesta es
"no se puede"
y yo estoy SEGURISIMO que estos cabezas usan SQL basico al estilo M$ porque
tengo un servidor andando y no hay un fucking tigger ni nada por el estilo.
Pero son
programadores de hace 40 años que se casaron con un lenguaje y que de pedo
usan SQL, asi que imaginate...
:). Imaginate un hacker con algo de idea, con semejante
Post by Alejandro VargasPost by Diego Leonardo Revechiniinformacion. En 30 segundos fundio al
banco.
Tremendo...
Si verdad :)
Pero más miedo me da un sistema que tiene esos agujeros y nadie pueda
Post by Alejandro Vargasexaminarlo y mucho menos corregirlo.
Uuuu, el concepto de "che, yo puedo hacerlo mejor, sos un SQT" lo tengo
incorporado
hace años. Donde valla veo cosas que estan mal hechas y que con tan solo
algo de
cesudes, se puede hacer mucho mejor. Desgraciadamente soy un "genio"
desperdiciado :)
y hablo de cualquier cosa, no simplemente de software.
Saludos Alejandro.
--
Diego Leonardo Revechini
Soporte Tecnico Independiente
blog: www.olafitoweb.com.ar
respecto al software. NO digo que definamos un discurso contra el imperio,
guerras para volver a contestar un mail...
de soft en General. SI es Soft libre, entonces no tenemos que dar respuestas
personas que lo crearon tengan acceso a el (encima esto es ilegal.... la
propiedad es el creador. Puede que el creador no tenga derechos de uso
comercial por haberlos "cedido", pero sigue siendo el dueño. PRivarlo del
para que otro grupo s forme y maneje temas solo de soft libre. Sino es como
sabemos del tema. Es incongruente por dode se lo mire.