Request objects should not be publishable

Bug #789863 reported by Alan Hoey on 2011-05-29
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zope 2
High
Tres Seaver

Bug Description

Request objects are currently publishable, there is a check to prevent objects with the id "REQUEST" from being published but this doesn't catch situations like browser views where the request commonly is lowercase (eg @@absolute_url/request). This leaks a significant amount of information including the cookies of the inbound request. This allows trivial circumvention of any HttpOnly cookies where javascript injection is possible (fetch the request object and parse for cookies, steal any session cookie there), hence this issue is marked as a security vulnerability.

Hanno Schlichting (hannosch) wrote :

Hhm, I wonder if we should maybe override the requests __str__ (or whatever is called to publish it) with a version that reports very little information and doesn't leak anything.

The request might commonly be referred to as request or REQUEST, but it could be reachable under any other variable name as well.

I'm not aware of any code that relies on str(request) to work, but this needs investigation.

Changed in zope2:
importance: Undecided → High
status: New → Confirmed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/02/2011 11:16 AM, Hanno Schlichting wrote:
> Hhm, I wonder if we should maybe override the requests __str__ (or
> whatever is called to publish it) with a version that reports very
> little information and doesn't leak anything.
>
> The request might commonly be referred to as request or REQUEST, but it
> could be reachable under any other variable name as well.
>
> I'm not aware of any code that relies on str(request) to work, but this
> needs investigation.

There is lots of debugging code which might use that (e.g., returning
the request from a PythonScript). What we want is to make the request
itself unpublishable, not unserializable.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3ntv0ACgkQ+gerLs4ltQ6X1wCgu3WV7xUwdBmBl04y9fPaYYxW
rdoAoMJjj8lYwSeljJC9oRHOm/pBo9Mf
=EfDA
-----END PGP SIGNATURE-----

LeoRochael (leorochael) wrote :

Here's a patch that deals with this issue, by overriding __doc__ at request instantiation.

Comments on it, and help in landing it in Zope are appreciated.

Richard Mitchell (mitchellrj) wrote :

The above patch renders request unpublishable, but doesn't fix this test case:

http://localhost:8080/Plone/@@myview/request/RESPONSE/setBody?body=evil

Attached is the patch I developed for some forthcoming Plone hotfix.

Tres Seaver (tseaver) wrote :

I am testing a branch now which lands both Leo's patch and the ideas from Richards hotfix. It should be included in 2.12.23, to be released this week.

Tres Seaver (tseaver) on 2015-06-29
information type: Private Security → Public Security
Changed in zope2:
milestone: none → 2.13.23
status: Confirmed → Fix Committed
Tres Seaver (tseaver) on 2015-07-30
Changed in zope2:
status: Fix Committed → Fix Released
assignee: nobody → Tres Seaver (tseaver)
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers