[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Excellent IETF BCP on XML
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|