Thursday, February 16, 2006

JSONP Service and Security

Before talking about shared services, I have to clarify what issues (or concerns) are now discussed about JSONP services (maybe not so discussed, because there're less services than usual REST XML or SOAP Web Services). Especially, I'm going to focus security concerns. Because XMLHttpRequest itself doesn't allow the request other than the original html source site (same-origin policy), there might be same or similar concerns in JSONP service.

Let's consider Site Y is a JSONP service site (like Yahoo), and Site M is your JSONP mashup site, and User u is a visitor to Site M. Site O is a simple web service provider nothing related to these services, but might be an atacker's target.

(Note that these are only my guesses)


If M is malicious, can M steal the identity information of u in Y ?



M cannot steal it without cooperation of Y. If Y have a unrestricted JSONP interface to access u's identity information, M can. If there's no consent of u, Y should be responsible for unintended usage of u's identity information.


If Y is malicious, can Y effect bad thing (information theft, session hijack) to M ?



Absolutely Y can. The loaded JSONP service does not always have to provide JSON object, it's nothing other than JavaScript and the code format itself is all under the control of Y. Loaded code is automatically executed without any validation (this is a key point of JSONP) and the excecution priviledge become that of Site M. So M have to do trust Y as long as M is using Y's service.


If Y become suddenly malicious, and the loaded code effected bad to M, who is responsible ?



Of course Y is responsible basically. If the information theft is u's identity information in M, M also should be responsible (about unintended usage of u's identity information).


If Y is malicious, Can Y attack O ?



Yes, for example, requesting huge amout of requests to O. And - similar to DDoS - the attacking context become that of User u. But it's not so special case in JSONP service because any malicious site can do that. The main concern here is trust. If User u trusted Site M, and not knowing M is using Y's service (and u might be not trusting Y), M was responsible for prior explanation about using Y's services, because, if notified, u might not have used the M's service. And M should also be responsible for Site O


Can Y steal the identity information of u in Site O ?



Basically no. If there were vulnerabilities in O it might be yes. If u accepted the usage of cross domain XMLHttpRequest in some way (browser setting?), it might also be yes, but it's under u's responsibility.


Can Y affect the transaction between u and O ?



Basically no. If there were vulnerabilities in O it might be yes. CSRF might be one of them. O should be responsible with its own vulnerability.

Technorati tags: , , ,

No comments: