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

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/

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

> 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(a)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(a)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 >>>>>