[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Excellent IETF BCP on XML

• To: XML Dev <xml-dev@l...>
• Subject: Re: Excellent IETF BCP on XML
• From: Miles Sabin <miles@m...>
• Date: Sat, 23 Nov 2002 13:36:49 +0000
• In-reply-to: <3DDECA93.4050203@t...>
• References: <15725CF6AFE2F34DB8A5B4770B7334EE0DF8DE@h...> <3DDECA93.4050203@t...>

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

• Follow-Ups:
  • Re: Excellent IETF BCP on XML
    • From: Tim Bray <tbray@t...>

• References:
  • RE: Excellent IETF BCP on XML
    • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Re: Excellent IETF BCP on XML
    • From: Tim Bray <tbray@t...>

• Prev by Date: Web Services -- The City of Jericho?
• Next by Date: Re: Web Services -- The City of Jericho?
• Previous by thread: Re: Excellent IETF BCP on XML
• Next by thread: Re: Excellent IETF BCP on XML
• Index(es):
  • Date
  • Thread