Keep your eyes open
In October, I saw the following lines in the HTTP logs for the Tarsnap website (the private network IP address is due to my use of jailed stunnel for terminating the SSL connection):www.tarsnap.com 192.168.0.44 - - [27/Oct/2009:22:02:14 +0000] "POST /confirm.cgi HTTP/1.1" 303 - "https://www.tarsnap.com/confirm.cgi?address=XXXXXX&cookie=XXXXXX" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9"I sent an email to Apple, and earlier this week they released large number of security updates for Safari, including the following:
www.tarsnap.com 192.168.0.44 - - [27/Oct/2009:22:02:16 +0000] "GET /confirmed.html HTTP/1.1" 200 2009 "https://www.tarsnap.com/confirm.cgi?address=XXXXXX&cookie=XXXXXX" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9"
WebKit
CVE-ID: CVE-2010-1406
Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.8, Mac OS X Server v10.5.8, Mac OS X v10.6.2 or later, Mac OS X Server v10.6.2 or later, Windows 7, Vista, XP SP2 or later
Impact: Visiting an HTTPS site which redirects to an HTTP site may lead to an information disclosure
Description: When WebKit is redirected from an HTTPS site to an HTTP site, the Referer header is passed to the HTTP site. This can lead to the disclosure of sensitive information contained in the URL of the HTTPS site. This issue is addressed by not passing the Referer header when an HTTPS site redirects to an HTTP site. Credit to Colin Percival of Tarsnap for reporting this issue.
This is a very minor security issue: The HTTP standard states that when accessing a page via HTTP, the Referer header should be cleared rather than including an HTTPS link. WebKit generally gets this right; but prior to this fix, it would improperly include the Referer header when being redirected from an HTTPS URL to an HTTP URL (e.g., via an HTTP 303 'See Other' response).
No matter how insignificant the vulnerability is, however, it serves to illustrate an important point from my blog post last September about the inherent insecurity attached to code complexity: Eschew obfuscation! I noticed this vulnerability because I had my eyes open and the evidence of the bug was right in front of me; if that evidence had been in any way obfuscated, I might as well have had my eyes closed. Now, I suspect that very few people deliberately obfuscate their log files; but the principle applies elsewhere: Whether you're looking at source code, data files on disk, or bits being sent over a network, the easier material is to read and understand, the more likely it is that you'll notice and be able to fix vulnerabilities before your product ships -- and that you'll notice the vulnerabilities not just while specifically looking for them, but also while working on something completely different and saying to yourself "gee, that looks odd".
Isaac Asimov is often claimed to have remarked that the most exciting phrase to hear in science is not "Eureka!" but rather "That's funny..."; the same is true of computer security. Keep your eyes open and avoid obscuring your vision with obfuscation, and you're far more likely to find yourself saying those same words.