auth in url funnies

[svilen <az...@svilendobrev.com>]

g'day
i am playing with the plain user:psw auth in url, and it gives funny
results. at least to me.. (couchdb 1.2.0 in latest ubuntu)

i register some user, say name=a/psw=b.

with auth:
$ curl GET http://a:b@/_users/org.couchdb.user:a 
is fine

without auth:
$ curl GET http://_users/org.couchdb.user:a 
returns 404 {"error":"not_found","reason":"missing"}

now with auth, but in browsers:
 - opera http://a:b@/_users/org.couchdb.user:a works
 - firefox http://a:b@/_users/org.couchdb.user:a warns about "server not
 needing authentication".. and strips the usr/psw yielding 404
 - iexplorer - 404 - strips unconditionaly

is this something that is expected to be so? 
maybe the error can be changed (to 401) ?

i don't know that part about the "server not needing authentication" ..
maybe something in the headers ? or some config of couch_httpd_auth ?

ciao
svilen

Re: auth in url funnies

[Robert Newson <rn...@apache.org>]

We return a 401 with {"error":"unauthorized","reason":"Name or
password is incorrect."} for the case when the username does not match
a valid user and the case where the username matches but the password
does not.

If you do find a gap in this, please email security@couchdb.apache.org.

B.

On 22 March 2013 13:58, svilen <az...@svilendobrev.com> wrote:
> fine. i meant that if i'm about to try guess some couchdb server
> users, if wrongusr:wrongpsw@SRV/_session is "revealing" the 401 then
> there's no point in hiding wrongusr:wrongpsw@SRV/_users/wrongusr behind
> 404. it's a weak "protection".
> but anyway.. nevermind.
>
> On Fri, 22 Mar 2013 13:43:49 +0000
> Robert Newson <rn...@apache.org> wrote:
>
>> returning 404 for /_session would be saying that /_session doesn't
>> exist unless you have credentials. This goes too far, there's nothing
>> secret about the existence of the /_session endpoint.
>>
>> Compare to GitHub. They return a 404 for any /accountname/projectname
>> that doesn't exist at all, and they return 404 for any
>> /accountname/projectname that *does* exist but is private. From the
>> point of view of someone without authorization to see that project
>> it's effectively not there. Returning 404 in the first case and 401 in
>> the second case would reveal information that should not be revealed.
>>
>> In the users db case, the resource at
>> /_users/name_of_someone_that_isn't_me is 404 unless you are allowed to
>> see it, for the same reason.
>>
>> B.
>>
>> On 22 March 2013 13:36, svilen <az...@svilendobrev.com> wrote:
>> > hmm
>> > shouldnt then /_session behave same?
>> > it returns 401
>> >
>> > On Fri, 22 Mar 2013 13:24:28 +0000
>> > Robert Newson <rn...@apache.org> wrote:
>> >
>> >> Sure, and it's deliberately not helpful;
>> >>
>> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5
>> >>
>> >> "This status code is commonly used when the server does not wish to
>> >> reveal exactly why the request has been refused..."
>> >>
>> >> Returning 401 vs 404 would reveal which user names exist.
>> >>
>> >> B.
>> >>
>> >> On 22 March 2013 13:20, svilen <az...@svilendobrev.com> wrote:
>> >> > that's fine. just the error isn't very helpful..
>> >> > and the browsers don't play nice.
>> >> > anyway
>> >> >
>> >> >> That's by design. In 1.2.0 you can only see your own user
>> >> >> document.
>> >> >>
>> >> >> B.
>> >> >>
>> >> >> On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
>> >> >> > g'day
>> >> >> > i am playing with the plain user:psw auth in url, and it gives
>> >> >> > funny results. at least to me.. (couchdb 1.2.0 in latest
>> >> >> > ubuntu)
>> >> >> >
>> >> >> > i register some user, say name=a/psw=b.
>> >> >> >
>> >> >> > with auth:
>> >> >> > $ curl GET http://a:b@/_users/org.couchdb.user:a
>> >> >> > is fine
>> >> >> >
>> >> >> > without auth:
>> >> >> > $ curl GET http://_users/org.couchdb.user:a
>> >> >> > returns 404 {"error":"not_found","reason":"missing"}
>> >> >> >
>> >> >> > now with auth, but in browsers:
>> >> >> >  - opera http://a:b@/_users/org.couchdb.user:a works
>> >> >> >  - firefox http://a:b@/_users/org.couchdb.user:a warns about
>> >> >> > "server not needing authentication".. and strips the usr/psw
>> >> >> > yielding 404
>> >> >> >  - iexplorer - 404 - strips unconditionaly
>> >> >> >
>> >> >> > is this something that is expected to be so?
>> >> >> > maybe the error can be changed (to 401) ?
>> >> >> >
>> >> >> > i don't know that part about the "server not needing
>> >> >> > authentication" .. maybe something in the headers ? or some
>> >> >> > config of couch_httpd_auth ?
>> >> >> >
>> >> >> > ciao
>> >> >> > svilen

Re: auth in url funnies

[svilen <az...@svilendobrev.com>]

fine. i meant that if i'm about to try guess some couchdb server
users, if wrongusr:wrongpsw@SRV/_session is "revealing" the 401 then
there's no point in hiding wrongusr:wrongpsw@SRV/_users/wrongusr behind
404. it's a weak "protection". 
but anyway.. nevermind.

On Fri, 22 Mar 2013 13:43:49 +0000
Robert Newson <rn...@apache.org> wrote:

> returning 404 for /_session would be saying that /_session doesn't
> exist unless you have credentials. This goes too far, there's nothing
> secret about the existence of the /_session endpoint.
> 
> Compare to GitHub. They return a 404 for any /accountname/projectname
> that doesn't exist at all, and they return 404 for any
> /accountname/projectname that *does* exist but is private. From the
> point of view of someone without authorization to see that project
> it's effectively not there. Returning 404 in the first case and 401 in
> the second case would reveal information that should not be revealed.
> 
> In the users db case, the resource at
> /_users/name_of_someone_that_isn't_me is 404 unless you are allowed to
> see it, for the same reason.
> 
> B.
> 
> On 22 March 2013 13:36, svilen <az...@svilendobrev.com> wrote:
> > hmm
> > shouldnt then /_session behave same?
> > it returns 401
> >
> > On Fri, 22 Mar 2013 13:24:28 +0000
> > Robert Newson <rn...@apache.org> wrote:
> >
> >> Sure, and it's deliberately not helpful;
> >>
> >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5
> >>
> >> "This status code is commonly used when the server does not wish to
> >> reveal exactly why the request has been refused..."
> >>
> >> Returning 401 vs 404 would reveal which user names exist.
> >>
> >> B.
> >>
> >> On 22 March 2013 13:20, svilen <az...@svilendobrev.com> wrote:
> >> > that's fine. just the error isn't very helpful..
> >> > and the browsers don't play nice.
> >> > anyway
> >> >
> >> >> That's by design. In 1.2.0 you can only see your own user
> >> >> document.
> >> >>
> >> >> B.
> >> >>
> >> >> On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
> >> >> > g'day
> >> >> > i am playing with the plain user:psw auth in url, and it gives
> >> >> > funny results. at least to me.. (couchdb 1.2.0 in latest
> >> >> > ubuntu)
> >> >> >
> >> >> > i register some user, say name=a/psw=b.
> >> >> >
> >> >> > with auth:
> >> >> > $ curl GET http://a:b@/_users/org.couchdb.user:a
> >> >> > is fine
> >> >> >
> >> >> > without auth:
> >> >> > $ curl GET http://_users/org.couchdb.user:a
> >> >> > returns 404 {"error":"not_found","reason":"missing"}
> >> >> >
> >> >> > now with auth, but in browsers:
> >> >> >  - opera http://a:b@/_users/org.couchdb.user:a works
> >> >> >  - firefox http://a:b@/_users/org.couchdb.user:a warns about
> >> >> > "server not needing authentication".. and strips the usr/psw
> >> >> > yielding 404
> >> >> >  - iexplorer - 404 - strips unconditionaly
> >> >> >
> >> >> > is this something that is expected to be so?
> >> >> > maybe the error can be changed (to 401) ?
> >> >> >
> >> >> > i don't know that part about the "server not needing
> >> >> > authentication" .. maybe something in the headers ? or some
> >> >> > config of couch_httpd_auth ?
> >> >> >
> >> >> > ciao
> >> >> > svilen

Re: auth in url funnies

[Robert Newson <rn...@apache.org>]

returning 404 for /_session would be saying that /_session doesn't
exist unless you have credentials. This goes too far, there's nothing
secret about the existence of the /_session endpoint.

Compare to GitHub. They return a 404 for any /accountname/projectname
that doesn't exist at all, and they return 404 for any
/accountname/projectname that *does* exist but is private. From the
point of view of someone without authorization to see that project
it's effectively not there. Returning 404 in the first case and 401 in
the second case would reveal information that should not be revealed.

In the users db case, the resource at
/_users/name_of_someone_that_isn't_me is 404 unless you are allowed to
see it, for the same reason.

B.

On 22 March 2013 13:36, svilen <az...@svilendobrev.com> wrote:
> hmm
> shouldnt then /_session behave same?
> it returns 401
>
> On Fri, 22 Mar 2013 13:24:28 +0000
> Robert Newson <rn...@apache.org> wrote:
>
>> Sure, and it's deliberately not helpful;
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5
>>
>> "This status code is commonly used when the server does not wish to
>> reveal exactly why the request has been refused..."
>>
>> Returning 401 vs 404 would reveal which user names exist.
>>
>> B.
>>
>> On 22 March 2013 13:20, svilen <az...@svilendobrev.com> wrote:
>> > that's fine. just the error isn't very helpful..
>> > and the browsers don't play nice.
>> > anyway
>> >
>> >> That's by design. In 1.2.0 you can only see your own user document.
>> >>
>> >> B.
>> >>
>> >> On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
>> >> > g'day
>> >> > i am playing with the plain user:psw auth in url, and it gives
>> >> > funny results. at least to me.. (couchdb 1.2.0 in latest ubuntu)
>> >> >
>> >> > i register some user, say name=a/psw=b.
>> >> >
>> >> > with auth:
>> >> > $ curl GET http://a:b@/_users/org.couchdb.user:a
>> >> > is fine
>> >> >
>> >> > without auth:
>> >> > $ curl GET http://_users/org.couchdb.user:a
>> >> > returns 404 {"error":"not_found","reason":"missing"}
>> >> >
>> >> > now with auth, but in browsers:
>> >> >  - opera http://a:b@/_users/org.couchdb.user:a works
>> >> >  - firefox http://a:b@/_users/org.couchdb.user:a warns about
>> >> > "server not needing authentication".. and strips the usr/psw
>> >> > yielding 404
>> >> >  - iexplorer - 404 - strips unconditionaly
>> >> >
>> >> > is this something that is expected to be so?
>> >> > maybe the error can be changed (to 401) ?
>> >> >
>> >> > i don't know that part about the "server not needing
>> >> > authentication" .. maybe something in the headers ? or some
>> >> > config of couch_httpd_auth ?
>> >> >
>> >> > ciao
>> >> > svilen

Re: auth in url funnies

[svilen <az...@svilendobrev.com>]

hmm
shouldnt then /_session behave same?
it returns 401 

On Fri, 22 Mar 2013 13:24:28 +0000
Robert Newson <rn...@apache.org> wrote:

> Sure, and it's deliberately not helpful;
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5
> 
> "This status code is commonly used when the server does not wish to
> reveal exactly why the request has been refused..."
> 
> Returning 401 vs 404 would reveal which user names exist.
> 
> B.
> 
> On 22 March 2013 13:20, svilen <az...@svilendobrev.com> wrote:
> > that's fine. just the error isn't very helpful..
> > and the browsers don't play nice.
> > anyway
> >
> >> That's by design. In 1.2.0 you can only see your own user document.
> >>
> >> B.
> >>
> >> On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
> >> > g'day
> >> > i am playing with the plain user:psw auth in url, and it gives
> >> > funny results. at least to me.. (couchdb 1.2.0 in latest ubuntu)
> >> >
> >> > i register some user, say name=a/psw=b.
> >> >
> >> > with auth:
> >> > $ curl GET http://a:b@/_users/org.couchdb.user:a
> >> > is fine
> >> >
> >> > without auth:
> >> > $ curl GET http://_users/org.couchdb.user:a
> >> > returns 404 {"error":"not_found","reason":"missing"}
> >> >
> >> > now with auth, but in browsers:
> >> >  - opera http://a:b@/_users/org.couchdb.user:a works
> >> >  - firefox http://a:b@/_users/org.couchdb.user:a warns about
> >> > "server not needing authentication".. and strips the usr/psw
> >> > yielding 404
> >> >  - iexplorer - 404 - strips unconditionaly
> >> >
> >> > is this something that is expected to be so?
> >> > maybe the error can be changed (to 401) ?
> >> >
> >> > i don't know that part about the "server not needing
> >> > authentication" .. maybe something in the headers ? or some
> >> > config of couch_httpd_auth ?
> >> >
> >> > ciao
> >> > svilen

Re: auth in url funnies

[Robert Newson <rn...@apache.org>]

Sure, and it's deliberately not helpful;

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5

"This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused..."

Returning 401 vs 404 would reveal which user names exist.

B.

On 22 March 2013 13:20, svilen <az...@svilendobrev.com> wrote:
> that's fine. just the error isn't very helpful..
> and the browsers don't play nice.
> anyway
>
>> That's by design. In 1.2.0 you can only see your own user document.
>>
>> B.
>>
>> On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
>> > g'day
>> > i am playing with the plain user:psw auth in url, and it gives funny
>> > results. at least to me.. (couchdb 1.2.0 in latest ubuntu)
>> >
>> > i register some user, say name=a/psw=b.
>> >
>> > with auth:
>> > $ curl GET http://a:b@/_users/org.couchdb.user:a
>> > is fine
>> >
>> > without auth:
>> > $ curl GET http://_users/org.couchdb.user:a
>> > returns 404 {"error":"not_found","reason":"missing"}
>> >
>> > now with auth, but in browsers:
>> >  - opera http://a:b@/_users/org.couchdb.user:a works
>> >  - firefox http://a:b@/_users/org.couchdb.user:a warns about
>> > "server not needing authentication".. and strips the usr/psw
>> > yielding 404
>> >  - iexplorer - 404 - strips unconditionaly
>> >
>> > is this something that is expected to be so?
>> > maybe the error can be changed (to 401) ?
>> >
>> > i don't know that part about the "server not needing
>> > authentication" .. maybe something in the headers ? or some config
>> > of couch_httpd_auth ?
>> >
>> > ciao
>> > svilen

Re: auth in url funnies

[svilen <az...@svilendobrev.com>]

that's fine. just the error isn't very helpful..
and the browsers don't play nice.
anyway

> That's by design. In 1.2.0 you can only see your own user document.
> 
> B.
> 
> On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
> > g'day
> > i am playing with the plain user:psw auth in url, and it gives funny
> > results. at least to me.. (couchdb 1.2.0 in latest ubuntu)
> >
> > i register some user, say name=a/psw=b.
> >
> > with auth:
> > $ curl GET http://a:b@/_users/org.couchdb.user:a
> > is fine
> >
> > without auth:
> > $ curl GET http://_users/org.couchdb.user:a
> > returns 404 {"error":"not_found","reason":"missing"}
> >
> > now with auth, but in browsers:
> >  - opera http://a:b@/_users/org.couchdb.user:a works
> >  - firefox http://a:b@/_users/org.couchdb.user:a warns about
> > "server not needing authentication".. and strips the usr/psw
> > yielding 404
> >  - iexplorer - 404 - strips unconditionaly
> >
> > is this something that is expected to be so?
> > maybe the error can be changed (to 401) ?
> >
> > i don't know that part about the "server not needing
> > authentication" .. maybe something in the headers ? or some config
> > of couch_httpd_auth ?
> >
> > ciao
> > svilen

Re: auth in url funnies

[Robert Newson <rn...@apache.org>]

That's by design. In 1.2.0 you can only see your own user document.

B.

On 22 March 2013 13:03, svilen <az...@svilendobrev.com> wrote:
> g'day
> i am playing with the plain user:psw auth in url, and it gives funny
> results. at least to me.. (couchdb 1.2.0 in latest ubuntu)
>
> i register some user, say name=a/psw=b.
>
> with auth:
> $ curl GET http://a:b@/_users/org.couchdb.user:a
> is fine
>
> without auth:
> $ curl GET http://_users/org.couchdb.user:a
> returns 404 {"error":"not_found","reason":"missing"}
>
> now with auth, but in browsers:
>  - opera http://a:b@/_users/org.couchdb.user:a works
>  - firefox http://a:b@/_users/org.couchdb.user:a warns about "server not
>  needing authentication".. and strips the usr/psw yielding 404
>  - iexplorer - 404 - strips unconditionaly
>
> is this something that is expected to be so?
> maybe the error can be changed (to 401) ?
>
> i don't know that part about the "server not needing authentication" ..
> maybe something in the headers ? or some config of couch_httpd_auth ?
>
> ciao
> svilen