Re: Patch: PR#7063

2002-03-27 Thread Raphael Amaury Jacquot

On Mon, 2002-03-25 at 23:23, Marc Slemko wrote:
 On Mon, 25 Mar 2002, Eli Marmor wrote:
 
  And a yet another note:
  
  It is not a bug that sometime causes problems;
  It is a bug that causes mod_auth_digest to fail ALWAYS (when there are
  parameters, of course).
 
 That is defined as sometimes.  And it is only IE with which it fails,
 no?

No, mozilla (all platforms) does this too

 
  So it looks important for me to commit this patch.
  Especially when there is no need to dig into the source, find the
  problem, fix it, and test it, but everything is ready and you just have
  to commit.
 
 Isn't this a matter of IE incorrectly implementing the spec?  
 
 Will making this change break browsers that do properly implement it?
 
 It is not obvious if or how we should attempt to cope with IE's 
 brokenness, so it is not something that can just be blindly
 applied.  Blindly ignoring the query string on a request can have
 security implications as well that need to be understood.




Re: Patch: PR#7063

2002-03-27 Thread Marc Slemko

On 27 Mar 2002, Raphael Amaury Jacquot wrote:

 On Mon, 2002-03-25 at 23:23, Marc Slemko wrote:
  On Mon, 25 Mar 2002, Eli Marmor wrote:
  
   And a yet another note:
   
   It is not a bug that sometime causes problems;
   It is a bug that causes mod_auth_digest to fail ALWAYS (when there are
   parameters, of course).
  
  That is defined as sometimes.  And it is only IE with which it fails,
  no?
 
 No, mozilla (all platforms) does this too

Odd, since it works for me...

What version of Mozilla is this?  0.9.7 and 0.9.9 both work with 
query strings.  (eg. http://server/foo?bar=taz)

Try http://www.apache.org/~marc/digest/?C=MO=A

login user / password

Works for me in Mozilla.

Fails in IE because IE doesn't send the query string as part of the digest
uri.

On Tue, 26 Mar 2002, Eli Marmor wrote:

 Marc Slemko wrote:
 
  Isn't this a matter of IE incorrectly implementing the spec?
 
 I'm not sure that this is the famous incompatibility between IE and
 Apache. But I'm not sure it isn't, too. In any case, something in the
 current code looks strange, and doesn't make sense. Are you sure that
 the ifdefed code implements the RFC?

What looks odd about the current code?

It does some odd questionable comparison shortcuts, but they still
appear to work from my quick glance.  It is checking to make sure the
query string part of the URI matches.  

 
  Will making this change break browsers that do properly implement it?
  
  It is not obvious if or how we should attempt to cope with IE's
  brokenness, so it is not something that can just be blindly
  applied.  Blindly ignoring the query string on a request can have
  security implications as well that need to be understood.
 
 I don't see any security problem with it.

Doesn't it allow replay attacks using different query strings?




Re: Patch: PR#7063

2002-03-25 Thread Marc Slemko

On Mon, 25 Mar 2002, Eli Marmor wrote:

 And a yet another note:
 
 It is not a bug that sometime causes problems;
 It is a bug that causes mod_auth_digest to fail ALWAYS (when there are
 parameters, of course).

That is defined as sometimes.  And it is only IE with which it fails,
no?

 So it looks important for me to commit this patch.
 Especially when there is no need to dig into the source, find the
 problem, fix it, and test it, but everything is ready and you just have
 to commit.

Isn't this a matter of IE incorrectly implementing the spec?  

Will making this change break browsers that do properly implement it?

It is not obvious if or how we should attempt to cope with IE's 
brokenness, so it is not something that can just be blindly
applied.  Blindly ignoring the query string on a request can have
security implications as well that need to be understood.




Re: Patch: PR#7063

2002-03-25 Thread Ian Holsman

Marc Slemko wrote:
 On Mon, 25 Mar 2002, Eli Marmor wrote:
 
 
And a yet another note:

It is not a bug that sometime causes problems;
It is a bug that causes mod_auth_digest to fail ALWAYS (when there are
parameters, of course).
 
 
 That is defined as sometimes.  And it is only IE with which it fails,
 no?
 
 
So it looks important for me to commit this patch.
Especially when there is no need to dig into the source, find the
problem, fix it, and test it, but everything is ready and you just have
to commit.
 
 
 Isn't this a matter of IE incorrectly implementing the spec?  
 
 Will making this change break browsers that do properly implement it?
 
should we implement this kind of thing by way of a 'browsermatch ...'
so that we could live in the best of both worlds? or is this still a 
security issue for IE users?

 It is not obvious if or how we should attempt to cope with IE's 
 brokenness, so it is not something that can just be blindly
 applied.  Blindly ignoring the query string on a request can have
 security implications as well that need to be understood.
 






Re: Patch: PR#7063

2002-03-25 Thread Eli Marmor

Marc Slemko wrote:

 Isn't this a matter of IE incorrectly implementing the spec?

I'm not sure that this is the famous incompatibility between IE and
Apache. But I'm not sure it isn't, too. In any case, something in the
current code looks strange, and doesn't make sense. Are you sure that
the ifdefed code implements the RFC?

 Will making this change break browsers that do properly implement it?
 
 It is not obvious if or how we should attempt to cope with IE's
 brokenness, so it is not something that can just be blindly
 applied.  Blindly ignoring the query string on a request can have
 security implications as well that need to be understood.

I don't see any security problem with it.
I suggest to consider Ian's suggestion:

 should we implement this kind of thing by way of a 'browsermatch ...'
 so that we could live in the best of both worlds? or is this still a 
 security issue for IE users?

(last quotation is from Ian)

-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel



Patch: PR#7063

2002-03-24 Thread Eli Marmor

HTTP GET requests with parameters (? and something after it) don't
work with mod_auth_digest of Apache 2.0 (I'm using CVS snapshot
httpd-2.0_2002032321.tar.gz).

It seems that the cause is PR#7063.

With basic auth, everything works flawlessly, and the only problem is
with digest.

From looking at the source, it seems simple to resolve (please commit
it):

-
--- modules/aaa/mod_auth_digest.bugMon Mar 25 06:37:39 2002
+++ modules/aaa/mod_auth_digest.c   Mon Mar 25 06:38:19 2002
@@ -1771,10 +1771,12 @@
 /* or '*' matches empty path in scheme://host */
  !(d_uri.path  !r_uri.path  resp-psd_request_uri-hostname
  d_uri.path[0] == '*'  d_uri.path[1] == '\0'))
+#ifdef BUGGY_DIGEST
 /* check that query matches */
 || (d_uri.query != r_uri.query
  (!d_uri.query || !r_uri.query
 || strcmp(d_uri.query, r_uri.query)))
+#endif
 ) {
 ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, r,
   Digest: uri mismatch - %s does not match 
-

Thanks,
-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel



Re: Patch: PR#7063

2002-03-24 Thread Amaury Jacquot

Quoting Eli Marmor [EMAIL PROTECTED]:

 HTTP GET requests with parameters (? and something after it) don't
 work with mod_auth_digest of Apache 2.0 (I'm using CVS snapshot
 httpd-2.0_2002032321.tar.gz).

Note:
I had the same problem in the 1.3 branch (patched and it worked)
I had sent this same patche for it some time ago, but nobody noted

Sincerely

Amaury

 It seems that the cause is PR#7063.
 
 With basic auth, everything works flawlessly, and the only problem is
 with digest.
 
 From looking at the source, it seems simple to resolve (please commit
 it):
 
 -
 --- modules/aaa/mod_auth_digest.bugMon Mar 25 06:37:39 2002
 +++ modules/aaa/mod_auth_digest.c   Mon Mar 25 06:38:19 2002
 @@ -1771,10 +1771,12 @@
  /* or '*' matches empty path in scheme://host */
   !(d_uri.path  !r_uri.path 
 resp-psd_request_uri-hostname
   d_uri.path[0] == '*'  d_uri.path[1] == '\0'))
 +#ifdef BUGGY_DIGEST
  /* check that query matches */
  || (d_uri.query != r_uri.query
   (!d_uri.query || !r_uri.query
  || strcmp(d_uri.query, r_uri.query)))
 +#endif
  ) {
  ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, r,
Digest: uri mismatch - %s does not match 
 -
 
 Thanks,
 -- 
 Eli Marmor
 [EMAIL PROTECTED]
 CTO, Founder
 Netmask (El-Mar) Internet Technologies Ltd.
 __
 Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
 Fax.:   +972-9-766-1314  P.O.B. 7004
 Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel
 


-- 



Re: Patch: PR#7063

2002-03-24 Thread Eli Marmor

Amaury Jacquot wrote:
 
 Quoting Eli Marmor [EMAIL PROTECTED]:
 
  HTTP GET requests with parameters (? and something after it) don't
  work with mod_auth_digest of Apache 2.0 (I'm using CVS snapshot
  httpd-2.0_2002032321.tar.gz).
 
 Note:
 I had the same problem in the 1.3 branch (patched and it worked)
 I had sent this same patche for it some time ago, but nobody noted

  It seems that the cause is PR#7063.
 
  With basic auth, everything works flawlessly, and the only problem is
  with digest.
 
  From looking at the source, it seems simple to resolve (please commit
  it):
 
  -
  --- modules/aaa/mod_auth_digest.bugMon Mar 25 06:37:39 2002
  +++ modules/aaa/mod_auth_digest.c   Mon Mar 25 06:38:19 2002
  @@ -1771,10 +1771,12 @@

And a yet another note:

It is not a bug that sometime causes problems;
It is a bug that causes mod_auth_digest to fail ALWAYS (when there are
parameters, of course).
So it looks important for me to commit this patch.
Especially when there is no need to dig into the source, find the
problem, fix it, and test it, but everything is ready and you just have
to commit.

-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__
Tel.:   +972-9-766-1020  8 Yad-Harutzim St.
Fax.:   +972-9-766-1314  P.O.B. 7004
Mobile: +972-50-23-7338  Kfar-Saba 44641, Israel