761141 - Firefox 12 Keeps on Processing/Transferring Data when CSP is in Place & Injection Based on HTML <img> Tag

Status: RESOLVED WORKSFORME

Description

[Ashar Javed]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

Hi,

I have found an interesting case in which Firefox 12 keeps on fetching/transferring data from the URL when CSP is in place and injection based on <img> tag. I have also tested the same thing in Nightly 15.0a1 (04-06-2012 update) & Nightly works fine. 


Actual results:

I have a CSP test-bed available at http://www.mobilefuxx.de/csp/xsstest/test.php. The CSP policy is 'self' for every type of resource.

Using Firefox 12, On the test-bed URL if I inject the following vector:

'';!--"<XSS>=&{()}<img src="http://placekitten.com/100/100" onerror="this.src='http://placekitten.com/100/100';"><

You will see Firefox keeps on fetching information from the URL. You can check it by opening the "Error Console" window & you will see it keeps on processing and one can not even clear the Error Console Window. Another thing I have noticed is that if you will stop Firefox 12, even then you will see it keeps on displaying warning messages until you have to restart Firefox 12.

Applying same thing on Nightly results in the following warning message and Nightly works fine.

Timestamp: 04.06.2012 15:03:53
Warning: CSP WARN:  Directive "img-src http://www.mobilefuxx.de:80" violated by http://placekitten.com/100/100


Timestamp: 04.06.2012 15:03:53
Warning: CSP WARN:  Directive "inline script base restriction" violated

Source File: http://www.mobilefuxx.de/csp/xsstest/test.php
Line: 0
Source Code:
onerror attribute on IMG element

Timestamp: 04.06.2012 15:03:53
Warning: CSP WARN:  Directive "img-src http://www.mobilefuxx.de:80" violated by http://placekitten.com/100/100





Expected results:

Would you please look into the issue? Thanks!

Comment 1

[Matthias Versen [:Matti]]

>Would you please look into the issue? Thanks!
This is already fixed from your statement in this report.
I don't understand why someone should look at this when this issue is already fixed.

Did I misunderstand something ?
I'm tempted to close this report as wfm

Comment 2

[Ashar Javed]

Ok Matthias. I have found & I thought that I should report this to you guys. You can go ahead regarding closing the bug. Thanks!