Because this is seciruy bug and is not listed by default, adding some Mozilla staff.
Created attachment 147219 [details] Tescase Simple testcase - loog at the input tag - Mozilla does not ignore its value.
I was sure we had a check for this... is the document.write necessary, or does just setting the value attribute in HTML also work?
(In reply to comment #3) > is the document.write necessary, or does > just setting the value attribute in HTML also work? Yes, it is. (I am demonstrating it on the the metioned page with "malicious code in action"). In summary: INPUT tag in HTML - OK INPUT tag created by DOM createElement - OK INPUT tag created by document.write() - VULNERABLE!
I'll have a look at this
Created attachment 147261 [details] Testcase2 - innerHTML And finaly: INPUT tag created by innerHTML has the same problem as document.write() - see testcace 2
This regressed between 2004-03-03-08 and 2004-03-04-08. Bug 232706 seems very very suspect.
Though the diff to nsHTMLInputElement looks ok....
OK, if I change that SetValue() call in nsHTMLInputElement::ParseAttribute to SetValueInternal() (which is what it should be to start with), then this bug goes away, as far as I can tell. And the bug is not present if the attribute order is reversed -- that's handled by the implementation of Reset(). So clearly the problem is that when there is script on the callstack the call to SetValue fails (which makes sense). The part I don't get is why it worked before!
i just arrived at the same conclusion. The reason it worked before is that we called SetValue *before* chaning mType. What i can't figure out is why there's a difference using document.write or using normal markup :)
> What i can't figure out is why there's a difference using document.write or > using normal markup :) Easy. In one case, there's JS on the stack, in the other there is not. Then the security manager does its security check, decides we were called from JS, and... This exact issue came up in discussion recently, in fact -- that our DOM apis are not reliable for internal use because they often perform security checks and have to guess at who the "real caller" is.
13 years ago
Comment on attachment 147273 [details] [diff] [review] this should do it The word you've entered isn't in the dictionary. Click on a spelling suggestion below or try again using the search box to the right. Suggestions for cought: 1. caught
Comment on attachment 147273 [details] [diff] [review] this should do it s/cought/caught/ and s/accidently/accidentally/, and r+sr=bzbarsky
Comment on attachment 147273 [details] [diff] [review] this should do it This patch should be very safe since all it does is to bypass some security-checks that we absolutly don't want to get cought in.
I was thinking if there was any way to trigger the same bug in the way the code was previously written, i.e. if we need to backport this patch to the 1.0 or 1.4 branches. However afaict the old way should be safe as well.
-> sicking, his patch and check-in
Comment on attachment 147273 [details] [diff] [review] this should do it a=dveditz for 1.7 branch. Please add the fixed1.7 keyword when checked in
Tested with "Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.7) Gecko/20040501 (from nightly/latest-1.7/)". Both testcases document.write() and innerHTML seem OK.
Adding Jon Granrose to CC list to help round up QA resources for verification
13 years ago
Removing security-sensitive flag for bugs on the known-vulnerabilities list
Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0759 to this issue.