Hi Sachiko,
Sounds good to me, with my only concern being that AJAXWorld might not like
an article that is too heavy on links/references versus content. What I
suggest is that you add inline references as you feel is appropriate and
then the rest of us can take a look at it. Any chance you could do this
within the next 24 hours? The arrangement with AJAXWorld was for them to
review a final and complete draft from us by August 15 (2 days) from which
their editorial staff would review and edit.
Thanks.
Jon
Sachiko Yoshihama
<SACHIKOY at jp.ibm.
com> To
Sent by: OpenAjax Alliance Security Task
marketing-bounces Force <security at openajax.org>
@openajax.org cc
marketing at openajax.org
Subject
08/13/2007 12:10 Re: [OpenAjaxMarketing]
AM [OpenAjaxSecurity] Some comments on
Ajax and Mashup Security
whitepaper draft
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: To
security-bounces at openajax "Finkelstein, Shel"
.org <shel.finkelstein at sap.com>
cc
marketing at openajax.org,
2007/08/09 04:04 security at openajax.org
Subject
Re: [OpenAjaxSecurity]
Please respond to [OpenAjaxMarketing] Some comments on
OpenAjax Alliance Ajax and Mashup Security
Security Task Force whitepaper draft
<security at openajax.org>
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
Inactive hide details for "Finkelstein, Shel" <shel.finkelstein at sap.com>
"Finkelstein, Shel" <shel.finkelstein at sap.com>
"Finkelstein, Shel"
<shel.finkelstein at sap.com
>
Sent by:
marketing-bounces at openaja
x.org To
<security at openajax.org>
08/07/2007 06:53 PM
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.orghttp://openajax.org/mailman/listinfo/marketing
_______________________________________________
security mailing list
security at openajax.orghttp://openajax.org/mailman/listinfo/security
_______________________________________________
marketing mailing list
marketing at openajax.orghttp://openajax.org/mailman/listinfo/marketing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070813/3cd9a9ac/attachment-0001.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/20070813/3cd9a9ac/attachment-0006.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic06714.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/3cd9a9ac/attachment-0007.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/20070813/3cd9a9ac/attachment-0008.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 18622573.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/3cd9a9ac/attachment-0009.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 18336910.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/3cd9a9ac/attachment-0010.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 18445717.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20070813/3cd9a9ac/attachment-0011.gif