On Sun, Jan 8, 2012 at 7:49 AM, Larry Masinter <[email protected]> wrote: > 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.
Nope. Browsers would not be able to implement that because it would break too many web sites. > *** 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? That seems out of scope for this document. This is a document for user agents. > <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. Sure, but just because the wikipedia article for privilege escalation doesn't call out sniffing an example doesn't mean that it isn't an example. > Surely since this is the main use case the specification is intended to > mitigate, shouldn't it be described somewhere? It's just a general term of art. If you like, we can add a reference to Section 3.3 of RFC 6454. > 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?) Not in all case, but that's not going to happen, so it's somewhat irrelevant. > The abstract implies there might be other attacks too... are there? what > are they? There are other attacks, but XSS is the most important one. I'd rather the reader focused on XSS because that's easiest to understand. Adam _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
