if your only goal is to make sure there aren't any forbidden
characters (rather than validate the whole URL) a simpler
regex would be easier to manage:
'^[-A-Za-z0-9\.\?=&+~_%/:@;!()]{1,}$'
that glob has all the RFC 1738 allowed and reserved characters
without trying to care about where they appear in the URL. you
may have to escape the curly braces at the end. if you want
to be more liberal you can add |, (), [], and {}.
alex
--- On Tue, 11/29/11, Kevin Bowling <[email protected]> wrote:
> From: Kevin Bowling <[email protected]>
> Subject: Re: [Pound Mailing List] Pound CSRF vulnerability in redirects
> To: [email protected]
> Date: Tuesday, November 29, 2011, 9:42 AM
> 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.
>
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
