9:20 a.m.
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(a)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(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
>>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev