-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2 Oct 2010, at 09:19, Christoph Haas wrote:
I'm running a 0.9.7 application (screenshots.debian.net) and this
morning received a paste error in my mail that got me thinking. The
actual exception was:
CookieError: Illegal key value: ,__utma
And the probable cause is this cookie:
HTTP_COOKIE
',__utma=183447588.206002125.1285996917.1285996917.1285996917.1;
__utmb=183447588.2.10.1285996917; __utmc=183447588;
__utmz=183447588.1285996917.1.1.utmcsr=(direct)|utmccn=(direct)|
utmcmd=(none)'
Are cookies beginning with underscores not valid? Or is this an
artificial limitation here? There is another cookie that I found
strange:
Leading underscores are legal syntax. I think it may be the leading /
comma/ in ',__utma=...' that may be causing the problem.
RFC2109 states:
NAME=VALUE
Required. The name of the state information ("cookie") is NAME,
and its value is VALUE. NAMEs that begin with $ are reserved for
other uses and must not be used by applications.
The VALUE is opaque to the user agent and may be anything the
origin server chooses to send, possibly in a server-selected
printable ASCII encoding. "Opaque" implies that the content is
of
interest and relevance only to the origin server. The content
may, in fact, be readable by anyone that examines the Set-Cookie
header.
and with respect to the token...
The two state management headers, Set-Cookie and Cookie, have common
syntactic properties involving attribute-value pairs. The following
grammar uses the notation, and tokens DIGIT (decimal digits) and
token (informally, a sequence of non-special, non-white space
characters) from the HTTP/1.1 specification [RFC 2068] to describe
their syntax.
av-pairs = av-pair *(";" av-pair)
av-pair = attr ["=" value] ; optional value
attr = token
value = word
word = token | quoted-string
Attributes (names) (attr) are case-insensitive. White space is
permitted between tokens. Note that while the above syntax
description shows value as optional, most attrs require them.
NOTE: The syntax above allows whitespace between the attribute and
the = sign.
so RFC 2068 defines the syntax for the token:
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value.
token = 1*<any CHAR except CTLs or tspecials>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Is this some kind of attacker who wants to annoy the Pylons
application
with overly long cookies to see if it fails?
That doesn't look like valid cookie syntax, it looks more like an HTTP
header.
However, as to whether the content suggests an attack based on
excessive value size, the limits are discussed here (heavily laced
with "should" and "may")...
6.3 Implementation Limits
Practical user agent implementations have limits on the number and
size of cookies that they can store. In general, user agents'
cookie
support should have no fixed limits. They should strive to store as
many frequently-used cookies as possible. Furthermore, general-use
user agents should provide each of the following minimum
capabilities
individually, although not necessarily simultaneously:
* at least 300 cookies
* at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
* at least 20 cookies per unique host or domain name
User agents created for specific purposes or for limited-capacity
devices should provide at least 20 cookies of 4096 bytes, to ensure
that the user can interact with a session-based origin server.
The information in a Set-Cookie response header must be retained in
its entirety. If for some reason there is inadequate space to store
the cookie, it must be discarded, not truncated.
Applications should use as few and as small cookies as possible, and
they should cope gracefully with the loss of a cookie.
6.3.1 Denial of Service Attacks
User agents may choose to set an upper bound on the number of
cookies
to be stored from a given host or domain name or on the size of the
cookie information. Otherwise a malicious server could attempt to
flood a user agent with many cookies, or large cookies, on
successive
responses, which would force out cookies the user agent had received
from other servers. However, the minima specified above should
still
be supported.
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkynh/MACgkQOsmLt1NhivwsLQCgnf9mVhB2YdA2yS7RbS5tyThN
hwYAoNKD7VJpCqbRPXqlxRvi4wrigLDriQCVAgUBTKeH81nrWVZ7aXD1AQLiEAQA
iH6ByDlQAoUu6EkR1PHX2UhtMZcRig5iSKmHm6cFFPf5CgBJAGFPsgi1xVtuKJ1d
YnE95EFrO6qJtcNIXnFM6PFLYlMwo7N9K/FmK1LRW2+bVH/mi//mHl5RWbM+RogY
olAqfVoucSepjN65IIaohFZfWRBl2lz/OkWNMT1LLE0=
=81rc
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
