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.
