Ajax Security

Sang Shin Java Technology Evangelist Sun Microsystems, Inc.

1

Disclaimer & Acknowledgments

Even though Sang Shin is a full-time employee of Sun Microsystems, the contents here are created as his own personal endeavor and thus does not necessarily reflect any official stance of Sun Microsystems on any particular technology Many slides are created from the contents posted in dojotoolkit.org website

Topics
Guidelines from OWASP Guidelines from Douglas Crockford Security threats (in Ajax environment)

Client side Suggested Guidelines (from OWASP)

Use .innerText instead of .innerHtml

The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.

Don't use eval

Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.

Don't rely on client logic for security

Hackers can use a number of browser tools to set breakpoints, skip code, change values, etc. Never rely on client logic.

Don't rely on client business logic

Make sure any business rules/logic is duplicated on the server side since a user can bypass the needed logic and do something silly, or worse, costly.

Encode Data before use

When using data to build HTML, script, CSS, XML, JSON, etc., make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning. Data should be properly encoded before used in this manor to prevent injection style issues, and to make sure the logical meaning is preserved. Check out the OWASP Encoding Project.

Avoid writing serialization code

This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality.

10

Avoid building XML dynamically

It could cause XML injection bugs, so stay way from this or at least use an encoding library to make attributes and element data safe. > Just like building HTML or SQL Check out the OWASP Encoding Project.

11

Never transmit secrets to the client

Hackers can find them out Keep all that secret stuff on the server please.

12

Don't perform encryption in client side code

Use SSL and encrypt on the server!

13

JSON and Browser Security (from Douglas Crockford)

Never Trust The Browser

The browser cannot and will not protect your secrets, so never send it your secret sauce. Keep your critical processes on the server. If you are doing input validation in the browser, it is for the users convenience. Everything that the browser sends to the server must be validated.

15

Keep Data Clean

The eval function can take a text from XMLHttpRequest and instantly inflate it into a useful data structure. Be aware however that the eval function is extremely unsafe. If there is the slightest chance that the server is not encoding the JSON correctly, then use the parseJSON method instead.
> The parseJSON method uses a regular expression to ensure that

there is nothing dangerous in the text. > The next edition of JavaScript will have parseJSON built in. For now, you can get parseJSON at http://www.JSON.org/json.js.

On the server side, always use good JSON encoders and decoders. 16

Script Tags
Script tags are exempt from the Same Origin Policy. That means that any script from any site can potentially be loaded into any page. There are some very important consequences of this. Any page that includes scripts from other sites is not secure. External scripts can be used to deliver ads or search result options, or logging, or alerts, or buddy lists, or lots of other nice things. Unfortunately, the designs of JavaScript and the DOM did not anticipate such useful services, so they offer absolutely no security around them. Every script on the page has access to everything on the page.
17

Security Threats In Ajax Environment

Universal XSS
Exploits flaws of browsers

19

HTTP Request Splitting

Exploits the flaws in the asynchronous requests
> Hackers can inject arbitrary headers when HTTP request is

built

20

Questions?