Determining if a browser or a script is calling your Ajax functions

Reply

mbaggett Posted: 11-10-2006 11:01 AM

rated by 0 users

I know you guys were looking at how IE & Mozilla could do something to allow the back end apps to determine if it was a user in a browser making an call to your ajax functions or a script running in the browser.  Would this work..

At application initiation the browser and server negotiate a shared secret.  The browser stores the shared secret outside the DOM.  Then uses it to digitally sign each request.  The digital signature can be a field added to the header by the browser.   By itself the signature would allow you do determine that it is the browser and not a script. You could also do some things to force sequencial function calls.   For example if the server wants to ensure a function1 is called before function2 you could use a challenge-response varient that is passed between functions.  So

1) Client shared secret signed request to function1

(Signature can be similar to kerberos.. Encrypt IP, date &time with shared secret)

2) Server function1 chooses nonce, encrypts with shared secret and includes in response header

3) Client browser decrypts adds 1 to nonce, reencrypts and includes in call to function2.

4) Function2 on server decrypts with shared secret. Verify nonce+1

A script could no longer go straight to function2.. right?

I guess it requires some significant changes on both the browser and a new object model in ajax.

Thoughts?

Mark

Reply

Billy replied on 11-13-2006 11:38 AM

rated by 0 users

Mark,

 Thats an interesting plan, but I see a few sticky points.

1. While you don't explicitly say it, you need to make sure the browser only adds that header to requests that are not made by JavaScript. The reason Ajax requests look like regular requests is because the browser actually makes both of them. The browser adds cookies data, HTTP auth, etc automatically to every request, regardless of what caused the request. That is the fundamental underline problem here.
   
2. Simply adding an HTTP header to each request saying what caused the request to happen is a more flexible solution. Somehting like "Origin: IMG SRC" "Origin: Hyperlink" or "Origin: JavaScript." It is not necessary to cryptographically sign this if all the browsers got on board and client side technologies that can create HTTP requests independent of the browser (basically Flash and Java Applets) prevented you from adding this header. A nice benefit is this would also stop XSRF in addition to XSS. As it currently stands, both Flash and Java Applets can create raw HTTP requests outside of the browser's control and spoof any header desired.
   
3. Kerberos is a nice system, but HTTP is a layer 7 protocol. Any solutions at Layer 7 shouldn't have knowledge of lower layers like IP. I can think of numerous situations where an IP address can change mid transaction (hopping WiFi access points, load balancers, transparent proxies, etc) for legitimate reasons, but what cause this system to fail.
   
4. HTTP, web browsers, and web servers are a resource serving system. It serves lots of content besides HTML, let along HTML with embedded JavaScript. It is not the web servers/browser job to ensure that JavaScript is executed in a particular fashion. I think you would get a lot of resistance trying put this type of system in place.
   
5. This system has an amazing amount of overhead. Negotiating a shared secret and digital signatures requires public key crypto and secure hashing functions. While the browser has a lot of this already in the SSL libraries, you really don't need all that. You could accomplish significant parts of it by simply storing some state on the server in a Sessions storage that keeps track of what functions have been called for what session ID (which isn't based on an IP) and enforces the order.

I'm glad that people are thinking about this problem. You should check out the WHATWG and Webappsec mailing lists. They have some excellent discussions about the pros and cons or various Cross domain XmlHttpRequest schemes.

Take care,

Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. – http://www.spidynamics.com
Phone:  678-781-4800
Direct:   678-781-4845

Reply

mbaggett replied on 11-13-2006 7:43 PM

rated by 0 users

Billy,

I've heard you speak on various subject and I know you know what you're talking about.  Please indulge me while I ask a few follow-ups to your points. 

1) Yes.  The browser would have to limit the header to the requests not generated by scripts.  Wouldn't this end up being the same logic engine required to accomplish the Origin headers you suggest in #2?

2) That would solve it, but I think it would be easier to have the browser guys buy into adding a signature than to take functionality away from the developers.   Its that ability to forge the headers that I was trying to defeat with the browser signature.   As long as the shared key is exchanged over ssl during the initial connection and isn't available in the DOM any scripting engine would have to resort to brute forcing the signature. Even if you got Sun and Macromedia to modify their libraries to not allow raw http packet manipulation you'd still have to deal with other client scripting languages as they emerge.  If you solve it in the browser once, your done.  Dont you think a signature approach would be more easily adopted then limiting client languages?

3) Agreed.  IP is probably not the best choice.  I was trying to come up with plain text the server would be able to easily verify, but NATting etc would break that.  Ideally the clear text would be something inaccessible to the DOM, but accessible both web server and browser.

4&5)  Good point.  There are better ways to enforce the sequence in which functions/methods are called.  Forget I suggested that. 

  Sounds like there is a forum where lots of people smarter than me are working on this.  I'll check it out too see what you guys come up with, but I'd be curious to hear your response before I go into lurker mode on that forum.