Re: Potential HTTP Security Risk

> For the 'security considerations' portion of the 1.1 draft, with your
> concurrence:

>> >    Implementations of the HTTP servers should be careful to restrict
>> >    the documents returned by HTTP requests to be only those that
>> >    were intended by the administrators. If an HTTP server translates
>> >    HTTP URIs directly into file system calls, the server must take
>> >    special care not to serve files that were not intended to be
>> >    delivered to HTTP clients. For example, Unix, Microsoft Windows,
>> >    and other operating systems use ".." as a path component to
>> >    indicate a directory level above the current one. A URL with such
>> >    constructs can be constructed to potentially allow access to
>> >    files outside the desired directory structure, and should thus be
>> >    disallowed. Similarly, access control files, configuration files,
>> >    script implementations of the HTTP server itself must be
>> >    adequately protected if they might contain sensitive information,
>> >    as long as the HTTP server translates the path of the URL into a
>> >    file system identity and sends it unless otherwise prohibited.
>> >    Experience has shown that minor bugs in such HTTP server
>> >    implementations have turned into security risks.

As an addition, it should go to the mailing list first (also, I think
it applies equally to 1.0).

I would suggest a few changes (in the latter half):

>    Implementations of the HTTP servers should be careful to restrict
>    the documents returned by HTTP requests to be only those that
>    were intended by the administrators. If an HTTP server translates
>    HTTP URIs directly into file system calls, the server must take
>    special care not to serve files that were not intended to be
>    delivered to HTTP clients. For example, Unix, Microsoft Windows,
>    and other operating systems use ".." as a path component to
>    indicate a directory level above the current one.
     On such a system, an HTTP server must disallow any such construct
     in the Request-URI if it would otherwise allow access to a resource
     outside those intended to be accessible via the HTTP server.
     Similarly, files intended for reference only internally to the server
     (such as access control files, configuration files, and script code)
     must be protected from inappropriate retrieval, since they might
     contain sensitive information.
>    Experience has shown that minor bugs in such HTTP server
>    implementations have turned into security risks.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 30 December 1995 00:16:47 UTC