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

[Anil Saldhana]

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

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