12.5 Attacks Based on File and Path Names
The implementation of the HTTP original server should be aware that the HTTP request for a file is subject to the name of the server administrator. If the HTTP server sends the HTTP URI to the system call, the server should pay special attention to the service when a request file is not sent to the HTTP client. For example, in UNIX, Microsoft Windows, and other operating systems use ".." as the superior directory name. Under such systems, the HTTP server side must disable access to other range of HTTP servers by using the request URI of this structure. Similarly, some files used inside the server include access control files, configuration files, Script code, etc., also subject to special protection to avoid being illegally requested to obtain, resulting in system sensitive information exposure. Experiments have shown that even the smallest bug can also lead to serious security issues.
13. Thank you (ACKNOWLEDGMENTS)
This document focuses on the augmented BNF and the general structure defined in RFC822 [7] by David H. Crocker in RFC822 [7]. Similarly, it uses many definitions made by Nathaniel Borenstein and Ned Freed for MIME [5]. We hope to reduce the relationship between HTTP / 1.0 and MAIL messages.
The HTTP protocol has been developing quickly over the past four years, it has benefited from a huge and active development group - is them, these people involved in the WWW discussion of the mailing list, which creates HTTP's global success. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen, They put a huge energy for the earlier versions of this document. Paul Hoffman provides information about information status, as well as the contents of Appendix C, D.
Berners-Lee, et al information [Page 51]
This document has benefited from the commentary of HTTP-WG members. The following is people who contribute to this specification:
Gary Adams Harald Tveit Alvestrand
Keith Ball Brian Behlendorf
Paul Burchard Maurizio Codogno
Mike Cowlishaw Roman Czyborra
Michael A. Dolan John Franks
Jim GetTys Marc Hedlund
Koen Holtman Alex Hopmann
Bob Jernigan shel kaphan
Martijn Koster Dave Kristol
Daniel Laliberte Paul LEACH
Albert Lunde John C. Mallery
Larry Masinter Mitra
Jeffrey Mogul Gavin Nicol
Bill Perry Jeffrey PERRY
Owen Rees Luigi Rizzo
David Robinson Marc Salomon
Rich Salz Jim Seidman
Chuck Shotton Eric W. Sink
Simon E. Spero Robert S. THAU
Francois Yergeau Mary Ellen Zurko
Jean-Philippe Martin-Flatin
14. Reference book (References)
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., And B. Alberti, "The Internet Gopher Protocol: a
Distributed Document Search and Retrieval Protocol, RFC 1436,
University of Minnesota, March 1993.
[2] Berners-Lee, T., "Universal Resource Identifiers in www: a
Unifying syntax for the expression of names and addresses of name
Objects on the network as buy in the world-wide web,
RFC 1630, CERN, JUNE 1994.
[3] Berners-Lee, T., And D. Connolly, "Hypertext Markup Language -
2.0 ", RFC 1866, MIT / W3C, NoveMber 1995.
[4] Berners-Lee, T., Masinter, L., And M. McCahill, "Uniform
Resource Locators (URL) ", RFC 1738, Cern, Xerox Parc,
University of Minnesota, December 1994.
Berners-Lee, et al information [Page 52]
[5] Borenstein, N., And N. FREED, "MULTIPURPOSE INTERNET MAIEXTENSIONS] Part ONE: MECHANISMS for Specifying and Describing
The Format of Internet Message Bodies, RFC 1521, Bellcore,
Innosoft, September 1993.
[6] BRADEN, R., "Requirements for Internet Hosts - Application and
Support ", STD 3, RFC 1123, IETF, October 1989.
[7] CROCKER, D., "Standard for the format of arpa internet text
Messages, STD 11, RFC 822, UDEL, AUGUST 1982.
[8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
J. SUI, And M. Grinbaum. "WAIS Interface Protocol Prototype
Functional Specification. "(V1.5), Thinking Machines
Corporation, April 1990.
[9] FIELDING, R., "Relative Uniform Resource Locators", RFC 1808,
UC IRVINE, June 1995.
[10] Horton, M., And R. Adams, "Standard for Interchange of UseNet
Messages, RFC 1036 (Obsoletes RFC 850), AT & T Bell
Laboratories, Center for Seismic Studies, DecEmber 1987.
[11] Kantor, B., And P. Lapsley, "NetWork News Transfer Protocol:
A proposed Standard for the stream-based transmission of news,
RFC 977, UC San Diego, UC Berkeley, February 1986.
[12] Postel, J., SIMPLE Mail Transfer Protocol. "STD 10, RFC 821,
USC / ISI, AUGUST 1982.
[13] Postel, J., "Media Type Registration Procedure." RFC 1590,
USC / ISI, MARCH 1994.
[14] Postel, J., And J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC / ISI, OCTOBER 1985.
[15] Reynolds, J., And J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC / ISI, October 1994.
[16] Sollins, K., And L. Masinter, "Functional Requirements for
Uniform Resource Names, RFC 1737, MIT / LCS, Xerox Corporation,
DECEMBER 1994.
[17] US-ASCII. Coded Character Set - 7-Bit American Standard CodeFor Information Interchange. Standard Ansi X3.4-1986, ANSI,
1986.
Berners-Lee, et al information [Page 53]
[18] ISO-8859. INTERNATIONAL STANDARD - INFORMATION Processing -
8-Bit Single-byte Coded Graphic Character Sets -
Part 1: Latin Alphabet No. 1, ISO 8859-1: 1987.
Part 2: Latin Alphabet No. 2, ISO 8859-2, 1987.
Part 3: Latin Alphabet No. 3, ISO 8859-3, 1988.
Part 4: Latin Alphabet No. 4, ISO 8859-4, 1988.
Part 5: Latin / Cyrillic Alphabet, ISO 8859-5, 1988.
Part 6: Latin / Arabic Alphabet, ISO 8859-6, 1987.
Part 7: Latin / Greek Alphabet, ISO 8859-7, 1987.
Part 8: Latin / Hebrew Alphabet, ISO 8859-8, 1988.
Part 9: Latin Alphabet No. 5, ISO 8859-9, 1990.
15. Author's address (Authors' Addresses)
Tim Berners-Lee
Director, W3 consortium
Mit Laboratory for Computer Science
545 TECHNOLOGY SQUARE
Cambridge, MA 02139, u.s.a.
Fax: 1 (617) 258 8682
Email: Timbl@w3.org
Roy T. Fielding
Department of Information and Computer Science, Trience, DEPARTMENT OF INFORMATION
University of California
Irvine, CA 92717-3425, U.S.A.
Fax: 1 (714) 824-4056
Email: FIELDING@ics.uci.edu
Henrik Frystyk Nielsen
W3 consortium
Mit Laboratory for Computer Science
545 TECHNOLOGY SQUARE
Cambridge, MA 02139, u.s.a.
Fax: 1 (617) 258 8682
Email: Frystyk@w3.org
Berners-Lee, et al information [Page 54]
Appendices
This information appears in the appendix only one reason, that is, they have not become an integral part of the HTTP / 1.0 specification.
A. Internet Media Type Message / HTTP (Internet Media Type Message / HTTP)
As a supplement to the HTTP / 1.0 protocol, this document is a specification for Internet Media Types "Message / HTTP". The following is registered in IANA [13].
Media Type name: Message: MEDIA TYPE NAME: MESSAGE
Media Subtype Name: HTTP Request Parameters: NONE
Optional parameters: Version, MSGTYPE
Version: The HTTP version number of additional messages, such as "1.0". If not given, the version can be obtained from the first row of its main body.
Message Type (MSGTYPE): Message Type - Request or Respond. If not given, the version can be obtained from the first row of its main body.
Encoding Considances: Only "7bit", "8bit", or "binary" is allowed.
Safety considerations: NONE
B. Wayerrant Applications
Although this document indicates the necessary conditions for generating HTTP / 1.0 messages, not all applications are corrected their implementation. Therefore, we recommend that the application enhances its fault tolerance, so that it can also ensure normal operation when it is still clearly explained.
When the client parsing status row (Status-line) and server resolution request, it should be fault tolerant. In particular, even if only one SP is required, they can also accept the domain separated by any number of SP or HT characters.
The row termination of the HTTP header domain is the sequence character CRLF. And we recommend that the application is resolving such titles, it should also be identified as a terminator condition for a single LF (without the previous CR).
Berners-Lee, et al information [Page 55]
C. Relationship with MIME (RELATIONSHIP to MIME)
HTTP / 1.0 uses many structures defined for Internet Mail (RFC822 [7]) and multi-purpose Internet mail extensions MIME [5] to allow entities to be transmitted through an open scalable mechanism. In fact, some characteristics in HTTP are different from the emails discussed in RFC1521, which are used to optimize the performance of binary transmission, providing greater freedom to media types, making the date more easier, of course, this It is also for compatibility with some of the early HTTP servers and client applications.
When writing this article, it is said that RFC1521 will be revised. The amendment will include some existing applications that appear in HTTP / 1.0, but these applications are not included in the current RFC1521.
The appendix describes the differences in HTTP and RFC 1521. When restricting the MIME environment, proxy and gateways should notice these differences and provide corresponding conversion support when necessary. The agent and gateway from the MIME to HTTP environment should also pay attention to these differences because some conversions may be necessary.
C.1 Conversion to specification form (Conversion to Canonical Form)
RFC1521 requires an Internet mail entity to convert to a specification form before transmitting, as described in RFC1521 [5] Appendix C. The specific form of the subclass of the "Text" media type allowed when the HTTP is described in Section 3.6.1 in this document describes. RFC1521 requires "text" content type (content-type) must use CRLF as a row break, and Cr or LF is prohibited separately. HTTP allows the use of CRLF when HTTP transmission, separate CR or LF as a line break.
As long as it is possible, the agent or gateway in the HTTP environment or the RFC1521 environment should be converted to CRLF all rows in the text media type described in section 3.6.1 of this document. Note that due to the content encoding (Content-encoding), and HTTP allows the use of multi-character sets, some of these characters are not used as CR and LF, which makes actual processing more complicated.
Berners-Lee, et al information [Page 56]
C.2 Date Format Conversion (Conversion of Date Formats)
HTTP / 1.0 uses the restricted date format set (Section 3.3) to simplify the process of date comparison. The proxy and gateway of other protocols should ensure that any date the title field in the message is consistent with the HTTP / 1.0 format, otherwise it is to be rewritten.
C.3 Content Coding Introduction Of Content-Encoding
RFC1521 does not include concepts such as the content encoding the title field in HTTP / 1.0. Since the content type domain is a modification of the media type, the agent and gateway from the HTTP to MIME compatibility protocol must change the value of the content type title field or the entity main body before pushing the message forward or on the entity main body (Entity- Body) Decoding (Some experimental applications for the Internet Mail content type use the media type parameters "; conversions = C.4 No content Transmission Coding (no content-transfer-encoding) HTTP does not use the CTE (Content-Transfer-Encoding) domain of RFC1521. Agent and gateway compatible with the MIME protocol must clear any no identifiable CTE encoding ("quoted-printable" or "base64") before passing the response message to the HTTP client. Proxy and gateways from HTTP to MIME compatibility protocols are responsible for ensuring correct and encoding transmission security on the protocol, so-called secure transmission refers to the restrictions or constraints specified in the corresponding protocol. The agent or gateway should identify data with the appropriate content transmission coding to improve the possibility of implementing secure transmission on the destination protocol. C.5 HTTP Title Domain (HTTP Header Fields in Multipart Body-Parts) In RFC1521, most of the types of mains components are typically ignored unless their domain name begins with "Content-". In HTTP / 1.0, any HTTP title field contained in multiple body portys is only meaningful for the corresponding part. D. Additional Features (Additional Features) Some protocol elements included in this appendix are present in some HTTP implementations, but they are not applicable to all HTTP / 1.0 applications. Developers should pay attention to these features, but they cannot rely on them to interact with other HTTP / 1.0 applications. Berners-Lee, et al information [page 57] D.1 Additional Request Methods (Additional Request Methods) D.1.1 PUT The PUT method requesting the server stores the entity of the attachment in the request URI. If the resource that the request URI points to, the attachment entity should be seen as a modified version of the current resource on the current original server. If the request URI does not point to the existing resource, the URI will be defined by the requested user agent into a new resource, and the original server will use the URI to generate this resource. The basic difference between the POST and PUT two requests is that the understanding of the request URI is different. The resources identified in the POST request method will be processed as an accessory entity by the server, which may be a data receiving process, a gateway of some other protocols, or a separate entity that can be annotated. In contrast, the user agent clearly knows where the entity identified in the PUT request is pointed out, and the request should not be used on other resource headers at the server. D.1.2 Delete The delete method requests the original server to delete the resources specified by the request URI. D.1.3 LINK The LINK method establishes one or more connection relationships between the resource specified by the request URI or other existing resources. D.1.4 unlink UNLINK method Deletes one or more connection relationships between the resources specified by the request URI. D.2 Additional Title Domain Definitions (Additional Header Field Definitions) D.2.1 ACCEPT The Accept request title domain is used to indicate a list of media ranges that can be accepted. The asterisk "*" is used to group media types, with "* / *" instructions to accept all media types; "Type / *" instructs all subtypes that accept the Type type. For a given context, the client should indicate which types are it acceptable. Berners-Lee, et al information [Page 58] D.2.2 Acceptable font set (Accept-charset) The ACCEPT-CHARSET request Title domain is used to indicate the preferred character set in addition to US-ASCII and ISO-8859-1. This domain will enable the client to understand more or more character sets, which can be stored on the server to store documents with such a character set. D.2.3 Accept coding (Accept-encoding) The Accept-Encoding request The title field is similar to the Accept, but limits the Content-Coding value that the response is accepted. D.2.4 Accept-language (Accept-Language) Accept-language request The title domain is similar to Accept, but limits the preferred natural language set in the request response. D.2.5 Content Language (Content-Language) The Content-Language entity header domain describes the natural language specified in additional entities. Note that this may be not a matter of matter with various languages used inside the entity. D.2.6 Connection (LINK) The LINK entity title domain describes the relationship between entities and certain other resources. An entity may include multiple connection values. LINK in the meta-information level indicates the relationship between the hierarchical structure and the navigation path. D.2.7 MIME version (MIME-VERSION) The HTTP message may include a single MIME version of the General-HEADER domain to indicate the version of the MIME protocol to construct messages. The use of the MIME version of the title is as defined in RFC1521 [5], and should be used to indicate whether the message meets the MIME specification. However, unfortunately, some old HTTP / 1.0 servers do not select this domain, causing this domain to be discarded. Berners-Lee, et al information [Page 59] D.2.8 is in .... Retroyal-After The Retry-After response to the title field can be used with 503 (service unavailable) to indicate the length of time for the server to stop responding to the customer request. The value of this domain can be represented by the date in the HTTP format, or an integer can also be used to indicate the number of seconds after the response time. D.2.9 Title (Title) Title entity Title domain is used to indicate the title of the entity. D.2.10 URI The URI entity header domain may contain some or all of the Uniform Resource Identifiers. See Section 3.2, through these identities to represent the resources specified by the request URI. It is not guaranteed to be able to find the specified resource based on the URI. Berners-Lee, et al information [Page 60] Translator statement: This document is translated by chifire (chifire@263.net). This document maintains consistent with the original RFC documentation as much as possible in the typographic format. Since I have limited level, some places may be insufficient enough, or even mistakes, or some terminology translation is wrong, please invite God to forgive, and write criticism.
