Re: XSS mitigation in browsers

Yes --- I would be sad if the github 404 stopped working. https://github.com/404

=devdatta

On 24 January 2011 10:42, Collin Jackson <collin.jackson@sv.cmu.edu> wrote:
> On Thu, Jan 20, 2011 at 4:07 PM, Steingruebl, Andy
> <asteingruebl@paypal-inc.com> wrote:
>>
>> > -----Original Message-----
>> > From: Michal Zalewski [mailto:lcamtuf@coredump.cx]
>> >
>> > Possibly, but IIRC, this does not happen today with <img>, <script>,
>> > etc. IIRC,
>> > Any codes other than 30x and 401 (and possibly other obscure cases) are
>> > essentially treated as 200. I suppose this is in line with the tradition
>> > of
>> > ignoring other HTTP information in these cases (Content-Type, Content-
>> > Disposition), although there are some efforts to improve at least that
>> > last
>> > part.
>>
>> Any history on why this is the case?  And, what would break if this
>> behavior changed?
>>
>> For example, we've never seen a case in recent history where any browser
>> will execute the embedded script in your example when the page is a 302 for
>> example, and yet some vuln scanners still complain about this issue.
>>
>> I realize lots of people have rich 404-pages, but how much would we really
>> break if we turned that off? No "dynamic content" on a 404? Or, some other
>> heuristic which covers your include case safely, but doesn't impact people's
>> existing 404-pages that embed content.
>
> I've personally worked on several large web sites that included JavaScript
> in 404 replies. The semantically correct thing to do when you have a
> nonexistent URL is to return a 404. When this happens, the user probably
> wants to use the navigation menu or search box to get where they're going,
> and navigation menus and search boxes are often enhanced with JavaScript.

Received on Monday, 24 January 2011 18:53:26 UTC