@JuDac, @Brent Thomas, The first step is to decide what you want to protect against.
*If you want to protect against a valid, authenticated user -* - You can prevent him from calling services he is not authorized to call. - You *cannot* prevent him from reading any data that you send as part of the RPC service. Its his data after all, and you can't hide it from him. - You *cannot* prevent him from modifying the request. Its your servers job to validate any data that comes from the client, doesn't matter if the client is authenticated/authorized. *If you want to protect against a man-in-the-middle -* *.. *Just use SSL, and use it correctly. Nothing else can protect you from a MITM. An attacker cannot use firebug to inspect the request/response of another user. He can only inspect his own data; and if wants, can only harm himself. I repeat, he cannot use firebug to inspect someone else's data if SSL is deployed correctly. *If you want to protect one use from another user, or another website - * - Make sure your site is free of XSS and CSRF vulnerabilities. Search this forum, you will find discussions on how to protect from these common problems. - Educate your users about phishing, and pray that they look at the secure https padlock before logging in. - *...@brent* - Javascript from one tab *cannot* access js from another tab. Its the same-origin policy, and without the entire internet would collapse. If you have taken care of XSS and CSRF, you have largely mitigated the risk of one website affecting your websites users. *If you want to protect from the user from a corrupt browser/machine - * You can't. If his machine is compromised, there is nothing you can do technically. If you are so concerned, send him a periodic email to run anti-virus, use latest browser, patch his machine and so on. But realize that your email would most likely make it to the trash. Hope that helps. --Sri On 13 October 2010 23:18, Brett Thomas <[email protected]> wrote: > I'm surprised by the responses here - seems that the overall theme is to > shift blame to users: > >> there is simply nothing you can do if the browser is compromised. Zip. >> Zero. >> It's the user's responsibility, not yours >> > > I really disagree. If you're going to deal with sensitive user data, I > think you need to be a little proactive about guarding them against attacks. > Even if it's not your "fault" if a user visits your site in IE6 and his > whole health and banking history is posted in a forum, it's not a good look. > Remember a while ago when a bunch of iPhone users started logging in to > random people's facebook accounts? *Surprise* it was actually AT&T's fault, > but it prolly cost facebook users. > > Some more specific questions: > > JavaScript from one tab can't access JavaScript from other tabs. >> > > Is it safe to develop a web app with this assumption? I'd argue no, for a > bunch of reasons... > > Thomas and Jeff, you both asked: > > What makes GWT-RPC any less secure than a straight HTTP post? > > > Yeah, that was basically my question. I'm not familiar with the internals > of GWT-RPC, but suppose every compiled service has a var "toBeSent" that > stores the payload. Maybe a script could say "find all toBeSent variables > and figure out their structure and values". I don't know if that's easier > than "find all XHR instances and attach a handler". I'm not suggesting this > should be a threat, but I'm not entirely convinced it shouldn't be. I'll > think about it more. > > On Wed, Oct 13, 2010 at 12:57 PM, [email protected] <[email protected] > > wrote: > >> JuDac, >> I think you're looking at the communication for MitM attacks too >> granular for security that can be imposed by javascript. In GWT you >> can only hope to secure Browser<->Server (ie SSL). If the security is >> that important for whatever data you're sending, maybe you shouldn't >> send it? BTW what data are you sending that needs to be encrypted? >> SSN? or is this the same issue of wanting to write a login page with >> GWT (which is a very poor choice)? >> >> On Oct 13, 12:27 pm, JuDaC <[email protected]> wrote: >> > Sure Jeff, any web page can suffer this attack. >> > >> > For keylogger there a simple any to prevent the attack. so to >> > screenlogger. >> > >> > But for "men in the middle" attack? is there any way to prevent >> > without doing something on client-side? >> > >> > I was thinking in create some info that is sensible to browser frame >> > here the page is running, so this info is sent together on the >> > request, >> > this info is unique per request, and is sensible to information on the >> > request. This along with the obfuscation provided by GWT, can offer >> > a little more security to the server to identify that the request is >> > from a real client and not from a phishing. >> > >> > but so far I can not think in something more reliable. >> > >> > Falcon, you are right. I can't prevent the user from seeing the >> > information, but what I want is to prevent someone to hijack the >> > session (by racking the user) and keep sending to the server >> > repeatedly the same package, or worst changing some informations on >> > the package. >> > >> > Can you imagine the problem that can it cause on the bank website? >> > >> > in this situation, is really important to ensure that the request that >> > reaches the server where made by a real user. Even that plugging that >> > some banks ask to install can't prevent you from this attack I >> > mentioned. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. 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.
