Please explain "internal redirect". My read of CGI.pm 2.46 shows that redirect() merely produces Status: 302 Moved and Location: headers, which get sent back to the browser. How could this result in private pages being made visible?
Is there something going on here that isn't obvious?
Update: I've tried this on both IIS and Apache, and in both cases a Location: header is send back to the browser, even for a scheme-less URL.
I may have misunderstood what you meant by "internal transfer," which seemed to imply that this could expose files that weren't otherwise available to a browser that knew their name.
Update*2:It turns out that the behavior I'm observing and the behavior merlyn is claiming is based, at least for Apache, on the presense or absense of the Status: 302 header. With that header present, Apache generates an external redirect, though IIS will generate an internal one.
that is,
print "Location: /xyz/foo.txt\n\n";
and
use CGI;
my $q = new CGI();
print $q->redirect("/xyz/foo.txt");
will yield different results on Apache (1.3.17) and IIS 4.0. Bleh.
| [reply]
[d/l]
[select] |
| [reply] |
FWIW, the servers I run this script on do not have any access restricted pages, and the redirects are always local (relative) URLs anyway.
What's interesting is that I did a packet capture using this script with Apache (1.3.14/Linux) and it did in fact pass a "302 Moved" back to the browser, and my browser immediately proceeded to fetch the indicated page. So how do you mean "internal" redirect?
Also, what do you mean by "The tr/// does nothing"? It does seem to handily eat any characters that aren't in the list -- or did you mean that it doesn't do anything with regards to security?
I'm anxious to hear your opinion on this in slighly more depth, and what could be done to improve the code. Perhaps always returning the redirect with an absolute URL?
Thanks for your help...
Signature void where prohibited by law. | [reply] |
The tr/// does nothing. This:
tr/[^\w\/\.\-\?\=\&\@\%]//
does nothing. When there's no right side, and no flags, the left side is copied
to the right side, and thus we've got a mapping of % to itself, w to itself, and so on.
Which brings up the second problem. You seem to be treating it like a s///,
rather than a tr///, and they share only the slashes. {grin}
There's no "character classes" in tr///, nor do the square brackets mean
what you think they mean, nor does the \w mean anything other than backslash
followed by the letter w.
As for the "external redirect" issue, dws and tilly helped me determine that CGI.pm now in fact (in violation of the spec) sends both a Status-302 and a Location
header to the server, which the server error-corrects by turning an internal redirect into a fully-qualified external redirect. Ewww. This is sooooo broken, and was therefore unexpected when I posted my first note.
So, you're safe, but only because others have padded the hallways for you, and only because everybody is error-correcting for you. {grin}
-- Randal L. Schwartz, Perl hacker | [reply]
[d/l] |
So what I really needed to do was change the tr/// into an s/// construct. I didn't realize that tr wasn't interpolated like s is. Hmm.
With regards to the second issue, how would you modify the code to send a correctly formatted redirect? Would you manually print(); the "Status" and "Location" headers, or is there some other way I don't know about?
A newly-shaven initiate thanks you...
Signature void where prohibited by law.
| [reply] |