Thanks, Takashi. Your suggestion about avoiding mixing sources of data makes sense. Its a good rule of thumb for this issue.
--Alex On Thursday, August 8, 2013 8:26:33 PM UTC-4, Takashi Matsuo (Google) wrote: > > > Hi Alex, > > Our security team implemented various possible countermeasures against the > CRIME attack for HTTP headers some time ago, and our understanding is that > BREACH is a new variation. > > As you said, with App Engine, gzip compression is automatically done if a > web browser sends corresponding headers. Thus, disabling the compression is > not currently an option for App Engine developers. Fortunately, there are > some countermeasures you can take to mitigate the risk. > > > - > > Generate a new XSRF token every time if you can. The token should > include the time it was generated as part of the input to the > cryptographic > hash function you use. > - > > Separate endpoints that serve sensitive content (e.g., secrets > including session id, credit card numbers, personally identifiable > information) from endpoints that include user input in the response. > - > > If you need to mix secrets and arbitrary user input in a single HTTP > response, consider introducing some randomness to the response. For > example: > - > > Encrypt the whole AJAX response with a random key, then decrypt the > response on the client side. This effectively disables compression for > that > response. > - > > Create a random string on the server side and XOR the secret or the > user input. Then, concatenate the XORed result and the random string, > and > XOR again when you display/use it. Make sure to use a different random > string for XORing for every request. > > Finally, it’s not directly related to App Engine development, but this > kind of attack is taking place because the system is compressing data from > mixed sources (for example, XSRF token and the user input). if you’re > designing a system which both compresses and encrypts data, please keep in > mind the lesson from this attack and avoid compressing mixed data. > > We'll try to share an update if and when we learn more. > > > Thanks, > > -- Takashi Matsuo on behalf of Google Security Team > > On Tue, Aug 6, 2013 at 8:43 AM, Alex Burgel <abu...@gmail.com<javascript:> > > wrote: > >> Can someone from Google make a statement on whether App Engine is >> vulnerable to the BREACH attack that was announced recently? >> >> http://breachattack.com/ >> >> I'm not a security expert, but it looks like you are vulnerable to the >> attack if you use both SSL/TLS and HTTP compression. Since that >> configuration is handled by App Engine infrastructure, our apps may be at >> risk and we have little ability to mitigate it without help from Google. >> >> Also, a statement on the similar CRIME attack would be helpful too. >> > >> Thanks. >> >> --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 google-appengi...@googlegroups.com <javascript:>. >> To post to this group, send email to >> google-a...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-appengine. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Takashi Matsuo | Developers Programs Engineer | tma...@google.com<javascript:> > -- 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 google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
