Closed
Bug 279642
Opened 21 years ago
Closed 15 years ago
Request url containing escaped newline causes login form target attribute to contain the wrong value
Categories
(Bugzilla :: User Accounts, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: sean, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
This seems to be primarily a bug in L. Stein's CGI.pm library... But it also
affects Bugzilla. An effective work-around is to post form data to Bugzilla
rather than using querystring arguments. An alternative work-around involves a
single-line change to Bugzilla (see below).
If a URL contains an escaped line feed (%0a) followed by url-encoded text that
decodes to something that looks like a URL... then the Perl CGI url method with
the -relative argument will take the url-encoded url as its return value.
Consider a URL crafted to pre-fill fields in enter_bug.cgi. Suppose we have a
paragraph or two of comment text that happens to mention a URL. If a user who is
not already logged into Bugzilla follows the hyperlink/bookmark/whatever,
Bugzilla will redirect to the login page. Bugzilla::Auth::CGI calls the
$cgi->url method with -relative. This function is confused by the text in the
comment and relativizes the URL from the query string rather than the entire
URL. Therefore, when Bugzilla outputs its login form element, it uses the url in
the comment instead of the url of the enter_bug.cgi page for its action
attribute value.
Bugzilla could work-around this problem by doing something like this:
143c143
< { 'target' => $cgi->url(-relative=>1),
---
> { 'target' => $cgi->url(-absolute=>1,-query=>0),
Note that the Bugzilla login form template uses the
global/hidden-fields.html.tmpl to encode query string arguments into the login
form as hidden form field elements. That's why I asked $cgi->url to not include
the query string above... But that option does not seem to have any effect. I've
also tried -full=>1 (with and without -query=>0).
Using either the -full or -absolute arguments to $cgi->url avoids the problem
with url-looking text following line feeds in the original request URL.
Reproducible: Always
Steps to Reproduce:
1. Logout of Bugzilla
2. Visit the URL
3. Login
Actual Results:
Apache served up an error message due to the login form having an incorrect
value for its action attribute.
Expected Results:
The form's action attribute value should have indicated enter_bug.cgi so that I
could enter a bug with some of the fields pre-filled for me.
The problem in Perl CGI is fixed in version 3.05.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 2•21 years ago
|
||
That doesn't fix it in Bugzilla... we should probably require the fixed version
of CGI...
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Comment 3•20 years ago
|
||
Should we increase the minimum version of CGI to 3.05 for 2.22?
Flags: blocking2.22?
Comment 4•20 years ago
|
||
I don't think this is a blocker, but it could be good to fix it. Yes, I think requiring 3.0.5 would be fine -- that appears to be what's on RHEL4, at least.
Glob -- would it be difficult for Windows users to use 3.0.5, for any reason?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking2.22? → blocking2.22-
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.22
Version: unspecified → 2.18
(In reply to comment #4)
> Glob -- would it be difficult for Windows users to use 3.0.5, for any reason?
hrm.
activestate perl 5.8.4 has cgi 3.0.4
5.8.6 has 3.0.5 however it has a Time::Local bug (bug 281920)
i've experienced dbi crashes in higher perl versions and i generally try to avoid them.
hrm, not sure what's best.
Updated•18 years ago
|
Target Milestone: Bugzilla 2.22 → Bugzilla 3.2
Comment 6•18 years ago
|
||
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.
Target Milestone: Bugzilla 3.2 → ---
Comment 7•15 years ago
|
||
Bugzilla now requires CGI 3.21, so this is no longer a problem.
Status: NEW → RESOLVED
Closed: 21 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•