Create an Account
username: password:
 
  MemeStreams Logo

MemeStreams Discussion

search


This page contains all of the posts and discussion on MemeStreams referencing the following web page: SAJA - Secure AJAX for PHP. You can find discussions on MemeStreams as you surf the web, even if you aren't a MemeStreams member, using the Threads Bookmarklet.

SAJA, and the smoking of the crack
by Acidus at 12:02 am EDT, Oct 27, 2007

K Said:

Just ran across this...

Any chance it makes the baby jesus' crying less acute?

Well, this sure scares me: http://saja.sourceforge.net/security/

I need to look at this but here are my thoughs so far.

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 convol... [ Read More (0.2k in body) ]


 
RE: SAJA, and the smoking of the crack
by k at 12:55 am EDT, Oct 27, 2007

Acidus wrote:
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.

I had a feeling this was the case, so, yeah, my initial thought was that obfuscating function calls isn't that helpful.

The emulating SSL with JavaScript is just damn scary. They are doing it very insecurely instead of kind of insecurely.

I hadn't even dug that far into it, but that does sound stupid based on my minimal knowledge. Your explanation seems to indicate the depth of retarditude. redardicity? anyway.

it's cool to hear your perspective. I was pretty sure this wasn't all it claimed to be.

enjoy raping it ;)


SAJA - Secure AJAX for PHP
by k at 2:38 pm EDT, Oct 25, 2007

Just ran across this...

Any chance it makes the baby jesus' crying less acute?


 
 
Powered By Industrial Memetics