Hi Vojtech/Oved, On 04/17/2013 12:13 PM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Vojtech Szocs" <[email protected]> >> To: "engine-devel" <[email protected]> >> Sent: Monday, April 15, 2013 2:04:24 PM >> Subject: [Engine-devel] Proposal to make REST API more webapp-friendly >> >> Hi guys, >> >> having worked with Engine REST API from web application (JavaScript) >> perspective, there are things that could be improved to make REST API more >> webapp-friendly. >> >> First of all, webapps are *not* traditional HTTP clients, i.e. they have >> *not* full control over HTTP processing. There are some standard conventions >> and behaviors built into web browsers that any REST API implementation >> should be aware of. >> >> -- >> >> (1) Don't force clients to use cookies for transmitting authentication >> information! (or don't use cookies at all) >> >> Good explanation can be found at >> [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many >> disadvantages: >> >> * cookie parsing/formatting is not trivial >> --> extra complexity imposed on REST clients
i wouldn't call it a cookie blocker, as in most cases (including ours) cookie contains restricted amount of records. >> >> * in addition to Same-Origin Policy >> [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set >> *only* for the given path >> --> JavaScript running at [http://example.com/webapp] *cannot* get/set >> cookies from requests at [http://example.com/restapi] >> >> * cookies are the primary source of Cross-Site Request Forgery >> [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks >> --> malicious websites/scripts can forge requests to REST API that will >> include the cookie, compromising user session same true for the authorization header, session being passed via HTTP headers >> >> Alternative: clients could be given the *option* to use regular HTTP header >> for transmitting authentication information. >> >> For example, webapp could read such (sensitive information) header, store it >> securely via HTML5 Session Storage >> [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP >> processing on its own, e.g. pass this header for all authenticated requests >> (instead of pushing this responsibility to browser). >> > > Option #1: > We currently return the JSESSIONID also using HTTP headers. We currently > return the jsession id also as part of the response HTTP headers, but the > client still needs to pass a cookie with the appropriate value in order for > the REST session to work. Isn't that enough to cope with this issue? api, can consume JSESSIONID from the header indeed, but my problem with this approach is a persistence of the http headers in browsers. > > If not, then we might be able to do option #2: > Today, we keep the engine session ID on the HTTP session attributes. > So, we can support either passing the cookie with the JSESSIONID (taking the > engine session ID from the http session), or passing the engine session ID as > HTTP header (assuming we would also return the engine session ID upon first > REST request). > > This approach is problematic, as it might work well now, when the only > attribute we use is the engine session ID, but in the future that might not > be the case. > If it is important enough (i.e., you can't really work with option #1) , then > we can make a decision to save the attributes on the engine session, rather > than on the HTTP session. > So, we would start by supporting them both together, adding new attributes > only to the engine session, and in the future deprecating the use of cookies, > and only supporting HTTP headers. > > cc-ed Juan and Michael, as they might have some input on that. > > >> -- >> >> (2) Straight-forward HTTP Basic Auth has some drawbacks! >> >> HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] >> over (non-secure) HTTP connection means sending user credentials >> (username/password/domain) in easy-to-decode cleartext, i.e. the value is >> *not* encrypted or hashed in any way. Using secure lower-level protocol >> (SSL) fixes the consequence, rather than the root cause of the >> confidentiality issue. same is true for any sensitive date being passed via plain text (including cookies) >> >> Furthermore, browsers typically remember HTTP Basic Auth information (either >> via browser-specific popup, or via XmlHttpRequest) until the browser window >> is closed. This means the webapp has no control over HTTP Basic Auth header >> after it has been set! This is the reason why it's hard to implement >> "logout" functionality in webapps when using HTTP Basic Auth. right, that is my concern of using headers as well, better solution may be sending JSESSION id via URI matrix parameter, e.g /api/vms;sessionid=xxx >> >> Last but not least, HTTP Basic Auth is vulnerable to Replay attacks >> [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and >> server can intercept requests and replay them, compromising user session. >> >> Alternative: clients could be given the *option* to use more advanced >> authentication scheme. >> >> I've just read an excellent article at >> [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] >> which describes easy yet secure authentication scheme inspired by Amazon Web >> Services REST API authentication >> [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. >> The idea is simple: collect auth information, hash (sign) it with a private >> key, and send everything to server. To guard against Replay attacks, just >> provide some timestamp to enforce request expiry after some time (say, 5-15 >> minutes). Easy and simple! 1. this concept has very same drawbacks as any other content encryption 2. decoding time stamp from request/s will produce fair load for the server as well and won't protect the server against DDOS, also it shouldn't as it's not api/webapp prerogative. in general what Vojtech is trying to achieve is passing session via some other container than cookie as webapp/browsers can't omit auth. header in runtime, what is only justifying my resistance of passing session id via http header, i think using matrix parameter (as mentioned above) may give you a decent solution. >> >> -- >> >> (3) Support JSON for resource representations! >> >> I think this is pretty much obvious. XML has no real advantages over JSON. >> JSON, on the other hand, has good support in webapps (JavaScript) and maps >> directly to common data structures (i.e. string, number, boolean, and so >> on). >> >> From webapp perspective, it's much easier and natural to use JSON than to >> parse/format XML documents. >> >> Alternative: clients could be given the *option* to use JSON, in addition to >> XML representation. not sure how it's related, but we plan supporting JSON in future. >> >> -- >> >> Vojtech >> _______________________________________________ >> Engine-devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
