Re: [seam-dev] Re: Adding a security audit to the Seam QA (release) process

On 16 Oct 2008, at 14:22, Anil Saldhana wrote: > Pete Muir wrote: >> >> On 16 Oct 2008, at 14:04, Anil Saldhana wrote: >> >>> Pete, >>> thanks for the information. I just returned from a software forum >>> conducted by the US Government. I got the feeling that there is >>> some element of internal push toward web 2.0 and open source >>> software in the government space. They are pretty strict on >>> security practices etc and they view open source software as a form >>> of COTS that cannot be trusted. I am sure this extends to >>> governments and financial institutions around the world. :) >>> >>> Security conscious customers want to see a proactive approach >>> (secure design practices etc) rather than a reactive approach >>> (patch management). This can be a key differentiator for us. >>> >>> We have to adopt a global security policy (vulnerability reporting, >>> handling and public notification). I am sure Marc will have the >>> lead role in this. The email alias (security(a)jboss.org) + online >>> vulnerability reporting contact form + 2-way feedback cycle/rapport >>> with the National Vulnerability Databases (Mitre for CVE and NIST >>> for NVSD) is all we need as a start IMO. :) >> >> We feel we are missing a page on jboss.org that outlines our >> notification procedure. We currently describe how you report a >> vulnerability to us, but *not* what we do when one is discovered. We >> need this information in one place, and very clearly stated; We >> have this on http://www.redhat.com/security/team/contact/ but not on >> jboss.org. I think we need a similar page, including a link to >> http://www.redhat.com/security/updates/advisory/ and a link to >> http://www.redhat.com/mailman/listinfo/jboss-watch-list. WDYT? > Yeah, that is what I was referring to. We have to come up with a > policy (which I plan to discuss with MarcS) as to how we do things at > JBoss with reference to security and put it up on > http://jboss.org/security Do you have a timescale for said policy. If it's short (e.g. a month) then we'll hold off going our own way, otherwise we will put up some words on seamframework.org for the interim.

> > > We need to figure out how we handle things - vulnerabilities that are > public information and those that are extremely sensitive in nature > (analogy, the DNS flaw that got leaked - Dan Kaminsky episode). We > should rope in all the .org leads into discussion. :) Ok, where do you want to discuss this?

> > > My presentation from Tuesday is: > http://anonsvn.jboss.org/repos/jbossas/projects/security/security-docs/tr... > > > >> >>> >>> >>> Irrespective of these processes, please continue with your >>> aggressive innovation. ;) >>> >>> Cheers, >>> Anil >>> >>> Pete Muir wrote: >>>> Marc, Christian, Jay and I met and discussed this. Here is the >>>> outcome: >>>> >>>> 1) Create a wiki page and list out the "top ten" web security >>>> problems. This page should list not actual exploits, but the >>>> underlying problems (for example XSS and XSRF). This page will >>>> also link to good resources describing the problem, and common >>>> solutions. Christian and Marc will collaborate to build this page. >>>> >>>> 2) Create a second wiki page to discuss how these problems affect >>>> the various points at which Seam is exposed (e.g. JSF, Wicket, >>>> remoting), the resources collected for (1) can be used to identify >>>> and help close any holes. Currently there is no-one leading this >>>> effort. >>>> >>>> 3) At release time QA will run through the list from (1) and >>>> identify if there are any new features added to Seam which could >>>> be affected. If there are, and the developer has not documented >>>> them on (2), QA will discuss the problem with the developer. >>>> Jay/QA to lead. >>>> >>>> 4) Building out a "Securing your application" chapter and tools >>>> which Seam users can follow to secure their application built >>>> using Seam. An example of this is provide a tool which can >>>> generate a unique token to prevent XSRF attacks. Currently there >>>> is no one leading this, but the same person as (2) should own it IMO. >>>> >>>> If someone would like to volunteer for (2) & (4) who has an >>>> interest in security, that would be great :-) >>>> >>>> We also discussed the process for dealing with found exploits: >>>> >>>> 1) We already tell people to email security(a)jboss.org with any >>>> suspected problems. >>>> >>>> 2) We need to publish the response policy, probably on jboss.org. >>>> Christian will talk to Anil about publishing this, and the jboss >>>> advisory list info. >>>> >>>> 3) It is at the discretion of the JBoss Security Response Team to >>>> decide whether to embargo an issue, and discuss just with a >>>> developer, and not make it public until there is a release or >>>> whether the issue is more general and should be discussed on >>>> seam-dev(a)lists.jboss.org >>>> >>>> >>>> On 6 Oct 2008, at 11:55, Pete Muir wrote: >>>> >>>>> Marc, >>>>> >>>>> Sounds great. I'm in the UK, so GMT+1 atm. Christian, will you >>>>> join us to discuss? >>>>> >>>>> Best, >>>>> >>>>> On 6 Oct 2008, at 11:13, Marc Schoenefeld wrote: >>>>> >>>>>> Hi Pete, >>>>>> >>>>>> that sounds like a good plan, let's schedule some initial >>>>>> planning for >>>>>> next week, because this week I am quite busy with after-PTO >>>>>> workload >>>>>> and SOA testing. How about next tuesday? BTW, which timezone are >>>>>> you >>>>>> in, maybe we can start with a phone chat? >>>>>> >>>>>> The first things that come into my mind are JSF view state >>>>>> injection, >>>>>> XSS in all different kinds, remoting misuse, insecure servlet >>>>>> mappings. >>>>>> During this week I will catch with the current Seam codebase by >>>>>> findbugs-ing through it, and maybe already stumble over the one or >>>>>> other place to start poking into. >>>>>> >>>>>> Cheers >>>>>> Marc >>>>>> >>>>>> Pete Muir wrote: >>>>>>> Hi Marc, >>>>>>> >>>>>>> Something that we've been discussing is the idea creating a >>>>>>> security >>>>>>> audit checklist that will cover Seam and the ways it interacts >>>>>>> with >>>>>>> the outside world; initially, we want to focus on JSF, Seam >>>>>>> Remoting >>>>>>> (Ajax) and Servlet but we will also consider adding in WS >>>>>>> including >>>>>>> JAX-RS, Wicket, GWT and perhaps others, though these are what I >>>>>>> can >>>>>>> think off. This checklist would then be added to the Seam QA >>>>>>> process >>>>>>> (which is run through at release time). >>>>>>> >>>>>>> We were wondering if you would be able to work with us on this? My >>>>>>> suggestion is, that as you (I hope ;-) have a good >>>>>>> understanding of >>>>>>> the general approaches that could be used to exploit a Seam >>>>>>> that you >>>>>>> would be to work with us both on an initial list of areas to >>>>>>> focus on, >>>>>>> and then help us develop the checklist. >>>>>>> >>>>>>> Let us know :) >>>>>>> >>>>>>> Pete >>>>>> >>>>>> >>>>>> -- >>>>>> Marc Schoenefeld / Red Hat Security Response Team