You’re welcome, glad you have a short term and long term fix in the works!
Joe
From: chasm [mailto:chasm(at)gmx.de]
Sent: Wednesday, July 04, 2012 2:50 PM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] URL Check - This method may not be used
Hi Joe,
thank you for your detailed answer.
Changing the application to use a POST Request instead does not work, because
we send a redirect to the browser to a new url (in some cases another
domain/subdomain).
Its some kind of customer login page with a self build single sign on redirect
to the real product page.
Your suggestion with the base64 encoding slipped in our next release plan,
because we have to build this into the login page as well as into all product
pages.
The short work around for now is more nasty then your suggestions - as work
arounds always are ;-)
We encapsulate the rc4crypt method, within a do while loop:
(simplified code extract)
do {
$authToken = rc4crypt($credencials);
} while (strpos($authToken, chr(0)) !== false);
$redirect = $url.'?login='.urlrawencode($authToken);
This way we do not have to fix all product pages for now but have to coordinate
the next releases with the base64 encoding.
Thank you again for making clear why pound behaves this way and how to get
around this behavior.
Best regards
Matthias
Am 03.07.2012 20:55, schrieb Joe Gooch:
I remember talking through this with Robert. The relevant code is around line
691 in pound.c:
n = cpURL(url, request + matches[2].rm_so, matches[2].rm_eo -
matches[2].rm_so);
if(n != strlen(url)) {
/* the URL probably contained a %00 aka NULL - which we don't allow
*/
addr2str(caddr, MAXBUF - 1, &from_host, 1);
logmsg(LOG_NOTICE, "(%lx) e501 URL \"%s\" (contains NULL) from %s",
pthread_self(), url, caddr);
err_reply(cl, h501, lstn->err501);
free_headers(headers);
clean_all();
return;
}
The general problem here is that C uses %00 as a string terminator. Which is
fine, I suppose. But the next thing Pound does is compare the URL against the
valid URL regular expression to make sure the user isn’t trying to slip
something damaging past the firewall. With a %00 in the string, when we remove
the URL encoding to check the URL for nasties, we would be unable to check
anything after the %00, which was unacceptable from a security standpoint.
Unfortunately, I don’t see how we can safely change this behavior.
Is it possible in your application you can accomplish this in another way?
Perhaps
1) Use a POST method instead of GET. This would have the added benefit
that your rc4crypted credentials would not be logged in your apache logs as get
parameters….
2) Base64 encode your response string before you URLencode it.. (most of
it wouldn’t need URLEncoding at that point, just the symbols), and send that
in the GET request
Joe
From: Chasm(at)gmx.de<mailto:Chasm(at)gmx.de> [mailto:Chasm(at)gmx.de]
Sent: Monday, July 02, 2012 3:08 AM
To: pound(at)apsis.ch<mailto:pound(at)apsis.ch>
Subject: [Pound Mailing List] URL Check - This method may not be used
Hi,
we use the actual stable version of pound 2.6 in production environment.
We have a customer login page from where we redirect our customers to the
special product page they will use.
In this redirect (its done on the backend servers) url we build in the user
credencials and encrypt these data with rc4crypt. After encrypting the url
parameters, we use the php function urlencode to make the encrypted data for
browsers acceptable.
So the final redirect link will look like this example:
https://www.example.com/?login=%81%00x%D5%3D2%C5%DC%E4%9B%CBy%8D%CE%8C%9C%DC%8CV%C0%91%A7%C2F%8C%5B%1DL%1E%9D%1D%B4%A0f%7DS%A3%87y8%82%1Co%02q
As you can see, there is a %00 in the data part.
Before pound version 2.6 we used pound version 2.4 and it worked fine.
But with version 2.6 the client (browser) got the message "This method may not
be used.".
We could not find the 501 in the Backend logs.
Its a pound 501 response: config.c: res->err501 = "This method may not be
used.";
How could we avoid this error message?
Is there a config flag for this checks?
Thank you for reading
Matthias
[...]
|
