Return-Path: 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 A4F1921F8636 for ; Mon, 9 Jul 2012 16:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.596 X-Spam-Level: X-Spam-Status: No, score=-106.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, 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 oRm9McF1nZz1 for ; Mon, 9 Jul 2012 16:19:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 842F821F8631 for ; Mon, 9 Jul 2012 16:19:26 -0700 (PDT) Received: from [128.89.253.161] (port=50951) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SoNFA-000FXw-0x; Mon, 09 Jul 2012 19:19:52 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Richard L. Barnes" In-Reply-To: Date: Mon, 9 Jul 2012 19:19:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71595112-9084-47B8-BD2E-44381509536E@bbn.com> References:

To: Adam Barth X-Mailer: Apple Mail (2.1278) Cc: websec@ietf.org Subject: Re: [websec] Content sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:19:27 -0000 I haven't thought much about this, but a couple of thoughts: The binary prologue means that the document is not valid HTML, so in = principle, it shouldn't be accepted as HTML. It makes you wonder what = other stuff you could put in there that the browser would stuff into the = DOM without it being obvious on the wire, say, to a proxy. I'm = imagining things like encrypted / compressed Javascript code that could = be unpacked by the more obviously HTML part of the page. =20 In a related vein, the "Text or Binary" section of = draft-ietf-websec-mime-sniff says that nothing scriptable must come out = of sniffing a binary blob. Yet in this case, it produced "text/html", = which is obviously scriptable. =20 --Richard On Jul 9, 2012, at 5:05 PM, Adam Barth wrote: > Why is this sniffing gone awry? Nothing bad seems to have happened in > this example. >=20 > Adam >=20 >=20 > On Mon, Jul 9, 2012 at 1:55 PM, Richard L. Barnes = wrote: >> Related to draft-ietf-websec-mime-sniff, an example of sniffing gone = awry: >> >>=20 >> It's a valid JPEG image that contains and HTML snippet in a comment = segment. As a result, when a browser loads the URL expecting an image, = it renders the image content, and when it expects HTML, it skips the = binary junk at the top and renders the HTML [*]. (In both cases, the = server reports Content-Type text/html.) What's even more startling is = that Chrome helpfully adds the binary junk at the top as the first child = of the element in the parsed DOM! >>=20 >> --Richard >>=20 >>=20 >> [*] At least in Chrome 20.0.1132.47 >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec