Bil, .22% can be a rather dramatic number of users if you are running, say, a very popular social media, bill payment or eCommerce system. I conjecture that the % of users who have their referrer headers stripped is a great deal higher if you only measure "enterprise" users (a opposed to normal consumers). This may have an even greater impact on specific web-based companies that focus on serving enterprise customers. -- Jim Manico VP, Security Architecture WhiteHat Security (808) 652-3805 On Mar 9, 2012, at 4:57 AM, Bil Corry <bil@corry.biz> wrote: > James Manico wrote on 3/2/2012 1:24 PM: >> Referrer header defense is reasonable for intranet facing applications >> where referrer header policy is controlled. >> >> Some organizations choose to strip all outbound referrer headers to >> prevent information leakage. Therefor referrer defense of this nature >> is not always workable for internet facing applications. >> >> So really, you are better off using entropy (random tokens) for CSRF >> defense, and proper validation and escaping for XSS defense. > > Using the referrer as a CSRF defense works when the site is HTTPS and you disallow requests with an omitted referrer header. Only a tiny fraction of internet users suppress the referrer header over HTTPS: > > "The Referer header can be used as a CSRF defense for HTTPS requests. In order to use the Referer header as a CSRF defense, a site must reject requests that omit the header because an attacker can cause the browser to suppress the header. Over HTTP, sites cannot afford to block requests that lack a Referer header because they would cease to be compatible with the sizable percentage (roughly 3–11%) of users. Over HTTPS, however, strict Referer validation is feasible because only a tiny percentage (0.05–0.22%) of browsers suppress the header. In particular, strict Referer validation is well-suited for preventing login CSRF because login requests are typically issued over HTTPS." > > Source: http://seclab.stanford.edu/websec/csrf/csrf.pdf > > > That paper discusses various techniques for CSRF defense and is worth a read for those interested in this topic. > > > - Bil

Jim, I was answering the question as to whether the referrer could be used as a CSRF defense - it can given the restrictions and limitations mentioned. Is it a good solution for everyone? No, but I would submit that the referrer method is far simpler to implement and get right for a small company with limited technical resources than propagating a cryptographically-strong random nonce throughout the site. I agree it's important to understand the traffic showing up at the actual webapp you're protecting and in turn, making decisions based on the business model of the webapp -- clearly if your paying customers block the referrer header, then you'll probably be motivated to accommodate them. - Bil James Manico wrote on 3/8/2012 9:08 PM: > Bil, > > .22% can be a rather dramatic number > of users if you are running, say, a very popular social media, bill > payment or eCommerce system. > > I conjecture that the % of users who have their referrer headers > stripped is a great deal higher if you only measure "enterprise" users > (a opposed to normal consumers). This may have an even greater impact > on specific web-based companies that focus on serving enterprise > customers. > > -- > Jim Manico > VP, Security Architecture > WhiteHat Security > (808) 652-3805 > > On Mar 9, 2012, at 4:57 AM, Bil Corry<bil@corry.biz> wrote: > >> James Manico wrote on 3/2/2012 1:24 PM: >>> Referrer header defense is reasonable for intranet facing applications >>> where referrer header policy is controlled. >>> >>> Some organizations choose to strip all outbound referrer headers to >>> prevent information leakage. Therefor referrer defense of this nature >>> is not always workable for internet facing applications. >>> >>> So really, you are better off using entropy (random tokens) for CSRF >>> defense, and proper validation and escaping for XSS defense. >> >> Using the referrer as a CSRF defense works when the site is HTTPS and you disallow requests with an omitted referrer header. Only a tiny fraction of internet users suppress the referrer header over HTTPS: >> >> "The Referer header can be used as a CSRF defense for HTTPS requests. In order to use the Referer header as a CSRF defense, a site must reject requests that omit the header because an attacker can cause the browser to suppress the header. Over HTTP, sites cannot afford to block requests that lack a Referer header because they would cease to be compatible with the sizable percentage (roughly 3–11%) of users. Over HTTPS, however, strict Referer validation is feasible because only a tiny percentage (0.05–0.22%) of browsers suppress the header. In particular, strict Referer validation is well-suited for preventing login CSRF because login requests are typically issued over HTTPS." >> >> Source: http://seclab.stanford.edu/websec/csrf/csrf.pdf >> >> >> That paper discusses various techniques for CSRF defense and is worth a read for those interested in this topic. >> >> >> - Bil >