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

[Pete Muir]

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