Discussion:
Nav Django exposing Username/Password in error case
Mischa Diehm
2014-03-25 17:50:05 UTC
Permalink
Hi,

I was playing around with ldap/AD integration and got this errorreport
mailed to our NOC-Group (see below)

- this mail leaks my username/password in cleartext. I think this should
really be avoided for any case happening! I don't have a clue about django
but a quick search showed me this:

https://docs.djangoproject.com/en/dev/howto/error-reporting/

Especially interesting might be this part:

...
Filtering sensitive information
<https://docs.djangoproject.com/en/dev/howto/error-reporting/#filtering-sens
itive-information>
Error reports are really helpful for debugging errors, so it is generally
useful to record as much relevant information about those errors as
possible. For example, by default Django records the full traceback
<http://en.wikipedia.org/wiki/Stack_trace> for the exception raised, each
traceback frame <http://en.wikipedia.org/wiki/Stack_frame> ¹s local
variables, and the HttpRequest
<https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.Htt
pRequest> ¹s attributes
<https://docs.djangoproject.com/en/dev/ref/request-response/#httprequest-att
ributes> .

However, sometimes certain types of information may be too sensitive and
thus may not be appropriate to be kept track of, for example a user¹s
password or credit card number. So Django offers a set of function
decorators to help you control which information should be filtered out of
error reports in a production environment (that is, where DEBUG
<https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-DEBUG> is
set to False): sensitive_variables()
<https://docs.djangoproject.com/en/dev/howto/error-reporting/#django.views.d
ecorators.debug.sensitive_variables> and sensitive_post_parameters()
<https://docs.djangoproject.com/en/dev/howto/error-reporting/#django.views.d
ecorators.debug.sensitive_post_parameters> .

...


I wonder if than can be integrated for NAV or if there is another way to get
around exposure like that?

Mischa

Original mail we became for django error:
----


Traceback (most recent call last):

File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line
111, in get_response
response = callback(request, *callback_args, **callback_kwargs)

File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 89, in
login
return do_login(request)

File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 122,
in do_login
account = auth.authenticate(username, password)

File "/usr/lib/pymodules/python2.7/nav/web/auth.py", line 95, in
authenticate
auth = ldapauth.authenticate(username, password)

File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 120, in
authenticate
lconn = open_ldap()

File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 76, in
open_ldap
server = _config.get('ldap', 'server')

File "/usr/lib/python2.7/ConfigParser.py", line 618, in get
raise NoOptionError(option, section)

NoOptionError: No option 'server' in section: 'ldap'


<WSGIRequest
path:/index/login/,
GET:<QueryDict: {}>,
POST:<QueryDict: {u'origin': [u''], u'username': [u'diehm-adm'],
u'password': [u'godDamnitDjango']}>,
COOKIES:{'sessionid': 'd660941ae6b821799dbb47ed41d47009'},
META:{'CONTENT_LENGTH': '52',
'CONTENT_TYPE': 'application/x-www-form-urlencoded',
'DOCUMENT_ROOT': '/usr/share/nav/htdocs',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTPS': '1',
'HTTP_ACCEPT':
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
'HTTP_ACCEPT_LANGUAGE': 'de,en-us;q=0.7,en;q=0.3',
'HTTP_CONNECTION': 'keep-alive',
'HTTP_COOKIE': 'sessionid=d660941ae6b821799dbb47ed41d47009',
'HTTP_DNT': '1',
'HTTP_HOST': 'urz-nav-pet.urz.unibas.ch',
'HTTP_REFERER': 'https://urz-nav-pet.urz.unibas.ch/index/login/',
'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0)
Gecko/20100101 Firefox/28.0',
'PATH_INFO': u'/index/login/',
'PATH_TRANSLATED': '/usr/share/pyshared/nav/wsgi.py/index/login/',
'QUERY_STRING': '',
'REMOTE_ADDR': '131.152.2.16',
'REMOTE_PORT': '59503',
'REQUEST_METHOD': 'POST',
'REQUEST_URI': '/index/login/',
'SCRIPT_FILENAME': '/usr/share/pyshared/nav/wsgi.py',
'SCRIPT_NAME': u'',
'SERVER_ADDR': '131.152.2.216',
'SERVER_ADMIN': '***@localhost',
'SERVER_NAME': 'urz-nav-pet.urz.unibas.ch',
'SERVER_PORT': '443',
'SERVER_PROTOCOL': 'HTTP/1.1',
'SERVER_SIGNATURE': '<address>Apache/2.2.22 (Debian) Server at
urz-nav-pet.urz.unibas.ch Port 443</address>\n',
'SERVER_SOFTWARE': 'Apache/2.2.22 (Debian)',
'SSL_TLS_SNI': 'urz-nav-pet.urz.unibas.ch',
'mod_wsgi.application_group': 'urz-nav-pet.urz.unibas.ch|',
'mod_wsgi.callable_object': 'application',
'mod_wsgi.handler_script': '',
'mod_wsgi.input_chunked': '0',
'mod_wsgi.listener_host': '',
'mod_wsgi.listener_port': '443',
'mod_wsgi.process_group': 'NAV',
'mod_wsgi.request_handler': 'wsgi-script',
'mod_wsgi.script_reloading': '1',
'mod_wsgi.version': (3, 3),
'wsgi.errors': <mod_wsgi.Log object at 0x7fa322859430>,
'wsgi.file_wrapper': <built-in method file_wrapper of mod_wsgi.Adapter
object at 0x7fa3228655d0>,
'wsgi.input': <mod_wsgi.Input object at 0x7fa3210d6eb0>,
'wsgi.multiprocess': True,
'wsgi.multithread': True,
'wsgi.run_once': False,
'wsgi.url_scheme': 'https',
'wsgi.version': (1, 1)}>
--
Mischa Diehm | Network Operations Center (NOC)
UniBasel | UniRechenZentrum (URZ)
Klingebergstr. 70 | CH-4056 Basel
Tel. +41 61 267 1574 | http://urz.unibas.ch
Morten Brekkevold
2014-03-26 10:05:16 UTC
Permalink
Post by Mischa Diehm
I was playing around with ldap/AD integration and got this errorreport
mailed to our NOC-Group (see below)
- this mail leaks my username/password in cleartext. I think this should
really be avoided for any case happening! I don't have a clue about django
https://docs.djangoproject.com/en/dev/howto/error-reporting/
[snip]
Post by Mischa Diehm
I wonder if than can be integrated for NAV or if there is another way to get
around exposure like that?
Nice catch, I'm sure it can be fixed, and thanks for the report! I would
kindly ask you to file it at [1], so we have a tracking number for it.

Having everything served through Django is a relatively recent
development in NAV, since Django has been shoe-horned into our legacy
code over several years. Before Django, no such reports were mailed when
things crashed, which is likely why the issue of sensitive data leaks
never was considered.


[1] https://bugs.launchpad.net/nav/+filebug
--
Morten Brekkevold
UNINETT
Loading...