[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote,
> Note that dereferencing a URI via GET is in principle and as far as I
> can tell in practice safe, assuming you protect against
> infinitely-large resource representations.
That simply isn't true.
Whether or not it's safe (in the broad sense rather than merely the RFC
2616 sense) depends on many factors,
1. The network client being correctly implemented.
2. The client application being correctly implemented.
3. The network server being correctly implemented.
4. The server application being correctly implemented.
5. The environment being trustworthy.
Where "correctly" means "securely and bug-free", and the contrast
between network client and client application (resp. network server and
server application) corresponds to the distinction between the
infrastructure provided by your platform, eg. java.net.URLConnection
vs. the application which uses it (resp. Apache/Tomcat vs. some
application-specific servlet).
Very non-exhaustive examples of possibly exploitable failures in the
above ...
1. Overlong URIs trip buffer overflows; ports in the URI authority part
point to unsafe network services; cunningly manufactured response
headers trip buffer overflows or other unfortunate behaviour;
protocol level errors which tickle bugs in the network client.
2. Buffer overflows on response entities (as you mentioned); response
entities triggering automated processing with unfortunate
consequences; malformed response entities which tickle bugs in the
client application.
3. Overlong URIs which trip buffer overflows; misconfigured or insecure
server software which causes unpleasant effects when fed cunningly
manufactured URIs.
4. Network services which are offered via GET, but which nevertheless
have unfortunate side-effects; anything mentioned under (3) but at
the application rather than the infrastructure level.
5. Poisoned DNS data, or compromised or misconfigured routers or proxies
which redirect your GET somewhere other than the intended
destination; DNS resolution for the authority part of the URI tickles
bugs in your platforms resolver (or the remote nameserver).
If you can guarantee that all of 1-5 hold, then maybe GET is safe. But
it's highly unlikely that you can make those guarantees unless you
control the source of the URIs, the URI receiving application at all
levels of the stack, and the target server at all levels of the stack.
Even if your own application is safe, accepting and dereferencing
arbitrary URIs from arbitrary sources means that you are in effect
offering your services as a reflector. That might be safe in the RFC
2616 sense, but it's more than a little irresponsible.
Cheers,
Miles
|
