couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: auth in url funnies
Date Fri, 22 Mar 2013 14:27:17 GMT
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 <rnewson@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 <rnewson@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

Mime
View raw message