draft-ietf-websec-mime-sniff-01.txt   draft-ietf-websec-mime-sniff-02.txt 
None A. Barth None A. Barth
Internet-Draft I. Hickson Internet-Draft I. Hickson
Expires: July 28, 2011 Google, Inc. Expires: August 8, 2011 Google, Inc.
January 24, 2011 February 4, 2011
Media Type Sniffing Media Type Sniffing
draft-ietf-websec-mime-sniff-01 draft-ietf-websec-mime-sniff-02
Abstract Abstract
Many web servers supply incorrect Content-Type header fields with Many web servers supply incorrect Content-Type header fields with
their HTTP responses. In order to be compatible with these servers, their HTTP responses. In order to be compatible with these servers,
user agents consider the content of HTTP responses as well as the user agents consider the content of HTTP responses as well as the
Content-Type header fields when determining the effective media type Content-Type header fields when determining the effective media type
of the response. This document describes an algorithm for of the response. This document describes an algorithm for
determining the effective media type of HTTP responses that balances determining the effective media type of HTTP responses that balances
security and compatibility considerations. security and compatibility considerations.
Please send feedback on this draft to apps-discuss@ietf.org. Please send feedback on this draft to websec@ietf.org.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 28, 2011. This Internet-Draft will expire on August 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Web Pages . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Web Pages . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Text or Binary . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Text or Binary . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Unknown Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Unknown Type . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Signature for H.264 . . . . . . . . . . . . . . . . . . . 15
6. Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Feed or HTML . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Feed or HTML . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The HTTP Content-Type header field indicates the media type of an The HTTP Content-Type header field indicates the media type of an
HTTP response. However, many HTTP servers supply a Content-Type that HTTP response. However, many HTTP servers supply a Content-Type that
does not match the actual contents of the response. Historically, does not match the actual contents of the response. Historically,
web browsers have tolerated these servers by examining the content of web browsers have tolerated these servers by examining the content of
HTTP responses in addition to the Content-Type header field to HTTP responses in addition to the Content-Type header field to
determine the effective media type of the response. determine the effective media type of the response.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
| 3b 20 63 68 61 72 73 65 74 3d | | | 3b 20 63 68 61 72 73 65 74 3d | |
| 55 54 46 2d 38 | | | 55 54 46 2d 38 | |
+-------------------------------+--------------------------------+ +-------------------------------+--------------------------------+
...then jump to the "text or binary" section below. ...then jump to the "text or binary" section below.
3. If there is no official-type, jump to the "unknown type" section 3. If there is no official-type, jump to the "unknown type" section
below. below.
4. If the official-type is "unknown/unknown", "application/unknown", 4. If the official-type is "unknown/unknown", "application/unknown",
or "*/*", jump to the "unknown" type section below. or "*/*", jump to the "unknown type" section below.
5. If the official-type ends in "+xml", or if it is either "text/ 5. If the official-type ends in "+xml", or if it is either "text/
xml" or "application/xml", then let the sniffed-type be the xml" or "application/xml", then let the sniffed-type be the
official-type and abort these steps. official-type and abort these steps.
6. If the official-type is an image type supported by the user agent 6. If the official-type is an image type supported by the user agent
(e.g., "image/png", "image/gif", "image/jpeg", etc), then jump to (e.g., "image/png", "image/gif", "image/jpeg", etc), then jump to
the "images" section below. the "images" section below.
7. If the official-type is "text/html", then jump to the "feed or 7. If the official-type is "text/html", then jump to the "feed or
HTML" section below. HTML" section below.
8. Let the sniffed-type be the official type. 8. Let the sniffed-type be the official type.
4. Text or Binary 4. Text or Binary
This section defines the *rules for distingushing if a resource is This section defines the *rules for distinguishing if a resource is
text or binary*. text or binary*.
1. The user agent MAY wait for 512 or more octets be to arrive. 1. The user agent MAY wait for 512 or more octets be to arrive.
Note: Waiting for 512 octets octets to arrive causes the text- Note: Waiting for 512 octets octets to arrive causes the text-
or-binary algorithm to be deterministic for a given sequence or-binary algorithm to be deterministic for a given sequence
of octets. However, in some cases, the user agent might need of octets. However, in some cases, the user agent might need
to wait an arbitrary length of time for these octets to to wait an arbitrary length of time for these octets to
arrive. User agents SHOULD wait for 512 octets to arrive, arrive. User agents SHOULD wait for 512 octets to arrive,
when feasible. when feasible.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
2. Let index-stream be an index into the octet stream being 2. Let index-stream be an index into the octet stream being
examined. examined.
3. LOOP: If index-stream points beyond the end of the octet 3. LOOP: If index-stream points beyond the end of the octet
stream, then this row doesn't match and skip this row. stream, then this row doesn't match and skip this row.
4. Examine the index-stream-th octet of the octet stream as 4. Examine the index-stream-th octet of the octet stream as
follows: follows:
- If the index-pattern-th octet of the pattern is a - If the index-pattern-th octet of the pattern is a
normal hexadecimal octet and not a "WS" octet or a "SB" normal hexadecimal octet and not a "WS" octet or a "_>"
octet: octet:
If the bit-wise "and" operator, applied to the If the bit-wise "and" operator, applied to the
index-stream-th octet of the stream and the index- index-stream-th octet of the stream and the index-
pattern-th octet of the mask, yield a value pattern-th octet of the mask, yield a value
different than the index-pattern-th octet of the different than the index-pattern-th octet of the
pattern, then skip this row. pattern, then skip this row.
Otherwise, increment index-pattern to the next octet Otherwise, increment index-pattern to the next octet
in the mask and pattern and index-stream to the next in the mask and pattern and index-stream to the next
skipping to change at page 11, line 48 skipping to change at page 11, line 48
octet in the octet stream. octet in the octet stream.
5. If index-pattern does not point beyond the end of the mask 5. If index-pattern does not point beyond the end of the mask
and pattern octet strings, then jump back to the LOOP step and pattern octet strings, then jump back to the LOOP step
in this algorithm. in this algorithm.
6. Otherwise, let the sniffed-type be the type given in the 6. Otherwise, let the sniffed-type be the type given in the
cell of the third column in that row and abort these cell of the third column in that row and abort these
steps. steps.
4. If none of the first n octets are binary data (as defined in the 4. If the first n octets match the signature for H264 (as define in
Section 5.1), then let the sniffed-type be video/H264 and abort
these steps.
5. If none of the first n octets are binary data (as defined in the
"text or binary" section), then let the sniffed-type be "text/ "text or binary" section), then let the sniffed-type be "text/
plain" and abort these steps. plain" and abort these steps.
5. Otherwise, let the sniffed-type be "application/octet-stream" and 6. Otherwise, let the sniffed-type be "application/octet-stream" and
abort these steps. abort these steps.
The table used by the above algorithm is: The table used by the above algorithm is:
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| Mask in Hex | Pattern in Hex | Sniffed Type | Security | | Mask in Hex | Pattern in Hex | Sniffed Type | Security |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF DF DF DF | WS 3C 21 44 4F 43 | text/html | Scriptable | | FF FF FF DF DF DF | WS 3C 21 44 4F 43 | text/html | Scriptable |
| DF DF DF DF FF DF | 54 59 50 45 20 48 | | | | DF DF DF DF FF DF | 54 59 50 45 20 48 | | |
| DF DF DF FF | 54 4D 4C _> | | | | DF DF DF FF | 54 4D 4C _> | | |
skipping to change at page 14, line 23 skipping to change at page 14, line 27
| FF FF FF FF 00 00 | 52 49 46 46 00 00 | image/webp | Safe | | FF FF FF FF 00 00 | 52 49 46 46 00 00 | image/webp | Safe |
| 00 00 FF FF FF FF | 00 00 57 45 42 50 | | | | 00 00 FF FF FF FF | 00 00 57 45 42 50 | | |
| FF FF | 56 50 | | | | FF FF | 56 50 | | |
| Comment: "RIFF" followed by four bytes, followed by "WEBPVP". | | Comment: "RIFF" followed by four bytes, followed by "WEBPVP". |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF FF | 00 00 01 00 | image/vnd. | Safe | | FF FF FF FF | 00 00 01 00 | image/vnd. | Safe |
| | | microsoft.icon | | | | | microsoft.icon | |
| Comment: A Windows Icon signature. | | Comment: A Windows Icon signature. |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF FF FF | 4F 67 67 53 00 | application/ogg | Safe | | FF FF FF FF FF | 4F 67 67 53 00 | application/ogg | Safe |
| Comment: An Ogg Vorbis audio or video signature. | | Comment: An Ogg audio or video signature. |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF FF 00 00 | 52 49 46 46 00 00 | audio/x-wave | Safe | | FF FF FF FF 00 00 | 52 49 46 46 00 00 | audio/wave | Safe |
| 00 00 FF FF FF FF | 00 00 57 41 56 45 | | | | 00 00 FF FF FF FF | 00 00 57 41 56 45 | | |
| Comment: "RIFF" followed by four bytes, followed by "WAVE". | | Comment: "RIFF" followed by four bytes, followed by "WAVE". |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF FF | 1A 45 DF A3 | vidow/webm | Safe | | FF FF FF FF | 1A 45 DF A3 | video/webm | Safe |
| Comment: The WebM signature [TODO: Use more octets?] | | Comment: The WebM signature [TODO: Use more octets?] |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF FF FF FF | 52 61 72 20 1A 07 | application/ | Safe | | FF FF FF FF FF FF | 52 61 72 20 1A 07 | application/ | Safe |
| FF | 00 | x-rar-compressed| | | FF | 00 | x-rar-compressed| |
| Comment: A RAR archive. | | Comment: A RAR archive. |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF FF | 50 4B 03 04 | application/zip | Safe | | FF FF FF FF | 50 4B 03 04 | application/zip | Safe |
| Comment: A ZIP archive. | | Comment: A ZIP archive. |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
| FF FF FF | 1F 8B 08 | application/ | Safe | | FF FF FF | 1F 8B 08 | application/ | Safe |
| | | x-gzip | | | | | x-gzip | |
| Comment: A GZIP archive. | | Comment: A GZIP archive. |
+-------------------+-------------------+-----------------+------------+ +-------------------+-------------------+-----------------+------------+
[TODO: MP3 audio and H.264 video.] [TODO: MP3 audio.]
User agents MAY support additional types if necessary, by implicitly User agents MAY support additional types if necessary, by implicitly
adding to the above table. However, user agents SHOULD NOT not use adding to the above table. However, user agents SHOULD NOT not use
any other patterns for types already mentioned in the table above any other patterns for types already mentioned in the table above
because this could then be used for privilege escalation (where, because this could then be used for privilege escalation (where,
e.g., a server uses the above table to determine that content is not e.g., a server uses the above table to determine that content is not
HTML and thus safe from cross-site scripting attacks, but then a user HTML and thus safe from cross-site scripting attacks, but then a user
agent detects it as HTML anyway and allows script to execute). In agent detects it as HTML anyway and allows script to execute). In
extending this table, user agents SHOULD NOT introduce any privilege extending this table, user agents SHOULD NOT introduce any privilege
escalation vulnerabilities. escalation vulnerabilities.
Note: The column marked "security" is used by the algorithm in the Note: The column marked "security" is used by the algorithm in the
"text or binary" section, to avoid sniffing text/plain content as a "text or binary" section, to avoid sniffing text/plain content as a
type that can be used for a privilege escalation attack. type that can be used for a privilege escalation attack.
5.1. Signature for H.264
This section defines whether a sequence of n octets *matches the
signature for H.264*.
If n is less than 4, then the sequence does not match the signature
for H264 and abort these steps.
Let box-size be the value of the first four octets, interpreted as a
32 bit unsigned, little-endian integer.
If n is less than box-size or if box-size is not evenly divisible by
4, then the sequence does not match the signature for H264 and abort
these steps.
If octets 5 through 8 (inclusive) of the sequence are not 0x66 0x74
0x79 0x70 (the ASCII string "ftyp"), then the sequence does not match
the signature for H264 and abort these steps.
For each i from 2 to box-size/4 - 1 (inclusive):
1. If i is equal to 3, continue to the next i, if any. (These
octets correspond to the minor version number.)
2. If octets 4*i through 4*i + 3 (inclusive) of the sequence are
0x6D 0x70 0x34 (the ASCII string "mp4"), then the sequence *does*
match the signature for H264 and abort these steps.
The sequence does not match the signature for H264.
6. Image 6. Image
This section defines the *rules for sniffing images specifically*. This section defines the *rules for sniffing images specifically*.
If the official-type is "image/svg+xml", then let the sniffed-type be If the official-type is "image/svg+xml", then let the sniffed-type be
the official-type (an XML type) and abort these steps. the official-type (an XML type) and abort these steps.
If the first octets match one of the octet sequences in the first If the first octets match one of the signatures in Section 5 for one
column of the following table, then let the sniffed-type be the type of the following media types, then let the sniffed-type be the
given in the corresponding cell in the second column on the same row corresponding media type and abort these steps:
and abort these steps:
+-------------------------+--------------------------+-----------------+ o image/gif
| Bytes in Hexadecimal | Sniffed Type | Comment |
+-------------------------+--------------------------+-----------------+ o image/png
| 47 49 46 38 37 61 | image/gif | "GIF87a" |
| 47 49 46 38 39 61 | image/gif | "GIF89a" | o image/jpeg
| 89 50 4E 47 0D 0A 1A 0A | image/png | |
| FF D8 FF | image/jpeg | | o image/bmp
| 42 4D | image/bmp | "BM" |
| 00 00 01 00 | image/vnd.microsoft.icon | | o image/vnd.microsoft.icon
| (see Section ??) | image/webp | "RIFF????WEBPVP |
+-------------------------+--------------------------+-----------------+ o image/webp
Otherwise, let the sniffed-type be the official-type and abort these Otherwise, let the sniffed-type be the official-type and abort these
steps. steps.
7. Feed or HTML 7. Video
This section defines the *rules for sniffing videos specifically*.
If the first octets match one of the signatures in Section 5 for one
of the following media types, then let the sniffed-type be the
corresponding media type and abort these steps:
o video/H264
o video/webm
Otherwise, let the sniffed-type be the official-type and abort these
steps.
8. Fonts
This section defines the *rules for sniffing fonts specifically*.
TODO
Otherwise, let the sniffed-type be the official-type and abort these
steps.
9. Feed or HTML
1. The user agent MAY wait for 512 or more octets to arrive for the 1. The user agent MAY wait for 512 or more octets to arrive for the
same reason as in the "text or binary" section above. same reason as in the "text or binary" section above.
2. Let s be the stream of octets, and let s[i] represent the octet 2. Let s be the stream of octets, and let s[i] represent the octet
in s with position i, treating s as zero-indexed (so the first in s with position i, treating s as zero-indexed (so the first
octet is at i=0). octet is at i=0).
3. If at any point this algorithm requires the user agent to 3. If at any point this algorithm requires the user agent to
determine the value of a octet in s which has not yet arrived, determine the value of a octet in s which has not yet arrived,
skipping to change at page 20, line 5 skipping to change at page 22, line 5
continue to step 19 of this algorithm. continue to step 19 of this algorithm.
18. Jump back to step 13 of this algorithm. 18. Jump back to step 13 of this algorithm.
19. Let the sniffed-type be "text/html" and abort these steps. 19. Let the sniffed-type be "text/html" and abort these steps.
For efficiency reasons, implementations might wish to implement this For efficiency reasons, implementations might wish to implement this
algorithm and the algorithm for detecting the character encoding of algorithm and the algorithm for detecting the character encoding of
HTML documents in parallel. HTML documents in parallel.
8. References 10. References
[BarthCaballeroSong2009] [BarthCaballeroSong2009]
Barth, A., Caballero, J., and D. Song, "Secure Content Barth, A., Caballero, J., and D. Song, "Secure Content
Sniffing for Web Browsers, or How to Stop Papers from Sniffing for Web Browsers, or How to Stop Papers from
Reviewing Themselves", 2009, <http://www.adambarth.com/ Reviewing Themselves", 2009, <http://www.adambarth.com/
papers/2009/barth-caballero-song.pdf>. papers/2009/barth-caballero-song.pdf>.
Authors' Addresses Authors' Addresses
Adam Barth Adam Barth
 End of changes. 20 change blocks. 
34 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/