MemeStreams | SAJA, and the smoking of the crack

The "Function" security sounds a lot like nonce on the system calls. Ok, so no one can access you system calls unless they are using your application, but most of hte Ajax stuff I'm focusing on is exploiting the application inside the context of the application (i.e. tampering with variables while its being used, control flow modification, data leakage, etc). This "you can only access the callback if you are really using the application" approach doesn't sound promising because it doesn't really address the problem, it attempts to limit access to the problem.

The emulating SSL with JavaScript is just damn scary. We have a whole chapter about hacking and securing mashups and aggregates like NetVibes, Facebook, etc in Chapter 11, Web Mashups and Aggregators, in our book Ajax Security. Here we point out that this implementing crypto in JavaScript is a bad idea. In fact, here is the text from the book:

Another popular aggregate site, PageFlakes, tries attempts a different solution: using asymmetric key encryption (also known as public key encryption). In public key encryption, the key used to encrypt the data is different than the key to decrypt the information. Thus PageFlakes uses a public/private key pair and embeds the public key in the web pages it sends to the client. Client-side JavaScript uses RSA to encrypt sensitive data before transmitting it to back to the server. This allows data to be securely sent from the client to PageFlakes by essentially emulating parts of an SSL connection on top of an HTTP connection. However this is not a good solution because it only solves half the problem because. Only the web server has a public/private key pair allowing secure communication in a single direction form the client to the server. There is no way for the server to communicate back to the client. You cannot pre-seed the client-side code with its own public/private key pair because that would be transmitted to a user’s web browser unencrypted over standard HTTP. An attacker would simply intercept it. The public/private key pair for the client would have to be generated on the client. JavaScript does not have a random number generator that is suitable for cryptographic functions. It might be possible for JavaScript to use a Java Applet’s cryptographically secure random number generator for key generation, but some browsers do not allow Applet’s to access these secure libraries. This whole approach does not even matter if malicious widgets that are not properly jailed. They could simply hook the JavaScript code and steal sensitive data before it is even encrypted using this convoluted half solution.
This entire train of thought is kind of silly and extremely dangerous. JavaScript is not designed to perform complex cryptographic functions. Even when it is capable of executing an algorithm, such as JavaScript implementation of RSA or MD5, the performance will be substantially less the native cryptographic functions of the browser. Furthermore JavaScript cannot create cryptographically secure random numbers required for key generation and necessary for ad hoc secure conversations. All of this is a poor attempt to implement an SSL channel on top of HTTP. This is nonsensical! The browser already has battle hardened and speed optimized functions for creating and using SSL connections. This is like reinventing the stone wheel as a stone pentagon: it is crude, not as efficient as a circle, and is most likely going to break and hurt someone. Developers should use SSL to prevent eavesdroppers like Eve from stealing data as it is transmitted between the client and server. Accept no emulated SSL substitutes like asymmetric encryption in JavaScript!

These jokers are using symmetric key encryption. It goes without saying thats beyond retarded and is completely broken.

I want to look more at the so-called function security, but I doubt any increase in security it could provide offsets damage caused by the "cluster fuck of a bad idea" of using RC4 encryption in JavaScript. I would not recommend using this library in anyway, shape, or form.

SAJA, and the smoking of the crack