Still not working for even the simplest of URLs. I agree with the Apache style redirect (escaped URL/"here" text). I'll write some patches later today when I have time.
Regards, Kevin On Tue, Nov 29, 2011 at 8:23 AM, Joe Gooch <[email protected]> wrote: > This may be more realistic... at least for most urls I've worked with. It's > not all-inclusive of every possible url pattern. > > CheckURL "^[A-Za-z0-9\.\/]+(\?[A-Za-z0-9=\.&]*)?(;[A-Za-z0-9=\.&]*)?$" > > > Also note from looking at the code, it looks like CheckURL runs *after* URL > encoded expansion. Which means, if your url has a %3c in it, it'll be > expanded to <, and then checked against the regex, and get rejected. Which > might not be a problem for you. > > Ultimately I think the solution is Pound needs to write the redirect page > using URL encoding for the href link, and maybe the word "here" for the link > text. (like, for instance, apache would) If it's going to write out the link > text it should be html entity encoded. > > I passed the URLs you gave into apache and it had no problem printing an > appropriate redirect page, and/or attempting to find that type of file on the > filesystem.... so... yeah. > > Joe > >> -----Original Message----- >> From: Kevin Bowling [mailto:[email protected]] >> Sent: Tuesday, November 29, 2011 1:43 AM >> To: [email protected] >> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in redirects >> >> This looks like pretty close to what I want but there's an error (i.e. >> the regex fails to work on any normal URL I've tried). Not >> particularly strong here, any help? >> >> Regards, >> Kevin >> >> On Mon, Nov 28, 2011 at 2:18 PM, Joe Gooch <[email protected]> >> wrote: >> > You can define a CheckURL directive to trap the invalid characters. >> (for instance, I don't believe < or > can appear inline in a URL, it >> would have to be % escaped) >> > >> > http://stackoverflow.com/questions/1547899/which-characters-make-a- >> url-invalid >> > >> > Thus you might want to include a line such as: >> > CheckURL "^[!#$&-;=?-[]_a-zA-Z~]+$" >> > >> > (note the regex is based on the Leif Wickland responder... You might >> want to check the &-; and ?-[ ranges, for instance. I take no >> responsibility for correctness in your environment) >> > >> > Given the URL you have supplied the URL would throw a 500 error based >> on the " in your request and the <> characters. >> > >> > Joe >> > >> >> -----Original Message----- >> >> From: Kevin Bowling [mailto:[email protected]] >> >> Sent: Friday, November 18, 2011 1:04 AM >> >> To: [email protected] >> >> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in >> redirects >> >> >> >> Here is what the system claims the actual exploit looks like> >> >> >> >> HTTP/1.0 301 Moved Permanently >> >> Location: >> >> >> https://<domain>.com:7443/"><script>alert(document.domain)</script>.htm >> >> l >> >> Content-Type: text/html >> >> Content-Length: 264 >> >> >> >> <html><head><title>Redirect</title></head><body> Redirect You >> should >> >> go to >> >> >> <script>alert(document.domain)</script>.html">https://<domain>.com:7443 >> >> /"><script>alert(document.domain)</script>.html >> >> (https://<domain>.com:7443/)</p></body></html> >> >> >> >> GET /"><script>alert(document.domain)</script>.html HTTP/1.0 >> >> Host: <ip>:7080 >> >> User-Agent: QualysGuard >> >> >> >> On Thu, Nov 17, 2011 at 5:07 PM, Kevin Bowling >> >> <[email protected]> wrote: >> >> > Hi, >> >> > >> >> > This is very low risk because any browser that doesn't obey the >> HTTP >> >> > 301 code is likely ancient and vulnerable. >> >> > >> >> > One place this matters is automated scanning tools. I have a >> system >> >> > that is being audited for PCI compliance by a tool from qualys >> which >> >> > is basically a glorified port scanner. It passes in a >> >> > <script></script> nonsense on the URL and sure enough pound >> repeats >> >> > this in the document fallback if the HTTP 301 redirect is not >> obeyed. >> >> > >> >> > It is a bad idea, the URL should be scrubbed (hard), or simply >> >> > repeated without an <a href=...> and let the user figure it out? >> >> > >> >> > Regards, >> >> > Kevin >> >> > >> >> > -- >> >> > To unsubscribe send an email with subject unsubscribe to >> >> [email protected]. >> >> > Please contact [email protected] for questions. >> >> > >> >> >> >> -- >> >> To unsubscribe send an email with subject unsubscribe to >> >> [email protected]. >> >> Please contact [email protected] for questions. >> > >> > -- >> > To unsubscribe send an email with subject unsubscribe to >> [email protected]. >> > Please contact [email protected] for questions. >> > >> >> -- >> To unsubscribe send an email with subject unsubscribe to >> [email protected]. >> Please contact [email protected] for questions. > > -- > To unsubscribe send an email with subject unsubscribe to [email protected]. > Please contact [email protected] for questions. > -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
