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

Jon Ferraiolo jferrai at us.ibm.com
Wed Aug 8 12:04:16 PDT 2007

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


             <shel.finkelstein                                          To 
             @sap.com>                 <security at openajax.org>             
             Sent by:                                                   cc 
             marketing-bounces         marketing at openajax.org              
             @openajax.org                                         Subject 
                                       [OpenAjaxMarketing] Some comments   
                                       on Ajax and Mashup Security         
             08/07/2007 06:53          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
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

* 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


Shel _______________________________________________
marketing mailing list
marketing at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070808/c9b66b7f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070808/c9b66b7f/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic05382.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070808/c9b66b7f/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070808/c9b66b7f/attachment-0002.gif 

More information about the security mailing list