Re: Discussion on security-for-gwt-applications
On Sep 19, 2:39 pm, Sripathi Krishnan wrote: > The problem you mention has nothing to do with an unsecured browser. You > just need to secure your services on the server side, and every servlet > container has something which lets you do that. > > --Sri I fully agree. You must also consider that evil users may not use a browser at all - there are other ways to issue get/post requests. And even if they use a "secure" browser (what ever that means), they could alter the requests/ responses before they are sent. --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
The problem you mention has nothing to do with an unsecured browser. You just need to secure your services on the server side, and every servlet container has something which lets you do that. --Sri 2009/9/18 ddyer > > > > On Sep 10, 9:56 pm, Sri wrote: > > If you have built your site correctly, a malicious browser cannot harm > > your site. > > > > Vacuously true. In practice there are huge problems if you can't > trust your browser, which you can't. > > Lets construct a simple example. Suppose I have a web site with a > user database, and you want > to get the list of user email addresses so you can spam them. If > there were a simple RPC somewhere > in the interface where the client supplied a user name, and the client > responds with an email address, > you could use this RPC to convert a list of users into a list of email > addresses. > > Effectively, every RPC becomes a new place where the user gets to type > nonsense. Sure, it's possible > to be super paranoid about the contents of every incoming call, but > it's not a very natural programming > style, and not especually supported or encouraged by GWT. In fact, > GWT encourages the opposite; to > treat RPC transactions as the same as function calls within a closed > program. > > > > > > > --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
On Sep 10, 9:56 pm, Sri wrote: > If you have built your site correctly, a malicious browser cannot harm > your site. > Vacuously true. In practice there are huge problems if you can't trust your browser, which you can't. Lets construct a simple example. Suppose I have a web site with a user database, and you want to get the list of user email addresses so you can spam them. If there were a simple RPC somewhere in the interface where the client supplied a user name, and the client responds with an email address, you could use this RPC to convert a list of users into a list of email addresses. Effectively, every RPC becomes a new place where the user gets to type nonsense. Sure, it's possible to be super paranoid about the contents of every incoming call, but it's not a very natural programming style, and not especually supported or encouraged by GWT. In fact, GWT encourages the opposite; to treat RPC transactions as the same as function calls within a closed program. --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
If you have built your site correctly, a malicious browser cannot harm your site. Lets say you build a browser that sends out cookies to you. The point is, you have to first get a real user to actually use your browser. And there lies the security - you can't get me using your hacked browser. If the network in unencrypted, sure - you can get hold of information. But if it is https protected, then man-in-the-middle attacks become difficult, and even if you were able to monitor the traffic, it would be all garbled. --sri On Sep 10, 4:18 pm, ddyer wrote: > Isn't any security that's based on the browser enforcing a policy > essentially a sham? > Or more politely, guaranteed to be ineffective against a deliberate > attack. > > The browsers are open source, and the communications channel is > unencrypted, > and you don't have to use a browser at all. There are just too many > ways for browser > security to be bypassed. > > This may not matter much if the target of the attack is presumed to be > the user, but > what if the target is the host site? --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Discussion on security-for-gwt-applications
Isn't any security that's based on the browser enforcing a policy essentially a sham? Or more politely, guaranteed to be ineffective against a deliberate attack. The browsers are open source, and the communications channel is unencrypted, and you don't have to use a browser at all. There are just too many ways for browser security to be bypassed. This may not matter much if the target of the attack is presumed to be the user, but what if the target is the host site? --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Hi Nitin, Did you recently experience a black hat who hacked your site? If so, you should post up some details about how the attack occurred and perhaps some members of the community can make suggestions about how to fix the potential security leak. In general, security for web applications, built with GWT or not, is a vast topic with lots of different classes of attacks. There is probably more to come than any security expert currently knows as black hats continue to spend their days thinking of ways to break your site. In security there are no 100% percent guarantees that your site won't be breached, only reduced chances that your security model won't be broken. That said, you should take every precaution necessary to secure your application for the sake of your users, despite the fact that no model is perfect. For starters about how you can secure you GWT application, check out Dan Morrill's excellent article at the link below. "Security for GWT Applications" - Dan Morrill: http://code.google.com/webtoolkit/articles/security_for_gwt_applications.html Hope that helps, -Sumit Chandel On Mon, Feb 23, 2009 at 11:25 AM, Nitin Sawant wrote: > > make the GWT more secure. so that the evil f**kers won't hack my > site.. > > > > --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Discussion on security-for-gwt-applications
make the GWT more secure. so that the evil f**kers won't hack my site.. --~--~-~--~~~---~--~~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
ERRATUM: On 4 déc, 10:58, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > Walden, you need a refresh on URIs and HTTP As Walden pointed out to me in private, I should have directed this answer towards Jason; as it's quite clear that Walden is aware of all I said ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
D'oh! I didn't see this last month. On 4 nov, 22:03, walden <[EMAIL PROTECTED]> wrote: > On Nov 4, 12:31 pm, "Jason Vincent" <[EMAIL PROTECTED]> wrote: > > > ((ServiceDefTarget) ourInstance) > > .setServiceEntryPoint(GWT.getModuleBaseURL() + > > "com.vincent.gwtapps.myApp.MyGwtApp/AuthenticationService?sid=" + sid); > > So it's a GET parameter on a POST request? Hmmm. Clever, though. Walden, you need a refresh on URIs and HTTP: the "query" part of an URI is totally independent on the thing you do with this URI. If it is an HTTP URL, you're free to use any HTTP method on it. An URI identifies a resource; the "query" part of it is not "GET parameter". People call it like that because that's how HTML forms are sent when method=GET and therefore that's how most server-side web frameworks (incorrectly) call it too ($_GET in PHP, for instance). Many web framework do not make any reference to the GET HTTP method when talking about the "query" part of the requested URL: ASP.NET's HttpRequest.QueryString, Java Servlet's HttpServletRequest.getQueryString(). You'll note too that the "query" part of a URI (even if it is an HTTP URL) is not constrained to look like key1=value1&key2=value2. Most (if not all) web frameworks automatically decompose such format (which is the one spec'd in HTML for sending forms with method=GET) into a hashtable-like object; but that's just to help with (on of) the most common case (HTML forms). Note too that major web frameworks can give you "parameters", whereever they come from: Java Servlet's ServletRequest.getParameterXXX methods when the request is an HTTP request, ASP.NET's HttpRequest.Params, PHP's $_REQUEST, etc. URI-wise and HTTP-wise, http://example.net/?key=value isn't any different from http://example.net/key?value, http://example.net/key/value, http://example.net/key=value, http://example.net/key,value, etc. They all are URLs identifying resources, and you can issue whetever HTTP method you like on them. The rest is implementation detail on the server side. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Thanks for the feedback Shawn and Reinier. I'm not relying on Cookies at all, the Session ID will be created by the server, it will be a large pseudo random number. The session IDs will of course expire. Interesting point about problems that could be created by restricting access to a single IP, I will drop that approach. I'd like to use SSL - but I don't think it's practical, I do have root access to the server, but it's not my server. I'll post again when it's done and let you all know how it all worked out! On Dec 4, 7:24 am, Shawn Pearce <[EMAIL PROTECTED]> wrote: > Also restricting a session to a single IP address can be problematic with > some providers that use web proxies for their clients. I don't know if this > has changed, but years ago AOL made this rather difficult as requests from > clients can be routed out through multiple proxy servers. Individual users > bounced around on IP addresses between requests, based on the proxy server > load balancing algorithm used. My last employer did this with their > corporate desktops too, and there it was a matter of load-balancing the > outgoing traffic through different T3 connections. Its more common than you > might think. > > If you really need to protect the session, use SSL. Otherwise, probably the > best you can do is a time-based session token. Trying to tie it to an IP > address is just asking for some difficulty with proxies. > > On Wed, Dec 3, 2008 at 18:46, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote: > > > > > krona: If you are getting the session ID from the cookie, your web > > service is still vulnerable to XSRF (wikipedia it). Make GWT send the > > session ID in the body of requests (such as a parameter to GWT-RPC or > > stuff it in the JSON you're sending to your PHP). > > > On Dec 4, 1:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > The approach I'm taking, and I'm hoping it is a good one, is to divide > > > the operations on the server cleanly in to read and write. I'm using > > > php on the server and GWT on the client. The client cannot execute any > > > write operation on the server without a unique Session ID, the only > > > way that the client can get a Session ID is by providing correct log > > > in credentials to the server. Once the client has provided correct > > > login credentials the server creates a Session ID and binds it to an > > > IP address. Any write requests coming in to the server will not be > > > honoured if they do not come from the IP address/Session ID > > > combination that the server understands as being 'safe'. Obviously > > > once write access is granted on the server all string data is stripped/ > > > escaped as appropriate. The philosophy is that the server will never > > > send anything to the client that could be intepreted as anything but > > > plain text. > > > > I cannot protect against fishing, but then this is only for a cat club > > > website! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Also restricting a session to a single IP address can be problematic with some providers that use web proxies for their clients. I don't know if this has changed, but years ago AOL made this rather difficult as requests from clients can be routed out through multiple proxy servers. Individual users bounced around on IP addresses between requests, based on the proxy server load balancing algorithm used. My last employer did this with their corporate desktops too, and there it was a matter of load-balancing the outgoing traffic through different T3 connections. Its more common than you might think. If you really need to protect the session, use SSL. Otherwise, probably the best you can do is a time-based session token. Trying to tie it to an IP address is just asking for some difficulty with proxies. On Wed, Dec 3, 2008 at 18:46, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote: > > krona: If you are getting the session ID from the cookie, your web > service is still vulnerable to XSRF (wikipedia it). Make GWT send the > session ID in the body of requests (such as a parameter to GWT-RPC or > stuff it in the JSON you're sending to your PHP). > > On Dec 4, 1:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > The approach I'm taking, and I'm hoping it is a good one, is to divide > > the operations on the server cleanly in to read and write. I'm using > > php on the server and GWT on the client. The client cannot execute any > > write operation on the server without a unique Session ID, the only > > way that the client can get a Session ID is by providing correct log > > in credentials to the server. Once the client has provided correct > > login credentials the server creates a Session ID and binds it to an > > IP address. Any write requests coming in to the server will not be > > honoured if they do not come from the IP address/Session ID > > combination that the server understands as being 'safe'. Obviously > > once write access is granted on the server all string data is stripped/ > > escaped as appropriate. The philosophy is that the server will never > > send anything to the client that could be intepreted as anything but > > plain text. > > > > I cannot protect against fishing, but then this is only for a cat club > > website! > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
krona: If you are getting the session ID from the cookie, your web service is still vulnerable to XSRF (wikipedia it). Make GWT send the session ID in the body of requests (such as a parameter to GWT-RPC or stuff it in the JSON you're sending to your PHP). On Dec 4, 1:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > The approach I'm taking, and I'm hoping it is a good one, is to divide > the operations on the server cleanly in to read and write. I'm using > php on the server and GWT on the client. The client cannot execute any > write operation on the server without a unique Session ID, the only > way that the client can get a Session ID is by providing correct log > in credentials to the server. Once the client has provided correct > login credentials the server creates a Session ID and binds it to an > IP address. Any write requests coming in to the server will not be > honoured if they do not come from the IP address/Session ID > combination that the server understands as being 'safe'. Obviously > once write access is granted on the server all string data is stripped/ > escaped as appropriate. The philosophy is that the server will never > send anything to the client that could be intepreted as anything but > plain text. > > I cannot protect against fishing, but then this is only for a cat club > website! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Discussion on security-for-gwt-applications
The approach I'm taking, and I'm hoping it is a good one, is to divide the operations on the server cleanly in to read and write. I'm using php on the server and GWT on the client. The client cannot execute any write operation on the server without a unique Session ID, the only way that the client can get a Session ID is by providing correct log in credentials to the server. Once the client has provided correct login credentials the server creates a Session ID and binds it to an IP address. Any write requests coming in to the server will not be honoured if they do not come from the IP address/Session ID combination that the server understands as being 'safe'. Obviously once write access is granted on the server all string data is stripped/ escaped as appropriate. The philosophy is that the server will never send anything to the client that could be intepreted as anything but plain text. I cannot protect against fishing, but then this is only for a cat club website! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Jason,
So it's a GET parameter on a POST request? Hmmm. Clever, though.
Walden
On Nov 4, 12:31 pm, "Jason Vincent" <[EMAIL PROTECTED]> wrote:
> I see your point. If the SID is invalid, either via a real attack or by
> session invalidation, the result is the same... "I don't know who you are so
> please re-authenticate yourself." My project is in its early stages, so for
> what I thought was an attack I was just throwing an exception to kick that
> request back to where it came from. I believe I'll just handle it like the
> user isn't logged in and send it to the login view. Thanks for your input.
>
> As for the get parameter... in my RemoteService interfaces, where I have the
> static getInstance to get the Async instance I essentially pass in the sid
> and build the url with that sid.
>
>
> public static synchronized AuthenticationServiceAsync
> getInstance(String sid) {
> if (ourInstance == null) {
> ourInstance = (AuthenticationServiceAsync)
> GWT.create(AuthenticationService.class);
> }
> ((ServiceDefTarget) ourInstance)
> .setServiceEntryPoint(GWT.getModuleBaseURL() +
> "com.vincent.gwtapps.myApp.MyGwtApp/AuthenticationService?sid=" + sid);
> return ourInstance;
> }
>
>
>
>
> On Tue, Nov 4, 2008 at 4:19 AM, walden <[EMAIL PROTECTED]> wrote:
>
> > Jason,
>
> > I think false positives is a feature of this kind of security
> > strategy, not necessarily a bad thing. How do you handle what you
> > think is a real "XSRF" attack? When I use Yahoo (not often), it seems
> > like it asks me to login a lot. But they smooth the experience with
> > words to the effect that it's for a good cause. Since the reality is
> > that you can't be sure when a sid error is an attack, why not be
> > candid about it?
>
> > BTW, how do you use RPC to send a "get parameter"? That part confused
> > me.
>
> > Walden
>
> > On Nov 3, 4:59 pm, Jason <[EMAIL PROTECTED]> wrote:
> >> I have a question about the "XSRF" protection. I've implemented this
> >> by using a requestFilter which filters for the "nocache.js" file and
> >> sets a "sid" cookie with the session id as the value. Then for each
> >> RPC call I send the value of the "sid" cookie as a get parameter.
> >> When the session is active this works great. The issue I have is when
> >> the session expires, or invalid for some reason. Currently this is
> >> reporting a false "XSRF" attack since the sid no longer matches the
> >> session id on the server.
>
> >> If the sid is based off the session Id (or anything that changes over
> >> time), how might it get updated when the session id gets invalidated?-
> >> Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Jason, Maybe you could come up with a session-less implementation, so then you wouldn't have to worry about releasing those resources? Walden On Nov 4, 12:52 pm, "Jason Vincent" <[EMAIL PROTECTED]> wrote: > Nah... I need sessions to expire like normal so that those resources can be > released as users leave the site. > > On Tue, Nov 4, 2008 at 5:14 AM, ponthiaux eric <[EMAIL PROTECTED]>wrote: > > > > > Did you try to make cyclic call to the server to preserve the session ? > > with a Gwt Timer for example . > > > regards. > > > 2008/11/3 Jason <[EMAIL PROTECTED]> > > >> I have a question about the "XSRF" protection. I've implemented this > >> by using a requestFilter which filters for the "nocache.js" file and > >> sets a "sid" cookie with the session id as the value. Then for each > >> RPC call I send the value of the "sid" cookie as a get parameter. > >> When the session is active this works great. The issue I have is when > >> the session expires, or invalid for some reason. Currently this is > >> reporting a false "XSRF" attack since the sid no longer matches the > >> session id on the server. > > >> If the sid is based off the session Id (or anything that changes over > >> time), how might it get updated when the session id gets invalidated? > > > -- > > Eric Ponthiaux > > > Consultant technique > > > +33.687030001 > > > [EMAIL PROTECTED] Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Nah... I need sessions to expire like normal so that those resources can be released as users leave the site. On Tue, Nov 4, 2008 at 5:14 AM, ponthiaux eric <[EMAIL PROTECTED]>wrote: > Did you try to make cyclic call to the server to preserve the session ? > with a Gwt Timer for example . > > regards. > > 2008/11/3 Jason <[EMAIL PROTECTED]> > >> >> I have a question about the "XSRF" protection. I've implemented this >> by using a requestFilter which filters for the "nocache.js" file and >> sets a "sid" cookie with the session id as the value. Then for each >> RPC call I send the value of the "sid" cookie as a get parameter. >> When the session is active this works great. The issue I have is when >> the session expires, or invalid for some reason. Currently this is >> reporting a false "XSRF" attack since the sid no longer matches the >> session id on the server. >> >> If the sid is based off the session Id (or anything that changes over >> time), how might it get updated when the session id gets invalidated? >> >> >> > > > -- > Eric Ponthiaux > > Consultant technique > > +33.687030001 > > [EMAIL PROTECTED] > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
I see your point. If the SID is invalid, either via a real attack or by
session invalidation, the result is the same... "I don't know who you are so
please re-authenticate yourself." My project is in its early stages, so for
what I thought was an attack I was just throwing an exception to kick that
request back to where it came from. I believe I'll just handle it like the
user isn't logged in and send it to the login view. Thanks for your input.
As for the get parameter... in my RemoteService interfaces, where I have the
static getInstance to get the Async instance I essentially pass in the sid
and build the url with that sid.
public static synchronized AuthenticationServiceAsync
getInstance(String sid) {
if (ourInstance == null) {
ourInstance = (AuthenticationServiceAsync)
GWT.create(AuthenticationService.class);
}
((ServiceDefTarget) ourInstance)
.setServiceEntryPoint(GWT.getModuleBaseURL() +
"com.vincent.gwtapps.myApp.MyGwtApp/AuthenticationService?sid=" + sid);
return ourInstance;
}
On Tue, Nov 4, 2008 at 4:19 AM, walden <[EMAIL PROTECTED]> wrote:
>
> Jason,
>
> I think false positives is a feature of this kind of security
> strategy, not necessarily a bad thing. How do you handle what you
> think is a real "XSRF" attack? When I use Yahoo (not often), it seems
> like it asks me to login a lot. But they smooth the experience with
> words to the effect that it's for a good cause. Since the reality is
> that you can't be sure when a sid error is an attack, why not be
> candid about it?
>
> BTW, how do you use RPC to send a "get parameter"? That part confused
> me.
>
> Walden
>
> On Nov 3, 4:59 pm, Jason <[EMAIL PROTECTED]> wrote:
>> I have a question about the "XSRF" protection. I've implemented this
>> by using a requestFilter which filters for the "nocache.js" file and
>> sets a "sid" cookie with the session id as the value. Then for each
>> RPC call I send the value of the "sid" cookie as a get parameter.
>> When the session is active this works great. The issue I have is when
>> the session expires, or invalid for some reason. Currently this is
>> reporting a false "XSRF" attack since the sid no longer matches the
>> session id on the server.
>>
>> If the sid is based off the session Id (or anything that changes over
>> time), how might it get updated when the session id gets invalidated?
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Did you try to make cyclic call to the server to preserve the session ? with a Gwt Timer for example . regards. 2008/11/3 Jason <[EMAIL PROTECTED]> > > I have a question about the "XSRF" protection. I've implemented this > by using a requestFilter which filters for the "nocache.js" file and > sets a "sid" cookie with the session id as the value. Then for each > RPC call I send the value of the "sid" cookie as a get parameter. > When the session is active this works great. The issue I have is when > the session expires, or invalid for some reason. Currently this is > reporting a false "XSRF" attack since the sid no longer matches the > session id on the server. > > If the sid is based off the session Id (or anything that changes over > time), how might it get updated when the session id gets invalidated? > > > > -- Eric Ponthiaux Consultant technique +33.687030001 [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
Jason, I think false positives is a feature of this kind of security strategy, not necessarily a bad thing. How do you handle what you think is a real "XSRF" attack? When I use Yahoo (not often), it seems like it asks me to login a lot. But they smooth the experience with words to the effect that it's for a good cause. Since the reality is that you can't be sure when a sid error is an attack, why not be candid about it? BTW, how do you use RPC to send a "get parameter"? That part confused me. Walden On Nov 3, 4:59 pm, Jason <[EMAIL PROTECTED]> wrote: > I have a question about the "XSRF" protection. I've implemented this > by using a requestFilter which filters for the "nocache.js" file and > sets a "sid" cookie with the session id as the value. Then for each > RPC call I send the value of the "sid" cookie as a get parameter. > When the session is active this works great. The issue I have is when > the session expires, or invalid for some reason. Currently this is > reporting a false "XSRF" attack since the sid no longer matches the > session id on the server. > > If the sid is based off the session Id (or anything that changes over > time), how might it get updated when the session id gets invalidated? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Discussion on security-for-gwt-applications
I have a question about the "XSRF" protection. I've implemented this by using a requestFilter which filters for the "nocache.js" file and sets a "sid" cookie with the session id as the value. Then for each RPC call I send the value of the "sid" cookie as a get parameter. When the session is active this works great. The issue I have is when the session expires, or invalid for some reason. Currently this is reporting a false "XSRF" attack since the sid no longer matches the session id on the server. If the sid is based off the session Id (or anything that changes over time), how might it get updated when the session id gets invalidated? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
