Re: Discussion on security-for-gwt-applications
On Sep 10, 9:56 pm, Sri sripathikrish...@gmail.com 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 -~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
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
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 nitin.sawant2...@gmail.comwrote: 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
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
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 -~--~~~~--~~--~--~---
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
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
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.
pre
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;
}
/pre
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
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
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
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.
pre
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;
}
/pre
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, 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 -~--~~~~--~~--~--~---
