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

Pete Muir pmuir at redhat.com
Thu Oct 16 10:14:31 EDT 2008


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 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?
> 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/trunk/presentations/SecuringOpenSource.pdf
>
>
>>
>>>
>>>
>>> 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




More information about the seam-dev mailing list