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

[Anil Saldhana]

Christian,
  great stuff. :)

Marc, maybe we can use seam's knowledge base to consolidate security 
information for all web applications.  The key would be to provide a 
link to security information wherever  folks download our community 
stuff IMO.

Cheers,
Anil

Christian Bauer wrote:
> I'm reactivating this discussion.
>
> Marc started with a basic whitepaper and I've now finished it on the
> wiki with an evaluation of how the most important issues are related
> to Seam:
>
> http://www.seamframework.org/Documentation/WebVulnerabilitiesOverview
>
> This is a new folder in the Knowledge Base so we can add more articles
> if we think that a particular issue applies to Seam.
>
> I'd be interested in feedback especially from Shane, who had some
> questions about Seam Remoting and CSRF. I tried to explain it and show
> why/how we have some missing features in this area. I think we need to
> do something about it - like per-request tokens. However, we might
> want to expand this feature as a general CSRF solution that also works
> with the REST request processing, for example. (And Wicket forms?)
>
> Dan, if you could add the current status of "stateless" view
> processing in JSF 2.0 to the CSRF page, we can go from there and draft
> some recommendations for users.
>
> Still need someone for Wicket security evaluation.
>
> That would complete steps 1) and 2) listed by Pete below.
>
> On Wed, Oct 15, 2008 at 6:53 PM, Pete Muir <pmuir at redhat.com> 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
>>>>
>>>>