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

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?

> > > 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