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

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

Pete, thanks for the information. I just returned from a software forum conducted by the US Government. I got the feeling that there is some element of internal push toward web 2.0 and open source software in the government space. They are pretty strict on security practices etc and they view open source software as a form of COTS that cannot be trusted. I am sure this extends to governments and financial institutions around the world. :) Security conscious customers want to see a proactive approach (secure design practices etc) rather than a reactive approach (patch management). This can be a key differentiator for us. We have to adopt a global security policy (vulnerability reporting, handling and public notification). I am sure Marc will have the lead role in this. The email alias (security(a)jboss.org) + online vulnerability reporting contact form + 2-way feedback cycle/rapport with the National Vulnerability Databases (Mitre for CVE and NIST for NVSD) is all we need as a start IMO. :)

Irrespective of these processes, please continue with your aggressive innovation. ;) Cheers, Anil 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. > > 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

Pete Muir wrote: > > On 16 Oct 2008, at 14:04, Anil Saldhana wrote: > >> Pete, >> thanks for the information. I just returned from a software >> forum conducted by the US Government. I got the feeling that there >> is some element of internal push toward web 2.0 and open source >> software in the government space. They are pretty strict on >> security practices etc and they view open source software as a >> form of COTS that cannot be trusted. I am sure this extends to >> governments and financial institutions around the world. :) >> >> Security conscious customers want to see a proactive approach >> (secure design practices etc) rather than a reactive approach >> (patch management). This can be a key differentiator for us. >> >> We have to adopt a global security policy (vulnerability >> reporting, handling and public notification). I am sure Marc will >> have the lead role in this. The email alias (security(a)jboss.org) >> + online vulnerability reporting contact form + 2-way feedback >> cycle/rapport with the National Vulnerability Databases (Mitre for >> CVE and NIST for NVSD) is all we need as a start IMO. :) > > We feel we are missing a page on jboss.org that outlines our > notification procedure. We currently describe how you report a > vulnerability to us, but *not* what we do when one is discovered. > We need this information in one place, and very clearly stated; We > have this on http://www.redhat.com/security/team/contact/ but not > on jboss.org. I think we need a similar page, including a link to http://www.redhat.com/security/updates/advisory/ > and a link to http://www.redhat.com/mailman/listinfo/jboss-watch-list > . WDYT? Yeah, that is what I was referring to. We have to come up with a policy (which I plan to discuss with MarcS) as to how we do things at JBoss with reference to security and put it up on http://jboss.org/security

We need to figure out how we handle things - vulnerabilities that are public information and those that are extremely sensitive in nature (analogy, the DNS flaw that got leaked - Dan Kaminsky episode). We should rope in all the .org leads into discussion. :)

My presentation from Tuesday is: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-docs/tr... > >> >> >> Irrespective of these processes, please continue with your >> aggressive innovation. ;) >> >> Cheers, >> Anil >> >> 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. >>> >>> 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

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

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

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 :-)

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

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&gt; 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 >>> >>>

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.

user's session. All the state necessary to rebuild the view and process the user-initiated event is sent along in the form post. The user could request the form on one day and submit it days later assuming that other session data isn't required (e.g., a login or comment form). This portability is not present in server-side state saving. The browser merely sends an identifier for looking up the component tree in the session. Without the session, there is no component tree. When that happens, the only reasonable thing for JSF to do is to throw and |ViewExpiredException| or simply render the page again without processing any events. ...that is, until Facelets came along. Facelets offers a "solution" to the stale form problem. By setting the |facelets.BUILD_BEFORE_RESTORE| context-param to true, you can have Facelets reconstruct the component tree in the restore view phase if the one in the session has expired (or the session as a whole expired). This would seem to match the behavior of client-side state saving. It does not. The reason is that the contract of requiring an existing view state to exist is now absent and a postback is no different than a page action. A form on a plain HTML page can now submit a post request directly to a JSF application (you do need an empty |javax.faces.ViewState| hidden field for it to work). To make things even more troubling, Facelets has become the standard view handler in JSF 2.0 and this behavior of Facelets is now the default. So what do we do? Well, as it turns out, because of a recent spec change, the "build before restore" feature has been inadvertently disabled in Mojarra, so we may not have to worry about it after all in JSF 2.0. But if it does get "fixed"...