Quantcast

Using xmlrpc interface requires that HTTP_AUTH be enabled?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using xmlrpc interface requires that HTTP_AUTH be enabled?

John P. Rouillard
Hi all:

It looks like the way to use a stand alone (outside the web browser)
xmlrpc client, is to use basic auth.

However, if you have HTTP_AUTH disabled in config.ini, that also
disables basic auth, so how would you generate a non-anonymous xmlrpc
call?

This test does work if I enable HTTP_AUTH:

===============
import xmlrpclib
class SpecialTransport(xmlrpclib.SafeTransport):

    def send_content(self, connection, request_body):

        connection.putheader("Referer", "https://localhost:8917/demo/")
        connection.putheader("Origin", "https://localhost")
        connection.putheader("X-Requested-With", "xmlrpc")

        connection.putheader("Content-Type", "text/xml")
        connection.putheader("Content-Length", str(len(request_body)))
        connection.endheaders()
        if request_body:
            connection.send(request_body)

roundup_server = xmlrpclib.ServerProxy('https://admin:admin@localhost:8917/demo/xmlrpc', transport=SpecialTransport(), verbose=False, allow_none=True)

print roundup_server.display('user2', 'username')
print roundup_server.display('issue1', 'status')
print roundup_server.filter('user',['1','2','3'],{'username':'demo'})
=================

returns:

{'username': 'anonymous'}
{'status': '2'}
['3']

Note that I have to override send_content to send the headers required
to pass the csrf tests. However I am stumped on how to do this if you
disable HTTP_AUTH.

Also I discovered an issues in my anti-csrf code.  If you enable
HTTP_AUTH and have a basic auth header, the code throws an error in
trying to seed the random number generator. I'll check in the simple
fix for this.

Does anybody use the xmlrpc interface in roundup from a stand alone
client?

If anybody uses the xmlrpc interface from the web browser, are the
referer, origin or other headers (auth) passed? Is the session cookie
in the browser used to auth the xmlrpc call?

Thanks and have a great week.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using xmlrpc interface requires that HTTP_AUTH be enabled?

Ralf Schlatterbeck-3
On Sun, Mar 26, 2017 at 10:56:20PM -0400, John P. Rouillard wrote:
>
> It looks like the way to use a stand alone (outside the web browser)
> xmlrpc client, is to use basic auth.
>
> However, if you have HTTP_AUTH disabled in config.ini, that also
> disables basic auth, so how would you generate a non-anonymous xmlrpc
> call?

I'm using xmlrpc only with basic auth.

> Does anybody use the xmlrpc interface in roundup from a stand alone
> client?

Yes, I'm using it regularly.

Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [hidden email]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using xmlrpc interface requires that HTTP_AUTH be enabled?

John P. Rouillard
Hi Ralf:

In message <[hidden email]>,
Ralf Schlatterbeck writes:
>On Sun, Mar 26, 2017 at 10:56:20PM -0400, John P. Rouillard wrote:
>> It looks like the way to use a stand alone (outside the
>> web browser) xmlrpc client, is to use basic auth.
>>
>> However, if you have HTTP_AUTH disabled in config.ini,
>> that also disables basic auth, so how would you generate
>> a non-anonymous xmlrpc call?
>
>I'm using xmlrpc only with basic auth.

Ok, so you have http_auth enabled in roundup's
config.ini. Are you using your web server to handle the auth
and pass back the REMOTE_USER header, or does roundup handle
the basic auth header?

>> Does anybody use the xmlrpc interface in roundup from a
>> stand alone client?
>
>Yes, I'm using it regularly.

It looks like a standard client (like the python based one
in doc/xmlrpc.txt) will send only the HOST header. So you
can't require any csrf header except the host header. You
will probably have to also set:

   other csrf_enforce_header_* to yes and not required

   csrf_enforce_header_x-requested-with to no

   csrf_header_min_count = 1

and use CSRF tokens for defense in the web interface. CSRF
tokens are not used for defending the xmlrpc interface.

If you use the python client I gave in my original email,
then you can set:

  csrf_enforce_header_x-requested-with = yes

and if you set the referer header you can enable some other
headers and require a larger minimum number of headers.

I also updated the xmlrpc.txt file with the basic and
advanced python clients. Also there are now tests for the
code and I restructured the tests to work correctly.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using xmlrpc interface requires that HTTP_AUTH be enabled?

Ralf Schlatterbeck-3
On Mon, Mar 27, 2017 at 11:14:03PM -0400, John P. Rouillard wrote:
> Ok, so you have http_auth enabled in roundup's
> config.ini. Are you using your web server to handle the auth
> and pass back the REMOTE_USER header, or does roundup handle
> the basic auth header?

Lately I'm using an apache webserver as the frontend.
But I was using roundups builtin server in the past, too.

> It looks like a standard client (like the python based one
> in doc/xmlrpc.txt) will send only the HOST header. So you
> can't require any csrf header except the host header. You
> will probably have to also set:
>
>    other csrf_enforce_header_* to yes and not required
>
>    csrf_enforce_header_x-requested-with to no
>
>    csrf_header_min_count = 1

How effective is CSRF protection in xmlrpc? My understanding was that
each request is separate (with auth info in the request) and there is no
login with a browser, so no CSRF is possible?

Or am I missing something here?

> and use CSRF tokens for defense in the web interface. CSRF
> tokens are not used for defending the xmlrpc interface.

OK, I will have to study this in detail before I do the next upgrade...

Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [hidden email]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using xmlrpc interface requires that HTTP_AUTH be enabled?

John P. Rouillard
Hi Ralf:

In message <[hidden email]>,
Ralf Schlatterbeck writes:

>On Mon, Mar 27, 2017 at 11:14:03PM -0400, John P. Rouillard wrote:
>> Ok, so you have http_auth enabled in roundup's
>> config.ini. Are you using your web server to handle the auth
>> and pass back the REMOTE_USER header, or does roundup handle
>> the basic auth header?
>
>Lately I'm using an apache webserver as the frontend.
>But I was using roundups builtin server in the past, too.
>
>> It looks like a standard client (like the python based one
>> in doc/xmlrpc.txt) will send only the HOST header. So you
>> can't require any csrf header except the host header. You
>> will probably have to also set:
>>
>>    other csrf_enforce_header_* to yes and not required
>>
>>    csrf_enforce_header_x-requested-with to no
>>
>>    csrf_header_min_count = 1
>
>How effective is CSRF protection in xmlrpc? My
>understanding was that each request is separate (with auth
>info in the request) and there is no login with a browser,
>so no CSRF is possible?

Well javascript can run XMLHttpRequest and IIUC the http
request will have alll the credentials/cookies etc. that are
stored in the browser.

*Caution* I think the following is right from what I have
read.  If anybody knows better please speak up.

One thing a malicious piece of javascript can't do is inject
headers in a request sent to somebody else's site. If the
xmlhttprequest is run from javascript gotten from bad.com,
it can submit a request to good.com but it can't set any
HTTP headers in the request. The browser will send the
referer (bad.com) and any authentication creds/cookies it
has for good.com in the http xml request.

However an xmlhttprequest comming from javascript code
obtained from good.com can also add a X-Requested-With
header to the good.com request. It can do so because it is
from the same origin that the xmlhttprequest is going to.

Hence the presence of that header "signs" the source of the
javascript as having originated from the target domain
(good.com).

Note that browser bugs that fail to enforce same origin
addition of cookies (or flash bugs...) invalidate using the
header for "authentication/authorization" purposes.

Also we validate the incoming request as text/xml and do not
accept text/plain.  This should prevent non-javascript based
xml attacks.

>Or am I missing something here?

If you are doing a standalone xml request via a client
library I don't think you are missing anything.

>> and use CSRF tokens for defense in the web interface. CSRF
>> tokens are not used for defending the xmlrpc interface.
>
>OK, I will have to study this in detail before I do the next upgrade...

A safe setting should be yes for everything except

   csrf_enforce_header_x-requested-with

which is set to no and setting:

   csrf_header_min_count = 0

if you are not setting any headers in your xmlrpc over http
request.

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Loading...