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]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
