Looking at one of my test servers, I've seen some odd names for
web2py-generated error files in the app's .../errors directory.
The typical error file name looks like:
127.0.0.1.2012-12-06.05-16-30.10bd4bdb-ea6d-4c43-a062-0bec4abb43b2
where the 3 segments are (requester's IP address).(request date and
time).(random UUID)
We run a lot of tests on these machines, including automated app security
scans incide the firewall, so we end up with thousands of errors.
A small number of the errors have unexpected content in the requester's IP
address field:
quot.2012-11-30.03-29-23.ad8deb4b-1676-45e9-8bef-f9bf911bd1b2
c0.2012-11-30.03-27-04.ca49284e-ff30-4135-9875-b01718033153
27.2012-11-30.03-25-45.a628267b-ea70-4e6a-8b3b-ec1d5ea925ea
2527.2012-11-30.03-27-47.5d41ba8c-4793-4b09-a9eb-b65c60c3a02f
In place of the usual IP address, the requester part of the error file name
is now quot, c0, 27 or 2527
Looking at gluon / globals / Request / compute_uuid:
def compute_uuid(self):
self.uuid = '%s/%s.%s.%s' % (
self.application,
self.client.replace(':', '_'),
self.now.strftime('%Y-%m-%d.%H-%M-%S'),
web2py_uuid())
return self.uuid
It would appear this has to be the result of application or client having
some unexpected content. We also have application logs that record a
certain amount of debug info, including current.request.client. These
other logs do provide independent proof that quot, c0, 27 and 2527 were
values of current.request.client at some point.
Can anyone explain what these could be? It concerns me if request.client
is not reliably an IP address. It is used in some security-related
functions in web2py, e.g. the is_localhost calculation that determines
access to admin app and other restricted content for those of us who use it
that way. If there's a way for request.client to not be an IP address,
maybe someone could manipulate its value into something that would spoof
localhost, or cause a directory traversal when the file is written to disk,
or ??
Mysterious
--
