9.08 KB, text/plain
17.12 KB, image/gif
15.12 KB, image/gif
Imagine that an active network attacker is trying to attack an HTTPS page. The HTTPS has an XSS filter that lets the attacker injecting the following HTML: <img alt="><script>alert(42)</script>xxxxxxxxxxxxxxxxxxxxxxx" src="..."> This HTML passes the site's XSS filter because it is not an XSS attack. Now, when the HTML page is sent to the user, the active network attacker (or DNS poisoner) interrupts the transmission during the xxxxxxxx bytes. Firefox sees the EOF and decides to execute the attacker's script, leading to XSS. Here's an example showing that the script runs: http://webblaze.org/abarth/tests/eof/firefox.html This bug isn't a huge problem, but it's probably worth fixing. Note that Safari and Chrome do not run the script. I'm not sure how the HTML 5 parser behaves in this case.
That fact that it works with http is no indicator that it will work with https. In https, data is sent in "records", which are either successfully received in their entirety or not received at all, so the attacker cannot arbitrarily cut off the data between two arbitrary characters of its choosing in the server's output. Also, with SSL, a premature EOF generates an error. An EOF on the underlying socket that is not preceded by SSL's special EOF record is reported to the higher layer as an error, not as an ordinary EOF. Unless FF is ignoring that error, FF should know that the page load was not entirely secure.
Oh, interesting. Regarding records, that mitigates the issue to some extent, but the attacker can always pad xxxxxxx until it crosses a record boundary. Regarding special EOF versus ordinary EOF, I haven't tested that directly. I'll try to set up a test case for that.
Here is a new test case: https://webblaze.org/abarth/tests/eof/firefox.php This page has a lot more xxxxx and then goes to sleep for a long time. I loaded this page in Firefox 3 and then shut off my wireless network connection. Once I did that, the script executed. Right after the script executed, the page got replaced with the following message: "Connection Interrupted The connection to the server was reset while the page was loading. The network link was interrupted while negotiating a connection. Please try again." So, it looks like you're right that we're catching the premature EOF as an error, but we're not doing it fast enough to stop the attacker's script from running.
I repeated this test, but in a way that causes Firefox's SSL socket to get an ordinary EOF (a TCP FIN) rather than an error termination. The results I got were: 1) an alert dialog, indicating that the script had been executed, and when I clicked OK, I got 2) a page containing a long line of "xxxxxxxxx..." I did NOT get any error about connection being interrupted (presumably because the connection got a TCP FIN). So, I confirm this bug.
Note: my test did NOT cause an SSL EOF record to be sent before the TCP FIN, so it was a true connection truncation that resulted in EOF, not timeout or RST.
This is a quirks mode behavior we can probably get rid of. If there are any subsequent quotes on the page then the mismatched quote becomes matched and this injection doesn't work. Instead, in the mismatched case we should just eat to EOF rather than supplying an assumed missing quote before the closing angle bracket. (In reply to comment #0) > Note that Safari and Chrome do not run the script. But IE does.
Is this still an issue with HTML5 parser?
(In reply to Olli Pettay [:smaug] from comment #10) > Is this still an issue with HTML5 parser? No, by design. If the stream ends inside the run of xxxxx, the img start tag token is incomplete and gets dropped. Furthermore, EOF never causes reparsing with different tokenization.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low] → [sg:low][fixed by the html5 parser]
You need to log in before you can comment on or make changes to this bug.