Re: CSP and web analytics

2011/6/8 gaz Heyes <gazheyes@gmail.com>

> On 8 June 2011 12:19, John Wilander <john.wilander@owasp.org> wrote:
>
>> To get ready for Content Security Policy in production organizations have
>> to get JavaScript guidelines in place stating no inline JavaScript, only
>> JavaScript in files. That's fine for in-house developers but I'm starting to
>> get worried about web analytics tools such as Omniture SiteCatalyst and
>> Google Analytics. These are very popular out there and the decision to use
>> them are typically made by managers closer to money than the security
>> department typically is.
>>
>
> As I see it there are two problems a) Sites will wrongly implement a CSP
> policy with inline enabled (xss protection off) to make analytics work
> rather that put them in a separate file. b) The analytics on the page will
> be abused to log their xss attacks without using another external server.
> Both break CSP at the core IMO and unless an alternative method is developed
> to handle inline script then it drastically reduces CSP effectiveness.
>

I actually started thinking about whitelisted script element ids to augment
CSP statements and allow for e.g. inline analytics blocks. But then I ran
into what we'd like to call "DOM Identity Theft" since browsers are
specified to return the *first* element with the given id when
getElementById() is called. Is the technique already known? Under a
different name?.

Signed code blocks are to fragile I think. Randomized ids may be a way
forward – whitelist a given script element id, browser augments it with
random string at rendering.

Well, well. I've got in contact with Omniture now at least. They think we
might be able to work it out, file-only.

   /John

-- 
John Wilander, https://twitter.com/johnwilander
Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
Conf Comm, http://www.owasp.org/index.php/Global_Conferences_Committee<http://owaspsweden.blogspot.com>