- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Fri, 21 Mar 2014 15:43:15 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, "Mark Nottingham" <mnot@mnot.net>, "HTTP Working Group" <ietf-http-wg@w3.org>, "Gabriel Montenegro" <gabriel.montenegro@microsoft.com>
Le Ven 21 mars 2014 15:25, Julian Reschke a écrit : > On 2014-03-21 14:58, Nicolas Mailhot wrote: >> ... >>> What I don't understand is how an out-of-band signal that can be >>> incorrect helps. If this is about security-related checks, you can't >>> trust it anyway, no? >> >> In a security context if something is suspicious you block/fail/error >> out >> and don't ask questions. >> >> With undefined encoding everything is suspicious so you can't act >> because >> it may be normal. > > Again: what makes the out-of-band signal trustworthy? > > If it is used for security-related checks, and it gets trusted, then > attackers *will* forge it. The signal is not used for security checks. The URLs are used for security check. Discrepancies between declared encoding and url content are one cause for suspicion. Lack of clear encoding rules does not make the whole thing more secure, it removes one parameter to check against, and prevents writing of other security checks due to unknown encoding fog. And, in theory, malware should repect 100% of all specs to avoid detection when triggering conformance checks, but in the actual world it does not because its aim is to work well enough for one campaign not work reliably on all possible web sites like a full browser. And even if malware started respecting 100% of all specs you would still win because you'd have removed the corner cases it could try to exploit. -- Nicolas Mailhot
Received on Friday, 21 March 2014 14:44:01 UTC