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

[Rodney Russ]

Pete Muir wrote:
>
> On 22 Oct 2008, at 12:05, Anil Saldhana wrote:
>
>> Shane Bryzak wrote:
>>> 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/
>
> Agreed, I hope this is part of the research that Marc and Christian 
> will do :-)
So, what I was thinking of by suggesting these two resources is that an 
IS/IT shop in a large enterprise will look to existing "standards" when 
asking about or looking for information regarding (web application) 
security.  Even if we develop an excellent resource of our own, I 
believe questions from developers will come up that are directly related 
to either of these two "standards".  For example, the Payment Card 
Industry Data Security Standard (PCI DSS) - 
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml - 
which is important in the US for companies handling credit card 
transactions explicitly references OWASP and codifies it in the 
requirements for compliance.  Keep in mind that I'm not advocating the 
correctness of either of these (although Jeremiah is an extremely bright 
security expert) just trying to anticipate behavior.
>
>>>>
>>>
>>> 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.
>
> Or if we can get a permalink to a good resource....
>
> BTW Dan is going to coordinate (2) and (4)
>
>>>
>> Both OWASP and webappsec are the results of Jeremiah Grossman, CEO of 
>> Whitehat Security.  So they will have the same contents.  You can 
>> combine them to get the list. :)
>>
>> I agree with Shane that we need to explain the vulnerabilities in 
>> addition to listing them.
>>>>>
>>>>> 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
>>>>>>>
>>
>