Yes. There are two variables:
request.env.remote_addr: the ip of the client as communicated by the web
server
request.env.http_x_forward_from: which may be injected by a proxy (for
example apache+mod_proxy).
request.cllient is set to the former or the latter (if present).
None of them is reliably the true client IP because the former is invalid
if there is a proxy. The latter is can be spoofed. Web2py uses request
client to determine the name of the session id.
It is possible that your testing included spoofing of http_x_forward_from.
Yet something is wrong. The request.client is validated by recent web2py.
Which version are you using?
On Thursday, 6 December 2012 13:15:34 UTC-6, Chris wrote:
>
> 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
>
--
