request.path leads to confusion/errors inside templates and may open XSS attacks

[David Danier <goliath.mailinglist@…>]

django.core.context_processors.request puts the request into the context of templates. As request offers dictionary-access to the provides data (combination of GET and POST) request.XXX is not unambiguous. You can override {{ request.path }} by adding '?path=...' to your URL for example. Other attributes (GET, POST, ..., method, get_full_path or is_secure) can be overwritten the same way, of course.

This has many problems attached:

• security: request.path is not escaped everywhere, because it is pre-filtered by url-config request.is_secure might be used to display forms only when using a secure connection (WLAN-setting?)
• errors when using GET, POST, ...: suddenly no dictionary there
• confusion: different behavior

As request.REQUEST exists the dictionary-access to request could be removed, I think. But to keep API stable I attached a patch that wrapps the request inside templates and will only allow access to the attributes.

[David Danier <goliath.mailinglist@…>]

getitem does not work for methods, as the resolver tries not to call values got by dict-access. Fixed this by using getattr instead.

[David Danier <goliath.mailinglist@…>]

Any progress on this issue? It seems like this ticket is accepted but has not been put into SVN for several month now. Are there any problems? Comments missing in the code or anything? If so I will update the patch.

Possible XSS attack probably is gone thanks to autoescaping now. So beeing able to overwrite request.path or request.is_secure inside templates is still possible, but you cannot insert HTML any more.

[Gary Wilson]

(In [8202]) Fixed #8092, #3828 -- Removed dictionary access for request objects so that GET and POST data doesn't "overwrite" request attributes when used in templates (since dictionary lookup is performed before attribute lookup). This is backwards-incompatible if you were using the request object for dictionary access to the combined GET and POST data, but you should use request.REQUEST for that instead.

[Jacob]

Milestone 1.0 beta deleted