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

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]
Sent: Monday, July 02, 2012 3:08 AM
To: 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

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] 
                  Sent: Monday, July 02, 2012 3:08 AM
                  To: 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