Brett, I'm not saying you shouldn't do everything you can to protect the user, but the matter is simply that if their machine or browser is compromised, there is absolutely nothing you can do to stop an attack. That's just fundamental. Anything you try to do to protect them at that point can be broken, and easily.
And yes, you have to make the assumption that one tab's JavaScript can't access the variables running in another tab. The browser sandboxes those and that is the browser's responsibility. What exactly are you supposed to do if that's broken? There's nothing you could do in JavaScript to prevent that. Once a machine or browser is compromised, it's out of your hands. JavaScript can't work miracles. Any JavaScript you use to try and "fix" the problem, if you are that compromised, the attacker will have access to that too. You are showing him exactly the steps he has to take to undo your "protection". That's like saying you should try to protect against other programs reading your JavaScript variables from RAM. You can't; there are simply no mechanisms that you have as a web developer to protect against that. That falls to the realm of the browser and the OS. What you _can_ do is send sensitive data over SSL and authenticate your user every time they try to get data or make a change. They're all HTTP requests in the end. If they have access to your JavaScript variables in the browser, they have access to the POST/GET/ PUT/DELETE/whatever even if you're not running AJAX or JavaScript at all. So if the user has JavaScript completely turned off and yet the user is still susceptible to this very same attack, exactly how do you think a web developer is supposed to stop it. It's simply not possible. That's all I'm trying to get across. There are certain aspects of security that depend on the browser and the OS, and it doesn't matter how much you wish you can change that, but those are entirely out of your hands. On Oct 13, 12:48 pm, 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]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
