Re: [Pound Mailing List] URL Check - This method may not be used

[chasm]

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: ch...@gmx.de [mailto:ch...@gmx.de] Sent: Monday, July 02, 2012 3:08 AM To: pound@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 -- To unsubscribe send an email with subject unsubscribe to pound@apsis.ch. Please contact ro...@apsis.ch for questions.