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

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

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. :)

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