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

[Shane Bryzak]

Rodney Russ wrote:
> 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.
> Any reason why we wouldn't look to existing lists for the top web 
> application exploits in the "wild"?  For example:
>
> * The OWASP top ten:  http://www.owasp.org/index.php/Top_10_2007
> * The Web Application Security Consortium's Threat Classification:  
> http://www.webappsec.org/projects/threat/

I took a look at both of these, I especially liked the second one (WASC) 
as they provide a PDF document containing details of known attack types 
broken down by class (authentication, authorization, client-side, 
command-execution, information disclosure, and logical attacks).  I 
would ultimately like to see a table detailing how Seam addresses each 
of these vulnerabilities, and I think an additional chapter in the docs 
as Pete suggested would be the best place for this (item 4 in the task 
list).  The great thing about the WASC document was that it gave clear 
examples of how each of the exploits worked -  I think we need to work 
the same kind of explanations into the documentation also.  For example, 
rather than just say 'this is how Seam is secure against session 
fixation attacks' we actually explain what a session fixation attack is.
>>
>> 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
>>>>
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev