Your plan to use an interface extending RemoteService to be consistent
in how you read the sessionID out of the request body and not the
cookie sounds excellent.
SSL does not protect against XSRF by itself. However, it does turn
moot the general issue of having session IDs hit the line. The long
talks about attempting to hide the sessionID by hiding the cookie and
using some whacky crypto scheme are experimental craziness without
SSL, and if you're already using SSL, utterly pointless.
In other words, SSL + your XSRF protection plan = security sweetness.
I run my website that way. (tipit.to)
You could hack in some sort of exception-over-JSON protocol, where you
build a custom class in between the HttpServlet and YourOwnServlets
class inheritance, which makes it easier to output JSON (for example
by allowing you to output a hashmap), as well as wrapping the actual
doGet()/doPost() calls (by overriding service()) in try/catch, and
having a standard way of conveying the exception to the client. e.g:
{ "error": true, "errorType": "java.io.FileNotFoundException",
"errorMessage": "/foo/bar" }
Going JSON with your API isn't really "better" than using GWT-RPC
unless you have very specific needs (such as: I'll be accessing my
servlets from something other than GWT as well), so only do this if
you really really need it.
One last security note on tossing exceptions across the line
automatically: That can be a security leak, in the sense that you tend
not to think about the exception when considering the type of data
that a servlet will send out onto the internet. It's rare that useful
info leaks out that way, but it does happen, and often it helps a
cracker determine fruitful attacks. Unless you run a very security-
sensitive app, I would accept the risk, but think about what info
might be available in an exception, and if its really bad, do
something about it. Example:
You need to read the password to the database off of disk, because you
use some horribly outdated database layer. The filename contains the
name of the db server and db name. This is info a cracker didn't have
before, but if that file doesn't exist or can't be read, now he does,
because FileNotFoundException, IIRC, has as message the filename. So,
the cracker sees /dbPasswords/localhost_1234_myServerDB or some such.
More info than he had. If he's found a different app on your site that
can be coerced into returning any given file anywhere on the system,
but not directory listings, he now has his puzzle complete and knows
the location of your db and the password. Again - don't abandon the
idea of swapping exceptions across the wire, just try to be aware that
it happens and that exceptions thrown by your servlet is essentially
public info.
NB: Bedankt :)
On Dec 1, 9:58 am, Patrick Ratelband <[EMAIL PROTECTED]> wrote:
> Hey everyone,
>
> thanks for the big replies. There is a lot of info in there, but I
> still have some questions.
>
> I understand that Mallory will always be a problem and that Eve might
> be one, however, defeating them is not part of what I want to do. The
> only thing I want to guard against are XSRF attacks. I understand that
> to prevent these I must put some identifier (let's use sessionID) and
> store it in a cookie to survive browser reload and I must pass it
> inside my GWT RPC request and not rely on the cookie in the header.
>
> So far so good, this is exactly what I am implementing right now.
>
> Gregor suggested that I create an interface that would extend the
> RemoteService, this is along the lines of what I was thinking as it
> would make the whole XSRF system transparent to the programmer, I have
> also understood from the later posts between you and Reinier that the
> visibility of the actual sessionID on the wire is not a problem here,
> so is there any substantial objection to use this approach?
>
> Shawn suggested I use his implementation with JSON, however, I have
> read the readme and the fact that exceptions are not thrown over the
> line is too big of a drawback for me as I use these in the app
> already.
>
> Reiner, you really seem to know your stuff, thank you for your
> clarifying posts and your enjoyable cynical take on the world. I think
> I understand what you are saying.
>
> Last question, would using SSL (which will be implemented on the
> server within a week or two) also prevent XSRF? From what I have read,
> I cannot draw a conclusion one way or the other.
>
> With thanks, Patrick
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
