Quantifying the Impact of “Cloudbleed”
It was my understanding that people were finding numerous examples of leaked data that included Authorization headers, which don&#x27;t always leak <i>passwords</i> but which still leak session keys. Maybe if espadrine from this linked comment reads this, he could explain more?<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13719455" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13719455</a><p>FWIW, as an example, Grindr uses CloudFlare: do a Google search for &quot;authorization: grindr3&quot; and you will find a URL which (no longer cached but you can still get snippets) contained an authenticated grindr request, which would be enough to have had temporary access to that person&#x27;s account.<p><a href="https:&#x2F;&#x2F;costumla.com&#x2F;wild-west-costumes-for-men.html" rel="nofollow">https:&#x2F;&#x2F;costumla.com&#x2F;wild-west-costumes-for-men.html</a><p>&quot;... U Edge Certificate Authority1 0 U San Francisco1 0 U California�1p ���U� N��U � � �f&quot;�0! %���U@ @GET &#x2F;v3&#x2F;profiles&#x2F;<i>[REDACTED]</i> HTTP&#x2F;1.1 CF-RAY: 33282514b8d957d7 FL-Server: 15f76 Host: grindr.mobi X-Real-IP: <i>[REDACTED]</i> Accept-Encoding: gzip Client-Accept-Encoding: gzip X-Forwarded-Proto: https Connect-Via-Https : on Connect-Via-Port: 443 Connect-Via-IP: 104.16.85.62 Connect-Via-Host: grindr.mobi CF-Visitor: {&quot;scheme&quot;:&quot;https&quot;} CF-Host-Origin-IP: <i>[REDACTED]</i> Zone-ID: 22252132 Owner-ID: 2607399 CF-Int-Brand-ID: 100 Zone-Name: grindr.mobi Connection: Keep-Alive X-SSL-Protocol: TLSv1.2 X-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256 X-SSL-Server-Name: grindr.mobi X-SSL-Session-Reused: . SSL-Server-IP: 104.16.85.62 X-SSL-Connection-ID: 15d1b8de6025864d-DFW X-SPDY-Protocol: 3.1 authorization: Grindr3 ... accept: application&#x2F;json user-agent: grindr3&#x2F;3.0.13.16790;16790;Free;Android 6.0 CF-Use-OB: 0 Set-Expires-TTL: 14400 CF-Cache-Max-File-Size: 512m Set-SSL-Name: grindr.mobi CF-Cache-Level: byc CF-Unbuffered-Upload: 0 Set-SSL-Client-Cert: 0 Set-Limit-Conn-Cache-Host: 50000 CF-WAN-RG5: 0 CF-Brand-Name: cloudflare CF-Age-Header-Enabled: 0 CF-Respect-Strong-Etag: 0 Set-Proxy-Read-Timeout: 100 Set-Proxy-Send-Timeout: 30 CF-Connecting-IP: <i>[REDACTED]</i> Set-Proxy-Connect-Timeout: 90 Set-Cache-Bypass: 0 Set-SSL-Verify: 0 CF-Force-Miss-TS: 0 Set-Buffering: 0 CF-Pref-OB: 1 Set-Keepalive: 1 CF-Pref-Geoloc: 1 CF-Use-BYC: 0 CF-IPCountry: <i>[REDACTED]</i> CF-IPType ...&quot;<p>edit: I have spent the last fifteen minutes pulling the search snippet (edit: and now an hour; but all on my phone, so this is harder than it should be, and I also am distracted by other stuff). The way you do this is by walking through the parts you can see to get nearby context. (I do this a lot to pull content purged from or inaccessible to or simply updated in Google&#x27;s cache.)<p>In so doing, while I haven&#x27;t been able to still have access to the session key (likely too long and unique for a snippet), I <i>have</i> pulled the X-Real-IP address field of this Grindr user and a profile identifier they were checking out (both of which I redacted above, but you could trivially get yourself now using that context).<p>CloudFlare: if you think there isn&#x27;t private data that was leaked, <i>OR EVEN PRIVATE DATA STILL ACCESSIBLE</i>, you are a bunch of fucking idiots. 1) Clearing the cache isn&#x27;t sufficient, as for anything built from short plain text words we can pull the snippet. 2) IP addresses and session keys count as &quot;private data&quot;. 3) GET requests actually <i>are</i> often sensitive information :&#x2F;.