[OpenAjaxSecurity] [OpenAjaxMarketing] Some comments on Ajax and Mashup Security whitepaper draft

Sachiko Yoshihama SACHIKOY at jp.ibm.com
Mon Aug 13 00:10:38 PDT 2007


Hi Jon, Shel, all,

As  for the Shel's second comment:

> * There are many papers and presentations describing threats and best 
practices, and I believe that some of the material in this paper may come 
from them. It would be appropriate to reference some of those papers, in 
place in the paper, especially if it's planned for publication in a 
magazine.

I am also a bit concerned about describing attacks and protection 
techniques without referring to the original sources. For instance, we did 
not invent JSONP or JSON Hijacking and the most of the original ideas came 
from the whitepapers and weblogs. I feel it is more appropriate to refer 
to these original sources to acknowledge the original authors.
(I am not quite sure about the writing style of AJAX World, but I will 
definitely insert in-line references if we are writing a conference paper)

On the other hand, we already have several in-line references as 
hyperlinks in the whitepaper. Would it be possible to translate these 
hyperlinks into the form of in-line references when converting the Wiki 
page to the AJAX World article? I do not think we need to include all 
references in the Resources page. We can include the most directly related 
ones (as the length limit allows) and refer to the OpenAjax Resources page 
for the rest.

Sachiko
-- 
YOSHIHAMA, Sachiko (FAMILY, Given)
IBM Tokyo Research Laboratory
Tel: 046-215-4828 / TieLine: 808-4828
E-mail: sachikoy at jp.ibm.com



Jon Ferraiolo <jferrai at us.ibm.com> 
Sent by: security-bounces at openajax.org
2007/08/09 04:04
Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org>


To
"Finkelstein, Shel" <shel.finkelstein at sap.com>
cc
marketing at openajax.org, security at openajax.org
Subject
Re: [OpenAjaxSecurity] [OpenAjaxMarketing] Some comments on Ajax and 
Mashup Security whitepaper draft






Hi Shel,
Great suggestions. I will update the abstract to do a better job of 
explaining the target audience, the purpose of this white paper, and 
explain the context of OpenAjax Alliance and its security task force. 
However, this needs to be brief and to the point. 

Regarding the "many papers and presentations describing threats and best 
practices" and whether we should instead point to other resources, these 
are high-level comments that would have been more appropriate a couple of 
months ago when the Security TF and Marketing WG (also Steering Committee) 
were first talking about possibly doing a white paper on security. At this 
point, the white paper is very far along and is now in the detailed 
editorial review stage where we are correcting grammar errors and writing 
style errors. We already have negotiated with AJAXWorld magazine about the 
content and length of an article whose submission due date is just next 
week (Aug 15). Putting that all aside, I will attempt to explain "the 
plan" regarding the white paper. The white paper (to be posted on the 
OpenAjax Web site) and the derivative AJAXWorld article are overview 
articles that are meant to give an Ajax developer and his management team 
an opportunity to go up learning curves quickly about security issues 
related to Ajax applications and the new phenomenon known as mashups. The 
overview article then has extensive backup from our wiki pages that 
provides (hopefully) convenient organization of various hyperlinks to Web 
resources which go into greater depth on various security issues. All of 
this activity (white paper plus resources wiki page) is consistent with 
the mission and purpose of OpenAjax Alliance, as described on our Web site 
(http://www.openajax.org/about.html):
-----------------
The OpenAjax Alliance provides value to the software community on both 
technical and marketing fronts. With its technology initiatives, which 
include specifications and open source software, the alliance will address 
key Ajax interoperability issues so that developers can successfully use 
multiple Ajax technologies within the same Web application. With its 
marketing initiatives, the alliance will help educate the community on how 
to achieve success with Ajax using open technologies. 
-----------------

With this particular white paper, we decided purposely to focus only on 
issues directly relevant to Ajax and mashups and not general Web security 
issues under the assumption that OpenAjax Alliance is mainly about Ajax 
and we hope that the rest of the industry is doing an adequate job with 
general Web security issues, such as lists of sites to include in a 
blacklist or whitelist. (But this is something we might consider down the 
road in the context of mashups because we might find that it becomes 
important to have blacklists for mashup components that are irreputable.)

Regarding section 2.1.2 and its schizophrenia, I can see what you mean, 
but it should be easy to fix. Even with the craigslist+gmaps example, 
there is an implicit mashup container which allows the mashing, and the 
cases in the 2nd paragraph are instances in Web sites such as Facebook 
adding mashup container capabilities to some of their Web pages. I think a 
little wordsmithing is all we need.

Regarding putting in explicit section numbers, this is mainly a limitation 
of the Mediawiki technology we are using with our wiki. Maybe it is 
possible to get section numbers inserted automagically by messing with the 
PHP and CSS files within our wiki setup, but it probably isn't easy to do. 
We could put the section numbers in the body text manually, but then the 
TOC would show duplicate section numbers. In the past, we have lived with 
this deficiency as we did collaborative development on the wiki, but then 
what happens is that magically the section numbers appear when converting 
into an HTML file for publication on the main site because of the wonders 
of copy/paste from the wiki into MSWord.

Back to one of your higher level questions, "the charter and mission of 
OpenAjax Security...is not clear". The basic premise with any task force 
at OpenAjax Alliance is that the task force should be short-lived 
(measured in <n> months) where the members of the TF work together towards 
making recommendations about what activities OpenAjax Alliance should 
pursue in the given area and what formally chartered committees should 
manage those activites. Right off the bat, the TF decided that it was 
obvious that the security task force could get its feet wet by working on 
a white paper (to be published by Mktg WG), But going forward, there are 
open issues about other Ajax security activities and optimal process for 
those activites. One idea to consider is that we promote the Security Task 
Force into a Security Working Group, where one task would be to develop 
and maintain the various wiki pages on security issues with the goal of 
maximizing usefulness to the community. A second activity would be 
involvement (probably review and coordination) in any secure mashup 
technical work that seems likely to happen in the context of OpenAjax Hub 
1.1. If you have opinions on these various organizational and process 
questions, I would love to hear them.

Jon


"Finkelstein, Shel" <shel.finkelstein at sap.com>


"Finkelstein, Shel" <shel.finkelstein at sap.com> 
Sent by: marketing-bounces at openajax.org 
08/07/2007 06:53 PM



To

<security at openajax.org>

cc

marketing at openajax.org

Subject

[OpenAjaxMarketing] Some comments on Ajax and Mashup Security whitepaper 
draft





Hi. As you know, Yuecel Karbulut is representing SAP on OpenAjax Security, 
but I thought that I would send a few brief high level thoughts for your 
consideration on the current OpenAjax Security Whitepaper (at 
http://www.openajax.org/member/wiki/WP3_-_Ajax_and_Mashup_Security), 
especially since I won't be able to be on Friday's call. The paper has a 
lot of strong material in it, and I'm sure that it will continue to 
improve before it's sent out. 
* The charter and mission of OpenAjax Security are not clear from the 
paper. Even though this is an OpenAjax white paper, it's a good 
opportunity to publicize this group. Also, intro might identify the 
audience for the whitepaper, and its purpose. This paper doesn't aim to be 
an exhaustive study of Ajax security issues; it's more of an introduction 
to some issues, with some suggested practices and pointers to additional 
material (next point). And that's fine, and it's even better to make that 
clear. 
* There are many papers and presentations describing threats and best 
practices, and I believe that some of the material in this paper may come 
from them. It would be appropriate to reference some of those papers, in 
place in the paper, especially if it's planned for publication in a 
magazine. (Referring to Resources listed on the OpenAjax website is good, 
but is it enough?) For example, I think that we might point to Douglas 
Crockford's webpage, papers and browser improvement goals. Other 
bibliographical references would help explain terms (e.g., JSONP), provide 
access to more detailed discussions (and other experts), and give credit 
to people who've been raising and addressing these issues before OpenAjax 
Security existed. 
* We know that that these are just some of the threats associated with 
Ajax and mashups. As I mentioned above, I suggest that this paper should 
be clear that this describes many of the more common issues. And I like 
best practices a lot, but perhaps we should clarify how much these best 
practices accomplish (avoiding some common errors, but not a panacea), so 
that we don't over-promise and mislead. Also, some other common practices, 
such as whitelisting and blacklisting of sites/services/URLs, aren't 
discussed. (There is a discussion of blacklisting and whitelisting for 
Input Value Checking, but that's a very different issue.) 
* Section 2.1.2 seems schizophrenic. The first paragraph speaks of the 
archetypal mashup example, annotating Google Maps using Craigslist, which 
involves explicitly programmed composition, while the second paragraph 
describes an event-based composition framework for mashups. These are 
different definitions, with different security implications. (Minor point: 
Can we include section numbers within the doc, as well as in the Table of 
Contents?) 
Regards, 
Shel _______________________________________________
marketing mailing list
marketing at openajax.org
http://openajax.org/mailman/listinfo/marketing
_______________________________________________
security mailing list
security at openajax.org
http://openajax.org/mailman/listinfo/security

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0010.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0011.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0012.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0013.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0014.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0015.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0016.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0017.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0018.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/f7fb280f/attachment-0019.gif 


More information about the security mailing list