AJAX Security Research and Findings - Round 2
July 6th, 2007 by Aaron
Round 2, and the final round, is complete! The previous article here talked about my initial findings. Well, I was able to try some proofs of concepts on my javascript finding, and I put together our top level recommendations for (”the triangle”). Lets see:
First off…
Javascript Object
Well, I had talked about an issue where you could substitute the javascript object across frames. Well I tried this example. Load up javascripttest.html and click the link. Nope, no dice in IE 6 and 7, FF 1.5 and 2. Whew.
javascripttest.html
1 2 3 4 5 6 7 8 9 10 11 12 13 | <html>
<body>
<script type="text/javascript">
function Object() {
this.hacked = 'test2';
}
document.Object = Object;
</script>
<iframe src="http://release.local/test.html"></iframe>
</body>
</html> |
test.html
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | <html>
<body>
<script type="text/javascript">
function clicker() {
var test = {};
var test2 = new Object();
alert (test.hacked);
alert (test2.hacked);
}
</script>
<a href="#" onclick="clicker()">bleh</a>
</body>
</html> |
Yah - not an issue with the main browsers I use. I didn’t try it on other ones though - so it might still be an issue… who knows… I was just curious.
The recommendations
I got together a few of my final recommendations (yes, very devoid of anything worthwhile, heh.) This is my own AJAX recommendations I’m going to try to follow too.
My Recommendations
Data Transfer
- Data should be sent according to the RFC 2616 in regards to GET and POST.
- Data sent back to the client should be in XML format always except:
- In cases where JSON is the overall best solution, a javascript based JSON parser should be implemented. Eval() should NEVER be used.
- Never pass direct dom or javascript commands.
- In order to preserve separation of view and model, try not to pass any html/css pre-formatted data.
- AJAX requests should match the security/ssl model of the page they’re on. If the page is SSL, the request must be SSL.
AJAX Processing Script Security
- An initial token should be initialized and used in every AJAX request. The script should exit immediately if no token is present. A new token does not need to be regenerated each request.
- Any error checking and validation should be done before the script begins actually processing or including any additional files. Due to the frequency of these requests, do not include additional files until all tests have past.
- If a test requires an included file to validate the data, it is permissible to skip this step if an error condition already exists. In this case, the error(s) will be returned to the client without the additional validation.
- If modifying the PHP session, program around conditions that additional asynchronous requests may be modifying the session as well.
AJAX Component Initialization
- Generally, only two AJAX Request objects should be initialized on a page at any time. The general worker object and the immediate response object. Do not initialize the immediate response object if it is not needed.
- All non time critical responses should be added to a cache, and then processed FIFO.
- Time critical responses should create their own object. There shouldn€™t be a time where more than one time critical method is executing with proper planning.
User Interface
- Always give a visual cue when an AJAX function is activated via a user action. This helps reduce confusion as to why there may be a delay.
- Only two states are needed - the init and the end state - to provide cues. It is not necessary to change state for each response/state type.
- Plan for remote script timeouts and display user friendly notifications.
- If a script times out, every effort to halt the user from invoking that script again should be made. In our environment, most often a timed-out script reflects additional issues that a retry will not fix.
Miscellaneous Notes
- Javascript Object() overwrite vulnerability existed in certain versions of IE and Firefox but was patched. There appears to still be an issue with Safari. This could be an issue with these AJAX responses. Its been tested on the browsers that we officially support and is not an issue.
- The recommended library to use for AJAX requests and effects is scriptaculous. This library extends prototype. Yahoo UI libraries are a secondary choice at this time.
This entry was posted on Friday, July 6th, 2007 at 8:56 pm and is filed under AJAX • PHP • security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Subscribe
December 14th, 2007 at 11:58 pm
Hey I had a question about your token security. I was reading a article that mentioned this (from darknet.org) about a server passing a token to the client then comparing them and was wondering if you got this to work. I really want to secure my ajax applications and I was thinking of using php to generate a token then storing that in a database and in a php session var then on the ajax page make sure the session matched what the db has. could you give me more detail about how your token security works and where you are actually storing the token? should i pass this token in plain javascript or is storing it in the users session ok? Thanks!!
January 3rd, 2008 at 6:48 pm
Hello,
I’m still trying to figure out exactly how to pass the session/token. However, here are my thoughts:
1) php generate a token
2) php inserts the token into the javascript somewhere
3) ajax sends this token
4) php verifies the token sent matches the session.
This is a one time token only, so it offers marginal security, but still some.
HOpe that helps - I’m always looking for more tips myself.