[Owasp-ajax] Some Roadmap Ideas

Thu Sep 14 10:27:30 EDT 2006

It's really important to "interpret" security principles, vulnerabilities,
countermeasures, etc... for new technologies that come out like Ajax.
Developers have shown an absolutely stunning ability to ignore security
lessons learned when moving to new technologies (sigh).  So even if it is
the same old stuff, it's not enough to say "input validation" -- we have to
say "when you parse JSON, you have to send it to a validate method it before
you eval() it."  Stuff like that.

--Jeff

-----Original Message-----
From: owasp-ajax-bounces at lists.owasp.org
[mailto:owasp-ajax-bounces at lists.owasp.org] On Behalf Of Illés Péter
Sent: Thursday, September 14, 2006 9:57 AM
To: owasp-ajax at lists.owasp.org
Subject: Re: [Owasp-ajax] Some Roadmap Ideas

Gentlemen,

Good get going! When John mentions that most of the vulnerabilities are
already covered by the Top Ten, I couldn't agree more, and that is fortunate
too :-). I second Anurag's thoughts about a centralized repository about
vulnerabilities (their reproduction and their presence/absence in various
toolkits) and about hacking incidents as well.

What we can emphasize is that certain aspects of AJAX and current toolkit
examples are making known issues worse.

One thing that comes into my mind is related to authentication: while
earlier the authentication page was always a new page protected with SSL
(and hopefully was opened in a new window to break out of frame cross
scripting) now with a few tens to hundreds kilobytes of AJAX framework code
already downloaded, and extensive state+business logic maintained in the
browser (rendering a public front-end portal), some web applications log in
in the current browser context in a background XMLHTTPRequest that is many
times not protected by SSL either. So the public to authenticated transition
became much weaker. I understand the rationale: the current user context is
too important to loose (and costly in terms of bandwidth, too), and it is
elegant to have a little box doing the login, but the net result is weakened
security.

Validation is also a key point: it is moved to the client side to enhance
interactivity, but it should be done on the server side too, to maintain
security. The best would be to work out a common architecture to be able to
describe the validation rules once, and then there would be a client-based
and a server-based engine as well performing the same validations
(injections covered). The best case would be a cross-frameworks standard way
of expressing business rules, but this is getting a bit far fetched :-)

Client-side business rules also open the door to revealing fundamental
business-confidential information. Until now this functionality was well
protected in the business tier on the server side. Now this is sitting in
the browser in plain JavaScript English (obfuscation or Flash-based
solutions may help somewhat). And sometimes confidential data is transferred
to the client to be processed and then authenticated results presented, but
the secret data is in the client browser too.

And centralization of authentication, authorization and validation comes to
my mind, as well: with all the separate little XMLHTTPRequests running
around it is tempting to become "modular" and decentralized (even scaleable:
separate servers can handle the requests) but this leads to a security
nightmare.

Security would require to leave as much of the functionality on the server
as possible, usability would require bringing as much onto the client as
possible, scalability is somewhere between (is it a bigger load for the
servers to run the business rules, or to transfer the data?). An open
dialogue should be started about the best tradeoffs for all parties. 

Part of this dialogue could be to look at the possibilities on the client
side to better protect the code and data. This could be a hardened browser
with some functionality for the server to be able to verify the soundness of
the client code. // What a coincidence: I've just received the Sept volume
of Communications of the ACM and there is an article about something similar
on page 45 entitled "Externally verifiable code execution" (have not read
yet).

This leads to the suggestion that we should try to get together an
industry-wide team. So some roadmap goals might be:

- assemble a team of experts from the most prominent open or closed source
AJAX toolkit vendors
- also invite members from the browser manufacturers as their participation
would be paramount in securing the client side
- industry representatives from high-security (e.g. banking) institutions
would be welcome as well
- define the most fundamental issues (together 
- work out solutions to these issues and create a certification program for
vendors that would demonstrate their commitment to user security
- raise awareness of the fundamental issues and of certification benefits
- develop/enhance testing tools

OK, now that was a little bit more than I set out to tell :-) - my
apologies. Is a bit far-fetched, too... Thoughts?

Peter

-----Original Message-----
From: owasp-ajax-bounces at lists.owasp.org
[mailto:owasp-ajax-bounces at lists.owasp.org] On Behalf Of
anurag.agarwal at yahoo.com
Sent: Wednesday, September 13, 2006 5:01 AM
To: John Creason; owasp-ajax at lists.owasp.org
Subject: Re: [Owasp-ajax] Some Roadmap Ideas

John - 

I think its a great start. Here are a few things of the top of my head, they
may sound a little ambitious in the beginning but we might wanna put them on
the roadmap.

1. In addition to the Ajax vulnerabilities, we may also need to showcase
some of the regular functionality which can be used in a malicious way. For
eg realtime keylogging using Ajax
2. Since we are going to identify vulnerabilities in Ajax, how about
maintaining a database of Ajax vulnerabilities which can be used
independently or can act as an input to a tool which OWASP or some other
party might want to create like appscan, webinspect, etc
3. Another idea which came to my mind was maintaining an Ajax incident
database where we have hacking incidents using Ajax. This may sound too
ambitious but i thought i will share it with you guys.

thoughts / suggestion?

anurag

----- Original Message ----
From: John Creason <john.creason at smartsheet.com>
To: owasp-ajax at lists.owasp.org
Sent: Tuesday, September 12, 2006 6:54:53 PM
Subject: [Owasp-ajax] Some Roadmap Ideas

ALL -

OK - let's get the dialogue started.  I've been thinking about this a lot,
and I have felt sort of stuck.  I think that a most of the issues that need
to be addressed in order to make AJAX secure are really things which we
already know about: authentication, access control, etc.  I am sure that
with everyone's ideas, we can get a roadmap pulled together quickly.

Here are some of my ideas about the AJAX Security Roadmap

1) Identify short list of top AJAX security vulnerabilities.

Include instructions on how to determine if your code is vulnerable, and
include recommendations on how to defend against a related attack.

This is similar to the top-ten, but it's AJAX focused.  My expectation is
that nearly every one of these issues will already be covered in Top Ten or
somewhere else in the OWASP materials.

We could address any AJAX specific aspects of the vulnerability and
reference other materials as needed

2) Complete AJAX Chapter of OWASP Guide.

There are a number of sub-sections which are just stub.  My recollection is
that most of these are on the various injection attacks.  These injection
attacks can exist inbound to the AJAX client or inbound to the web server -
need to address both sides of the injection threat.

3) Sample Code

With AJAX , developers are going to be using JavaScript to build content for
requests.  Some JavaScript samples could be helpful.

A couple simple samples come to mind.  In both cases, I have production code
which could be donated as examples:

toSafeXML(string) - Escapes all unsafe characters from the supplied string
using standard XML escape sequence.  It is important that all user supplied
data is made safe before attempting to include that data in an XML document
for transport from an AJAX Client to the Application Server.  This sample
code uses a "whitelist" approach and will escape all non-listed characters
using standard XML escape encoding.

toFormUrlEncoded(string) - This function takes a string and efficently does
the Form URL Ecoding.  This is a necessary step to submit an AJAX request
via POST.  See OWASP guide for details on why we want to encourage people to
only use POST for sending AJAX requests.

Other ideas?

John D. Creason
Smartsheet.com
john.creason at smartsheet.com
(o) 425-296-2488
(m) 425-760-0985

www.smartsheet.com 

_______________________________________________
Owasp-ajax mailing list
Owasp-ajax at lists.owasp.org
http://lists.owasp.org/mailman/listinfo/owasp-ajax

_______________________________________________
Owasp-ajax mailing list
Owasp-ajax at lists.owasp.org
http://lists.owasp.org/mailman/listinfo/owasp-ajax