Solo como acotacion al pie, me parece bueno aclarar que no siempre que encontramos vulnerabilidades en un app le hechemos la culpa a los developers de una diciendo que estos no tienen ni idea de practicas de seguridad. En la mayoria de los casos las empresas no invierten en seguridad, crean una bateria de smoke tests y casos de uso especifico, si eso pasa el release se aprueba, en todo caso despues cuando la aplicacion es estable y los reditos fueron buenos la empresa invierte en consultores de seguridad o en el peor de los casos lo hacen despues de algun incidente. Pocas empresas se rigen por un riguroso proceso de calidad, y a veces los tiempo sencillamente no dan, hay que sacar un release porque hay una demo ya programada ante un grupo de inversores y los developers hacen lo que pueden, y la clasica frase de los dirigentes es: "despues vemos, ahora hay que terminar esta feature" :D
Por otro lado tambien es cierto que los developers no son (somos) expertos en seguridad, sino los consultores de seguridad no tendrian trabajo ;). Aprovecho tambien para responder algo que lei en este mismo thread, donde hablaban de que mantener los tests puede ser una tarea tediosa frente a los cambios de codigo. El tema es que unicamente deberias cambiar los tests cuando renombras classes lo cual es bueno si estas limpiando el codigo pero no es algo que se hace seguido, si los tests estan bien construidos y el resultado esperado de los metodos esta bien definido, cuando cambies el codigo de los metodos esto no deberia afectar en absoluto a los tests, esa es la maravilla de la ecapsulacion. Bueno, lean el paper de Matias que esta muy bueno. Saludos. /jk 2008/12/3 Matias Pablo Brutti <[EMAIL PROTECTED]> > Se que es un poco "off Topic" , pero hablando de testing yo ademas de > pensar los tipos de tests que mencionan como consultor de seguridad se me > vienen a la marola, los tests que yo tengo que hacer a diario. Y que creo > que deberian estar haciendolo los developers como parte de "testing" > Mi recomendación con respecto a tests de seguridad es hacer ambos tipos > whitebox ( auditoria de codigo) y blackbox en la forma de web application > Penetration tests. > > En la ultima LugparanaConf que se realizo en Paraná, di una charla > sobre vulnerabilidad en aplicaciones web con una orientación para > programadores y developers. ya que a diario veo que la gran mayoría de estos > no tienen ni idea de practicas de seguridad. Talves para > la próxima reunión que tengamos la pueda orientar exclusivamente a > ruby/rails/otros frameworks y dar algo. SI alguien tiene ganas hasta podemos > hacer algo en conjunto. > > Slds. > > > > 2008/12/3 NachoKB <[EMAIL PROTECTED]> > >> >> >> 2008/12/3 Nicolás Sanguinetti <[EMAIL PROTECTED]> >> >>> >>> Hasta hace un tiempo, era un firme creyente en limitar los tests al >>> caso mas especifico posible, stubbear todo, y asegurarme de que todos >>> los tests fuesen unitaros. >>> >>> Hoy en dia, hago todo lo contrario. Estoy escribiendo *solo* tests de >>> aceptación (usando Cucumber), y cuando necesito testear algun edge >>> case, o tengo que modelar algún api "no convencional", bajo a escribir >>> units. >> >> >> A mi me pasa justamente que me cuesta muchísimo pensar "de arriba hacia >> abajo", necesito siempre comenzar por los units (y, digamos, siempre queda >> poco tiempo para integración y aceptación). >> >> Recién cuando voy conociendo la funcionalidad es que "me sale" el diseño >> de la "interacción"... >> >> >>> >>> >>> Ojo, los tests son lentos. Esa es una contra grande a ir contra toda >>> al aplicación en lugar de testear en aislación una clase dada (además, >>> ruby es lento! >:-)), pero a) me dicen si anda o no exactamente lo que >>> el cliente quiere (si los stories de cucumber son buenos) y b) no >>> pierdo horas manteniendo tests. >>> >>> (b) es un problema grande. Mañana refactorizas un método de un modelo >>> y pasa una de dos cosas: >>> >>> 1) Cambiás todos los controller tests que usan dicho modelo >>> (engorroso, aburrido, perdida de tiempo que le estás cobrando a tus >>> clientes sin darle ningún beneficio a ellos) >>> >>> 2) Te olvidás, y todos los tests siguen pasando, por más que tu >>> controller se rompe, y el cliente te llama a las 3am para putearte >>> porque justo hizo una demo a un potencial inversionista =P (no, no me >>> pasó, pero podría) >>> >>> >>> En definitiva, escribir tests a lo más alto nivel posible, y, a medida >>> que se hace necesario por edge cases, ir bajando de nivel hasta units. >> >> >> Me encantaría :D >> >> >>> >>> >>> Y ta, el tema de la lentitud se puede "arreglar" no corriendo toda la >>> suite de tests todo el tiempo, sino solo los que te importan a vos >>> mientras estas trabajando, y dejar que un servidor de integracion >>> continua como Integrity [1] te avise si se rompio algo ;-) Así >> >> trabajan en github, por ejemplo (si, si, usan integrity =P) -- Ojo, >>> esto solo funciona si pusheas cambios seguido. Si sólo pusheas una vez >>> al final del dia, suerte en pila =) >> >> >> Chivo!! :D >> >> >>> >>> >>> -foca >> >> >> -- nachokb >> >> >>> >>> >>> [1] Chivo! http://integrityapp.com >>> >>> On Wed, Dec 3, 2008 at 12:38 PM, Pedro Visintin >>> <[EMAIL PROTECTED]> wrote: >>> > Hola Gente: >>> > >>> > Creo que todos estamos de acuerdo que las metodologías no estan 100% >>> maduras >>> > y estan evolucionando continuamente. >>> > >>> > A medida que avanzamos nos aparecen nuevas preguntas y cuestionamientos >>> > sobre lo que venimos haciendo y si nos sirve para lo nuevo o si hay >>> forma >>> > mejor de hacerlo. >>> > >>> > Muchas veces caemos en el cliche de tomar lo que dice el libro, pero >>> siempre >>> > es lo mejor? >>> > >>> > En cuanto a testing hay muchos interrogantes y muchas diferentes formas >>> de >>> > encarar las cosas. >>> > >>> > Esta charla plantea algunas cosas interesantes para pensar: >>> > >>> > http://rubyconf2008.confreaks.com/testing-heresies.html >>> > >>> > De ahí sale la pregunta: Con los specs y tests de controllers hago >>> stubbing? >>> > >>> > pros que veo con stubbing: >>> > el dominio del test lo tengo claro, estoy testeand el controller. >>> > me fuerza a hacer stubbing de todas los mensaje s que mando a los >>> objetos lo >>> > cual queda bien ajustado. >>> > me delata si tengo acciones mal hechas cuando tengo que hacer mucho >>> stubbing >>> > es porque el controller esta haciendo mas de lo que tiene que hacer. >>> > >>> > contras que veo con el stubbing: >>> > si mi diseño del controller no es bueno voy a avanzar muy lento >>> teniendo que >>> > hacer miles de stubbings y mocks >>> > pueden romper el modelo y el spec del controller va a seguir >>> funcionando. >>> > (aqui un punto interesante, el spec de controller es de integracion?) >>> > >>> > pros que veo sin stubbing: >>> > estoy testeando el modelo tambien >>> > puedo ahorrar tiempo en el stubbing >>> > >>> > contras que veo sin stubbing: >>> > no queda claro que estoy probando en los specs se mezcla un poco la >>> cosa, >>> > requiere mas atencion al escribirlos >>> > acciones complejas en el controller pasan desapercibidas >>> > >>> > Seguramente sus puntos de vista seran diferentes y me parecio >>> interesante >>> > abrir la discusión >>> > >>> > Gracias por hacer tan buena esta lista! >>> > >>> > Saluti >>> > >>> > P >>> > >>> > -- >>> > Pedro Visintin . S o f t w a r e A r c h i t e c t >>> > http://www.pedrovisintin.com >>> > >>> > Ruby On Rails Argentina. http://blogs.onrails.com.ar >>> > >>> > Personal page: >>> > http://www.p-e-t-e-r-p-u-n-k.com.ar >>> > >>> > "Todo descontento por aquello que no tenemos parece provenir solamente >>> de >>> > nuestra falta de gratitud por aquello que tenemos" >>> > >>> > >>> > > >>> > >>> >>> --~--~---------~--~----~------------~-------~--~----~ >>> Grupo de Usuarios Ruby del Uruguay - >>> http://groups.google.com/group/ruguy >>> Anular suscripción - [EMAIL PROTECTED] >>> -~----------~----~----~----~------~----~------~--~--- >>> >>> >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > > > -- > -- > --<自由編碼人>-- > Ing. Matias Pablo Brutti > Security Consultant > Email : [EMAIL PROTECTED] > Site: http://www.freedomcoder.com.ar > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > >
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
