Espero que este sea el primero de varios, sobre seguridad en aplicaciones ( y tantito en servers ), hay varios temas interesantes que tocar ( entre ellos uno de criptografía que me pidió sergio tarrillo, los cuales vendrán luego), tengo algunos post en la sección borradores, esperemos que luego puedan salir.
Preludio
un amigo me pidió que cuente algunas de mis experiencias… y eso me hizo recordar ciertas cosas… y bueno recordando viejos tiempos, cuando empecé a meterme “profesionalmente” a lo de informática ( no cuento lo de servers, eso es otra historia ), por allá en el 2001, empecé como “tester”, ya que era un simple estudiante de Ing. Química, dentro de una empresa que hacia Software de Ingeniería ( Software especializado para Ingeniería de Procesos, lógicamente de los Químicos), que solo sabia algo de pascal, assembler, RPL y algo de programación PLC –a excepción de assembler, lo demás nos lo dan en la carrera-, pero con ningún conocimiento formal sobre Ing. de Software, o procesos de desarrollo de software –lógicamente ya estoy cubriendo esa falencia –, empecé en esa empresa formada por ex alumnos de la facultad mi universidad (UNI ), curiosamente me metí a este mundo, por que por los cálculos avanzados de la carrera ( matemáticos y demás), se tenia que realizar simulación de procesos y la universidad solo tenia un “trial – limitado” de la versión actual y la versión full era demasiado antigua como para poder hacer las simulaciones ( la licencia pasaba de los USD $ 250,000.00 ), así que con unos compas empezamos a buscar el “crack”, pero como no existía ( casi no existen de software especializados, por suerte :)), nos pusimos a estudiar ensamblador, y finalmente pudimos usar la aplicación…, lógicamente, ya a estas alturas de mi vida, ya no promuevo el “crackeo ilegal” – si, de eso viene el otro post –, aunque eso hizo posible mi incursión en el mundo del software, ya que me acoplaron a una empresa de ex alumnos, cuando yo aun era alumno. Ya luego logre ver a .Net, me maravillo y comencé a programar allí, me fue gustando mas el mundo de la informática, así que poco a poco que termine alejándome del mundo de la Ing. Química y me fui al software ( discúlpenme que no considere a la “Ingeniería de software” una ingeniería de verdad – por mas que desde el 2004 “estudio formalmente sobre informática y/o sistemas” y trabajo en cuestiones de software – , pero mi concepto de “ingeniería” es muy diferente al de los informáticos tradicionales –por mi carrera base- y me es imposible – al menos por el momento- considerarlo una ingeniería. ), luego ya cuando vine a México, me metí al 100% a lo de software :)- en varios campos -, ….
Ahora si, ya entrando al tema de este post 
:
Algo que se esta volviendo muy común, en las empresas de software, es que cada vez están pensando – y ya muchas lo hacen – , el tener un área de “control de calidad”, o área de pruebas, (sobre este tema Miguel Llopis tiene varias entradas al respecto, coincido en muchas cosas – con respecto a este tema –, aunque en algunas otras… aun estoy algo escéptico; pero de todas maneras me parece interesante lo que pone ;), léanlo ).
Lógicamente hay muchas empresas que tienen bien estructurada y organizada su área de pruebas, aunque de todas maneras se les escapan “bugs”, entre ellos tenemos a Microsoft, Google, etc; por lo que e visto en los betas de MS que ando metido – empecé con el vs 2005 alpha – Microsoft a mejorado mucho su modo de tomar los errores, y como los recibe, desde Betaplace hasta ahora con Connect , y e visto que hablan que tienen sus tester y demás, pero aun así, se les escapan bugs, algunos gigantescos, lo bueno es que ahora los encargados de los productos hacen mayor énfasis a recibir comentarios y sugerencias; pero si asi pasa con una empresa que invierte mucho dinero en pruebas, imagínense como es con las empresas con una mínima o nula inversión al respecto.
A mi parecer, en muchos casos aun veo algunos detallitos al como se aplica la parte de pruebas en las empresas, dentro del desarrollo de software, lógicamente hay empresas que si aplican muy bien esto, y el % de errores que se les escapa es “mínimo”, veamos algunos que pude lograr ver.
- Personal no Especializado El detalle aquí es que en la mayoría de veces se pone “solamente” a las personas con menos experiencia, o mejor dicho personas no especializadas en el tema (no estaría mal, que si el equipo tuviera una parte de un tipo y otra del otro tipo ), o también a personas con un nivel bajo o nulos conocimientos de programación, los ponen a “usar la aplicación”, si bien al estar considerados como “Usuarios comunes y silvestres” saldrán varios “detallitos”, pero quizá no los mismos que podría sacar alguien con algo mas de conocimientos – aunque como siempre, hay casos que rompen la regla, esos con dones “destructivos”, en los cuales todo lo que tocan falla 🙂 –, pero el detalle aquí es que la cantidad de errores descubiertos, puede ser mínima, comparando con los que realmente tiene la aplicación, por eso es bueno tener gente especializada, si bien quizá no todo el equipo, pero no debería de faltar alguien especializado,al respecto también a escrito hace algún tiempo Joel Spolsky sobre este tema en su articulo Las Cinco Principales Razones (Equivocadas) por las Cuales no tienes Ingenieros de Prueba, aunque el a su vez aclara que es difícil conseguir buenos, y en algunos casos solo podamos ir rotando gente sin experiencia.
- Tienen un área de pruebas, pero nadie les hace caso : E visto esto en varias empresas, donde los programadores, se podría decir que casi ignoran los tickets enviados por los de pruebas, y dicen “ luego los arreglo” – algo que nunca pasa –, es algo ilógico tener un área de pruebas y que casi nunca se les haga caso, esto en algunos casos es por la mala planeación y que los programadores estén “contra el reloj” terminando funcionalidad y “no tengan tiempo para corregir”, aunque en otras es culpa de los programadores, pueden ser muchos los posibles motivos, aunque parezca algo loco, lo e visto :); hasta me a llegado a pasar ya un par de veces con los team de MS, enviaba bugs y hubo casos en que se demoraban hasta meses para tan solo revisar el error – imagínense en repararlo – , por suerte ya esta mejorando esto, jeje y bueno también tengo un usuario “moderador” en Connect.
- Poco o nulo énfasis a la seguridad – (este será el foco de los siguientes post) los encargados de pruebas, en la mayoría de casos, se dedican a ver que la aplicación funcione “ como debe”, el detalle aquí es que en muchos casos se limitan a dar unos cuantos clics, a la aplicación y piensan que con eso eso la aplicación esta libre de problemas y que es segura, lógicamente hay varios niveles de seguridad, dependiendo de la solución, puede ser algo básico o niveles extremos como los que usa la NASA – así le dice Jerson - ( sobre esto creo que mejor no me extiendo por ahora y lo dejo para un siguiente post), lógicamente ya muchos pensaran, pero hay programas ( de terceros) que hacen esto, a lo cual les diría, que esos programas, si bien es cierto que ayudan en muchos casos, no nos dan una seguridad al 100% (lógicamente también depende de la solución y del nivel de seguridad que necesitemos); otros dirán “ Visual Studio” trae herramientas muy potentes, lo cual es en extremo cierto, pero no para “análisis automático” allí también hay que programar pruebas :), personalmente me parece una herramienta muy potente y algunas de las veces que me han pedido que haga “pruebas” e usado al VS como herramienta de trabajo –a ver si mas adelante escribo algo de esto-. La seguridad es un mundo no es posible tocarlo en un solo post, todo dependerá de que tanto queremos
- Los encargados de pruebas, tienen flojera : No puedo negar que es algo tedioso y en algunos casos algo aburrido estar “probando aplicaciones” , y muchas veces e visto a tester’s que por lo mismo, y pro zafarse del trabajo (para luego poder seguir googleando), le dan una revisada “al vuelo” y no concienzudamente, aunque también, hay quienes pueden estar trabajando todo el día buscando errores y encontrar unos cuantos mientras hay quienes solo con 40 minutos, puedes sacar una gran cantidad de errores; lógicamente si detectamos personas que no hacen bien su trabajo, no merecen menos que el despido.
- No se tiene un buen control del historial de “bugs” : por mas que tenga buenos encargados de pruebas, si no lo hago de un modo ordenado, todo eso se volvería un caos, existen múltiples programas, entre free y de paga ( hasta un starter kit de aspnet 1.0) con el que podemos tener bien registrados los errores.
- No se Integra desde la etapa de diseño la seguridad : mucho se habla de esto, aunque quizá no muchos lo apliquen, en la etapa del diseño de la aplicación debería integrarse la parte de seguridad, lamentablemente es muy difícil conseguir un programador y un diseñador que sepa de seguridad (saber de verdad), la mayoría no piensa en seguridad, o en su defecto, tienen un conocimiento empírico, saben que tienen que poner seguridad, pero en la realidad no aplican seguridad…, y luego cuando empiezan los problemas ( lógicamente no en todos los sistemas aparecen) , tienen que comenzar a “parchar”, lo cual hace que se pierda mas tiempo, al menos por eso lo que suelo recomendar es que el diseño pase por un análisis previo de seguridad, este entra al de funcionalidad.
De todos estos puntos que puse, en el que quiero especificar es en el de la seguridad y especialización, lógicamente sin olvidar sobre el performance, ya que como dicen algunos “intentar poner seguridad de manera desmedida, sin tomar en cuenta el impacto en el performance es malo”.
En el siguiente post, espero tocar una pregunta que en algunos casos es controversial… “saber técnicas de hacking y/o cracking, es malo?”, intentare explicar, el por que creo que no es malo, mas bien por el contrario, es imprescindible.”, ya luego vendría uno de criptografía 🙂 , si, la respuesta al post de Sergio Tarrillo
Para terminar – por ahora – quiero dejarles algo para que piensen… “el mejor ataque, es cuando la victima no se a dado cuenta que a sido atacada, y que están dentro del sistema” ( la idea es evitar esto, ya que no es necesario que nos modifiquen una pagina, o que nos pongan una foto, para que “estén dentro” ) .
Salu2
