Cookie Security Concern

[Google Code Exporter]

We have an iOS app that uses the google ios SDK. This means that we also 
authenticate users via Oauth. Recently a third party company scanned our app 
and found that the Google iOS SDK does in fact set cookies during the oauth 
process as it does use a UIWebViewBrowser. No surprise here but the third party 
claims that the contents of 'Cookies.binarycookies' contains sensitive data and 
should not be written to disk. The specific cookie they reference starts with 
the substring 'LSOSID=' and is set for the 'accounts.google.com'. Does anybody 
know what the contents of this cookie contains and if it is actually sensitive 
information (I would be surprised if it was). Thanks for your help.

Original issue reported on code.google.com by [e-mail] on 2 Sep 2014 at 9:03

[Google Code Exporter]

When you say "Google iOS SDK", which one do you mean?  
https://code.google.com/p/gtm-oauth2/ (or https://code.google.com/p/gtm-oauth/ 
since you said OAuth and not OAuth2).  Or 
https://developers.google.com/+/mobile/ios/?  Or something else?  Just trying 
to make sure we know which specifics you are talking about.

Original comment by [e-mail] on 3 Sep 2014 at 2:45

[Google Code Exporter]

My bad for not specifying in the original bug, we are in fact using the 
gtm-oauth2 project.  Let me know if you need any additional details.

Original comment by [e-mail] on 3 Sep 2014 at 5:25

[Google Code Exporter]

The LSOSID cookie by itself, should be an issue.  If you are on the current 
version of the SDK, the GTMOAuth2ViewControllerTouch has methods where we try 
to save/restore the browser cookies before/after the flow so the signin doesn't 
leak to other webview.  You might want to check the flow to confirm that 
controllers viewWillDisappear: is getting called to do the cleanup.

Original comment by [e-mail] on 15 Sep 2014 at 8:14

[Google Code Exporter]

Developer support for Google authentication services is available via the links 
at https://developers.google.com/accounts/forum

Original comment by [e-mail] on 19 Dec 2014 at 2:32

• Changed state: Invalid