Re: [websec] mimesniff feedback, part 2
Larry Masinter <masinter@adobe.com> Sun, 08 January 2012 15:49 UTC
Return-Path: <masinter@adobe.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71F521F8505 for <websec@ietfa.amsl.com>; Sun, 8 Jan 2012 07:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.254
X-Spam-Level:
X-Spam-Status: No, score=-107.254 tagged_above=-999 required=5 tests=[AWL=-2.145, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF1hP3gyKijs for <websec@ietfa.amsl.com>; Sun, 8 Jan 2012 07:49:58 -0800 (PST)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4381321F84A1 for <websec@ietf.org>; Sun, 8 Jan 2012 07:49:58 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTwm7ES+l/y3XWoi3T6wGGIyaFOLshIxB@postini.com; Sun, 08 Jan 2012 07:49:58 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q08FnaPu013584; Sun, 8 Jan 2012 07:49:36 -0800 (PST)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q08FnY7o009477; Sun, 8 Jan 2012 07:49:34 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sun, 8 Jan 2012 07:49:33 -0800
From: Larry Masinter <masinter@adobe.com>
To: Adam Barth <ietf@adambarth.com>
Date: Sun, 08 Jan 2012 07:49:31 -0800
Thread-Topic: [websec] mimesniff feedback, part 2
Thread-Index: AczN0rj3mAMqp3BZTsWNU4WokVvgaQASGHwQ
Message-ID: <C68CB012D9182D408CED7B884F441D4D06123B4E44@nambxv01a.corp.adobe.com>
References: <op.v5icng1csr6mfa@kirk> <CAJE5ia81jBN1hmpUG-0fupHd=XfcWwxJZKN1sbZ2PkuSZmvOcA@mail.gmail.com> <4ED0E230.3010507@gmx.de> <CAJE5ia9Eh76vyiithc5VOrb1hRufC=hH604qrB5Nsiz=DsGgNw@mail.gmail.com> <C68CB012D9182D408CED7B884F441D4D0612042673@nambxv01a.corp.adobe.com> <4F068031.3080906@gondrom.org> <C68CB012D9182D408CED7B884F441D4D06123B4CA4@nambxv01a.corp.adobe.com> <CAJE5ia-Ay6KGrG51BneeQN-3usA+DY-hUw-hfEjhvoBnArvLWg@mail.gmail.com>
In-Reply-To: <CAJE5ia-Ay6KGrG51BneeQN-3usA+DY-hUw-hfEjhvoBnArvLWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "IETF WebSec WG (websec@ietf.org)" <websec@ietf.org>
Subject: Re: [websec] mimesniff feedback, part 2
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Jan 2012 15:49:59 -0000
I've started on editing the sniffing document in earnest. Foolishly, I started going through it from the beginning. Here's a take at the Abstract to make the scope clearer: <t>HTTP provides a way of labeling content with its Content-Type, an indication of the file format / language by which the content is to be interpreted. Unfortunately, many web servers, as deployed, supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, web clients would consider the content of HTTP responses as well as the Content-Type header fields when determining how the content was interpreted (the "effective media type"). Looking at content to determine its type (aka "sniffing") is also used when no Content-Type header is supplied. Overly ambitious sniffing has resulted in a number of security issues in the past. This document specifies methods and options for computing an effective media type, in a way that addresses both security and compatibility considerations. It also discusses the use of sniffing in contexts other than delivery of content via HTTP. </t> I wanted to address the scope by making it clear that the scope of the document included sniffing outside of content delivered via HTTP. *** Shouldn't sniffed content have a different origin than the content as labeled? The only "privilege upgrade" that I've come across seem to be cross-origin ones. *** Is sniffing used by servers when clients use file-upload? Doe web servers do sniffing on content to decide what media type to label the content with? Or is sniffing really only scoped to apply to web browsers? <section anchor="intro" title="Introduction"> <t>HTTP provides a way of labeling content with its Content-Type, as an indication of the file format / language by which the content is to be interpreted. Unfortunately, many web servers, as deployed, supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, web clients would consider the content of HTTP responses as well as the Content-Type header fields when determining how the content was interpreted (the "effective media type"). Looking at content to determine its type (aka "sniffing") is also used when no Content-Type header is supplied.</t> I tried to introduce "effective media type" as it was used before defined. Where is the term "privilege escalation", as used in this document, defined? http://en.wikipedia.org/wiki/Privilege_escalation defines the term in general, and then at the end mentions a couple of examples under ===============begin Wikipedia quote =========================== "Examples of horizontal privilege escalation" This problem often occurs in web applications. Consider the following example: User A has access to his/her bank account in an Internet Banking application. User B has access to his/her bank account in the same Internet Banking application. The vulnerability occurs when User A is able to access User B's bank account by performing some sort of malicious activity. This malicious activity may be possible due to common web application weaknesses or vulnerabilities. Potential web application vulnerabilities or situations that may lead to this condition include: * Predictable session ID's in the user's HTTP cookie * Session fixation * Cross-site Scripting * Easily guessable passwords * Theft or hijacking of session cookies * Keystroke logging ===============end Wikipedia quote ========================== But there are no mentions there of sniffing is a source of privilege escalation. Surely since this is the main use case the specification is intended to mitigate, shouldn't it be described somewhere? The examples given in passing in the document seem to be XSS attacks (which would be mitigated merely by giving sniffed content a different unique origin, wouldn't it?) The abstract implies there might be other attacks too... are there? what are they? Larry -- http://larry.masinter.net
- [websec] mimesniff feedback, part 2 Philip Jägenstedt
- Re: [websec] mimesniff feedback, part 2 Adam Barth
- Re: [websec] mimesniff feedback, part 2 Julian Reschke
- Re: [websec] mimesniff feedback, part 2 Adam Barth
- Re: [websec] mimesniff feedback, part 2 Larry Masinter
- Re: [websec] mimesniff feedback, part 2 Peter Saint-Andre
- Re: [websec] mimesniff feedback, part 2 Larry Masinter
- Re: [websec] mimesniff feedback, part 2 Adam Barth
- Re: [websec] mimesniff feedback, part 2 Tobias Gondrom