While reviewing IDS logs at work today, I noticed that the Snort Bleeding-Edge rule "BLEEDING-EDGE CURRENT EVENTS Google Calendar in Use" (Snort SID 1:2003597) had fired.. Looking at the logged request, I noticed that it logged a URL similar to:
http://www.google.com/calendar/feeds/COWORKER%40gmail.com/private-98d32c472
5baf853a1c50c4485c9XXXX/full?start-min=2007-04-30T00:00:00&start-max=2007-05
-05T00:00:00
(note, actual calendar name and Session-ID have been changed to protect the innocent, so link will not work)
But the URL basically includes: /username/auth-token
Upon clicking on the initial unmodified link, it allowed me to view my coworker's private Google calendar..
It appears that Google is ignoring a fundamental rule of web application security. "Thall shall not expose any credentials in URLs"
Referencing item A3 Broken Authentication and Session Management of the OWASP Top 10
From the Session ID Protection section: First, they should never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded to a ‘friend’.
This also includes web proxy logs and IDS logs.
Quote from a friend of mine: " but it's Google.. you don't have to be secure, you just have to be easy "
No comments:
Post a Comment