On Wednesday, August 7, 2013 3:26:29 PM UTC-4, Chad Vincent wrote: > I'm with the person from Iron Mountain... Just like CRIME, they both seem > to require some kind of XSS vulnerability in the page, then take advantage > of TLS and GZIP. As long as your users don't use a lot of suspicious > add-ons and you prevent XSS as best as you can, I really don't think > there's much risk. > > Not that the compression + encryption combination don't need fixed, but > you not only need help from Google to mitigate it on AppEngine by > supporting an updated standard, but all of your users will have to use an > updated web browser, too.
I don't see why a browser upgrade is necessary. Google can fix this on the server side by disabling compression when using HTTPS. Of course, thats a shotgun approach that will waste bandwidth and CPU probably. Individual apps can also fix this by taking the other steps recommended by the paper. But since only Google controls compression and encryption settings, it puts app developers in a tight spot because they can't temporarily disable compression while implementing a better fix. Also, its not an XSS issue, its about information leakage, the paper talks specifically about getting CSRF tokens. Anyways, I brought it up because I'm curious how Google handles these issues. I'm sure they have customers that have very high security requirements and other customers who probably don't care. Are they going to wait and see what happens (i.e., wait for real exploits) or are they going to take steps to protect their customers against a potential (theoretical?) threat? --Alex -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
