This probably belongs in https://bugs.chromium.org/p/monorail but I don't know if there's a way to RestrictViewGoogle for bugs there, if we wanted to keep this private.

That said, this seems likely to be by-design. If I use an google.com account to get a token for Bugs.chromium.org and I later log out of that account on google.com, it's not clear why or how that should expire the token granted for bugs.chromium.org. Supporting cross-origin logout would require revalidation of tokens with the original authentication authority on every page load, which isn't scalable or robust.

Hello elawre...@chromium.org, Google Security Team,

I too wasn't quite sure regarding the available Privacy controls on the monorail and thus reported the issue here.

Also "By-design"??? If that is so, then similarly the granted tokens shouldn't expire for other google domains as well, eg. "wallet.google.com".

1) bugs.chromium.org implements cross-origin login, similar to several other google owned products and services.
2) All other google owned products and services implement cross-origin logout and also require re-validation of tokens with the original authentication authority on every page load, for obvious security reasons. 
3) Why should bugs.chromium.org be any different then? 

Somehow I fail to agree with the reasoning of "isn't scalable or robust" as it cannot justify unsafe security measures. Furthermore Google and its engineers are well-known for their ability to scale, and I am not only sure but confident that with a little effort this issue can be easily fixed.

Eagerly awaiting your reply.

Thanks & Regards,
~ Kushal.

+cc Chrome Infra/Monorail people for their thoughts.

The need for physical access to exploit this vulnerability greatly mitigates its impact.

Monorail is just a GAE app, we only know that the user is signed in or out based on what GAE tells us.  So, I'll try to repro this to understand it and then pass it on to the GAE team.

@dominickn,

I agree that the example scenario mentioned above might seem to need physical access.

BUT, for an attacker, this issue can be easily exploited remotely by convincing the victim to login into his/her gmail account (for eg. to create an account on some site using victim's gmail credentials) and simultaneously logging into victim's chromium bug-tracking profile (via an invisible iframe) and accessing victim's private reports. 

In that case, there is no need for physical access to exploit this vulnerability and thus does not mitigate its impact at all.

The victim might innocently logout of his/her gmail account after said operation, but the attacker would have access to victim's private reports on bugs.chromium.org and the attacker can download PoC's and view/modify/update these reports at leisure.

I repro'd this behavior on bugs.chromium.org, codereview.chromium.org, and monorail-prod.appspot.com.   So, it does not seem to be monorail-specific or specific to appengine custom domains.    I do not see the same behavior between mail.google.com and docs.google.com, so it is a difference between appengine and those other google products.

After a lot of searching for existing internal bug reports and where to report it, I gave up and just posted to the GAIA users group to see if this is considered a defect or WAI by them.

The feedback that I got is that it is working as intended for the session to last up to 5 minutes after signing out on gmail.com.  I tried it and found that I was in fact signed out on appengine after 5 minutes.

Hello jrobb...@chromium.org, Google Security Team,

Firstly, I would like to thank you for responding so quickly, I sincerely appreciate it.

Secondly, I noticed some "interesting" labels like "WontFix" and "Security_Impact-None", which I believe no serious Info-Sec individual would agree to.

If I were to follow from comment 7 & comment 8, then this appears to be WAI(Working as Intended) by the GAIA , Monorail and GAE teams at Google and in that case I would like to request you to remove Security Restrictions and assign this report "allpublic" label. 

BUT, in the case that my inference(from c#7 & c#8) is wrong and instead you do acknowledge the vulnerability and fix it, then the status cannot be "WontFix".

Nonetheless, I am sharing along with a video confirming the issue(which you already reproduced as per c#7) in the attached password-less zip file and am also sharing the dropbox link for any individual who would like to view this vulnerability, that is if it isn't fixed.

DropBox Link:- https://www.dropbox.com/s/hza2frgndj9i641/Final%20Video%20to%20send%20to%20Google.avi?dl=0

Eagerly awaiting your reply in earnest.

Thanks & Regards,
~ Kushal.

@jrobb..., could you kindly respond?

elawrence: I'll let you decide if you want to keep this issue restricted or not.