Security Minutes 2007-06-15
From MemberWiki
URL: http://www.openajax.org/member/wiki/Security_Minutes_2007-06-15
Contents |
OpenAjax Alliance Security Task Force minutes 2007-06-15
Attendees
- David Boloker <boloker(at)us.ibm.com>
- Alex Russell <alex(at)dojotoolkit.org>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Larry Koved <koved@us.ibm.com>
- Shel Finkelstein <shel.finkelstein@sap.com>
- Naohiko Uramoto <uramoto(at)jp.ibm.com>
- Todd Kaplinger <todkap(at)us.ibm.com>
- Gideon Lee <glee(at)openspot.com>
- Bertrand Le Roy <bleroy (at) microsoft.com>
- Yucel Karabulut, SAP
- Suresh N. Chari <schari(at)us.ibm.com>
- Frederik De Keukelaere <EB41704(at)jp.ibm.com>
Original Agenda
- Quick decisions (hopefully at first phone call)
- What should this task force work on at first? (e.g., write up use cases and scenarios, including associated security threats and counter measures)
- How to decide what to work on next? (e.g., evaluate the use cases and scenarios writeups, then decide on a plan of action)
- Date/time and frequency for task force phone calls
- Initial discussion about the list of security-related activities that OpenAjax might pursue?
- Educational-focused documents such as white papers
- Technical-focused documents such as Best Practices
- Case studies which highlight security "success" stories
- Position papers, such as how browsers should evolve to support convenient but secure mashups
- Are there any technical specs that we should pursue?
- Initial discussion about how forward-looking should we be?
- Just focus on today's desktop browser mashup problem?
- Try to drive industry towards better solutions to desktop mashup scenarios?
- Try to drive industry towards better solutions for server-side mashup scenarios?
- What about mobile security scenarios?
- Extend into widgets security?
- What are the key use cases and scenarios we need to address?
- Should we capture uses cases and scenarios on wiki pages?
- Any other business?
- Wrap up
Minutes
Topic: Key scenarios
Larry: Questions or comments on the agenda and what we should cover?
(silence)
Larry: Then lets talk about use cases and scenarios, associated threats, and how to mitigate those threats. Let's go around the table and consider types of mashups. Proxy servers or content delivered directly to the browser from browser request. What communications patterns are of interest.
IBM
David (for IBM): Clear usage patterns for mashups are emerging. Consumer space and non-consumer. Consumer-space, where classic example is mashup with Google maps combined with other types of data on top, using an HTML fragment, that shows lat/long for points on the map. JavaScript from another source to be used on your page. So generally, at least two sources of data, and question is what will be executed on client and what will happen to the DOM.
Larry: Do you see content coming through a proxy or pulled in from multiple domains on the client?
David: Both. Consumer cases, there will be a proxy server from the mashup provider. Single proxy -- Zillow is done on the server. But some mashup makers will allow mashups to be assembled on the glass. Both are valid.
Larry: Are we seeing information including code passed down via the proxy or proxy just passes content?
David: Second case now. Passing content.
Larry: Any cases where code is sent via proxy.
David: I haven't seen it yet.
Alex: Google IG has plugins that run in the proxy. But Google and AOL both transform and verify before sending down.
Uramoto: We need to look at both the mashup and non-mashup cases (ie single page) for both XSS and CSRF.
Dojo
Alex (for Dojo): I see distinction between server-side and client-side being a result of security decisions. "Simple mashups" are not client-side. Client-side only when security isn't as important and server-side such as Enterprise when quality of service and security concerns matter more. Lack of "trust" on client-side mashups. Don't know if client-side is that interesting, but if it is, then my main interest is around sandboxing. Also, side-by-side toolkit loading gets lots of requests, where security is one concern, but maybe security interest can help us address the side-by-side loading issue. Also, interested in making sure the Open Web doesn't get FUD'd by security issues. No specific usage scenarios.
Microsoft
Bertrand (for Microsoft): I see 3 key problems. (1) cross-domain requests, (2) Isolation, (3) When on client, most web services are sending a key to all of your users. So the key can't be kept secret if you support client-side.
Larry: So you would need some sort of client-side cryptography.
OpenSpot
Gideon: The scenario not talked about is the WebTop scenario. Standalone apps from different servers. Want generic protocol for things like copy/paste, e.g., text from one editor to another. For end user mashups, not developer mashups.
Gideon: There is a blurring between mashups and other things. We need an architecture that is general but also covers mashups. A cross-domain communications model. But mashups are the immediate need.
What about GreaseMonkey
Larry: What about GreaseMonkey when there is no chrome. Anyone see use of GreaseMonkey catching on and being important? Is that an issue or concern?
Bertrand: When app removes chrome or replaces chrome?
Larry: I have seen things such as global desktop.
Bertrand: Isn't that a concern for browser vendors?
Jon: I think that's a concern being addressed in other organizations, like W3C and the browser vendors. Our focus and where we can add value is around mashups.
SAP
Shel: The term mashup has been used for both client and servier. Combining data and code from multiple sources, a range of clients and servers. The question is how to exchange data but without harm? Issues about technology, safe topologies, and also business issues around trust relationships. At IEEE conference, we identified about 30 separate issues. Out there is a web site. We need to do a combination of best practices, what can be done safely now, how to pick technologies, how to influence technologies going forward.
Larry: Any other technologies or communications patterns you see at SAP that we haven't discussed yet?
Shel: Not only notion of data trust, but also validation and business to business scenarios. Not only trusting one company, but trusting the companies they trust.
Larry: Transitive trust. That's a deep topic. Any pointers to information that covers this?
Shel: No. I am hoping that we can start to address this.
David: Pretty clear we have 2 sets of discussions. Technical, end to end scenarios where we need to focus. Then once we have a list, then have marketing committee write up the issues.
Jon: You are saying we have both a technical and an educational role to play.
David: Absolutely.
Shel: Start to make a list of resources and issues. There isn't a lot of information about how to be safe. There are the "sky is falling" presentations (some from consultants). There are no "here's the safe way" to make mashups.
David: I was just saying there are already a bunch of lists, but not concise. We could pursue "if you do the following, you'll be safe" but I don't think that's true. It depends on who implements. The right person will help things, but the wrong person implementing might make things worse.
Alex: Traditionally, you provide tools that people can use. For example, tools now reduce the number of SQL injection attackes. Do we want to look at that?
Jon: Yes. We want to look at tools and educational material. But the focus should be mashups and we have to determine if we actually can provide value.
David: What we should do: (1) At a minimum, help educate. That is likely to provide value. Something anyone can pick up and understand. (2) Try to get people together and involved to move things forward.
Yucel: We need to define scenarios and interaction patterns, and attempt to understand mashup problems that happen. Mashup interaction patterns will follow other interaction patterns that have existed before. We need to look at security protocols and standards that we can apply to solve these scenarios, such as SAML and XACML. Can it be used for mashup identity issues?
Larry: Sounds like we want to come up with a set of scenarios, both client-side and server-side. Another one we haven't raised so far: for several services to poxy and then forward to client. Do we want to consider multiple intermediary scenarios?
Jon: Could you give an example?
Larry: Stock quote is a raw data feed. Then something like Dun & Bradstreet offers separate services, which are combined. Do we trust the data from the combined service? Sometimes there are confidentiality situations and agreements on the original data.
Jon: For OpenAjax, we usually address issues where client is involved. From client perspective, isn't it just a REST call to a service and its the back end's job to deal with data issues?
Larry: Like Shel says, how can the client be sure the data is good.
Shel: To solve the infinite N problem, it is often good to start off with trying to solve case 1.
Gideon: Single sign-on - do we want to do anything with that?
Larry: Good question. Microsoft has Cardspace in IE7 which allows security tokens on your computer for credentials for multiple sites. Similar thing is hosted at Eclipse. Over next two years likely to take root.
Alex: OpenID is also addressing this.
Larry: So, maybe we should talk about *leveraging* federation.
David: Should point to these other groups. Federation is a huge topic.
Larry: Does this group want to talk about how to use federation?
David: Yes.
Shel: So, defining how to do, probably not in our charter, but how to use, yes.
David: Yes.
Gideon: What sort of delivery do you assume?
Larry: If you have Cardspace, Higgins or OpenId, here's how to use it and here are the risks.
Jon: In other words, what you would see in a white paper.
Larry: Then down the road, maybe some frameworks.
Topic: Next steps
Larry: Suggest that a few of us take the minutes and find areas of agreement.
Larry: Regular phone calls or wiki or email?
David: Or both
Larry: For regular phone calls, is this time slot good? How about 1 hour earlier for the Japanese folks
(ok with everyone)
Larry: Next meeting in 2 weeks, but one hour earlier. Most important thing is to make progress on the use case scenarios.
Shel: Good suggestion. But do we have critical mass?
Jon: About 12 people, about 7 companies, which is bigger than most of our other meetings. I have found it's OK to have a smaller number draft proposals, but you need more eyes to review proposals.
Shel: OK
Larry: Maybe we are missing critical mass of expertise in certain technical areas. IBM has some experts that we can bring in for certain topics.
Larry: We are looking for volunteers to write up key use cases. Maybe one on simple proxy and one on client mashups.
Pointer to IEEE web site: http://seclab.cs.rice.edu/w2sp/2007/
???: Need a common vocabulary to discuss scenarios & issues under discussion.
Larry: So, next meeting in 2 weeks, but one hour earlier.
