[Disclaimer: I'm not a security expert] On Tuesday, June 24, 2014 2:10:57 PM UTC+2, Jack Thompson wrote: > > Hello, > > The company where I work is starting a new family of web applications and > have decided to use GWT on the client side. > > In the matter of security I've conducted a review of GWT XSS/XSRF best > practices and I'd like to confirm my assumptions. > > For communication with our server we will be using JSON with REST and > HTTP-Basic authentication to authenticate the user. All HTTP traffic takes > place over SSL connection. It is my understanding that using HTTP-Basic > which requires explicit username and password for each operation should > protect us from XSRF attacks as the session is not maintained with cookies > and the server side is entirely stateless. This is of course assuming some > malicious code does not find its way inside our GWT application and steal > the username and password from within there, which brings our attention to > cross-site scripting attacks. >
I don't know how browsers actually work with XMLHttpRequest, but it might a) remember the username/password and send them in subsequent requests (defeating your assumption that it would protect you from XSRF) and b) prompt the user for his username/password (which it WILL remember 'til the browser is closed) in case the provided ones don't match (e.g. if the user changed his password but the app doesn't know the new one). The sole fact that you'd keep the password in memory in a JS string variable is enough for me to dismiss the idea. You should either generate a "token" that you pass with a custom header (or a custom Authorization scheme, possibly just using OAuth Bearer auth <https://tools.ietf.org/html/rfc6750>), or use cookies with additional measures to mitigate XSRF (sending some token, or possibly just the cookie's value, in a custom header, and compare it to the cookie/session on the server side). That way, you send the username/password once only, and the token you generated can easily be revoked (terminate a remote session, revoke all sessions in case of discovered vulnerability or stolen data, revoke session in case of suspicious activity, etc. all those things you cannot do when you send the password in each request). > > For the XSS four attack vectors mentioned in > http://www.gwtproject.org/articles/security_for_gwt_applications.html I > believe we are (mostly) safe if we > Note that this article is VERY old. Not much things have changed though in the security front since then. > > - Don't use JavaScript on the host page > - Don't use JavaScriptNativeInterface > - Use innerHtml or setHtml only with SafeHtml or not at all > - Access user created strings to and from widgets by getText/setText > methods > > …or sanitizing HTML if you do need/want rich text inputs. For the JSON part we are shall be using RestyGWT. For the JSON related > security issues mentioned in GWT documentation I shall ask in the Resty's > mailing list. But I assume if Resty succesfully parses the JSON code I am > safe to pass the strings to GWT widgets by setText without need of SafeHtml > or anything else. > GWT will parse JSON using the browser's native JSON.parse(), which is safe (unless some XSS injects an insecure JSON object into the page, but then it can do much more than that…) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
