On Fri, Apr 4, 2008 at 1:43 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > I did the search, the docs were pretty obtuse though..
Yeah. Almost by definition you're dealing with the intersection of obscure behavior in two different codebases. Nobody understands it, much less includes it in test plans. > I still don't see the need to have this check here.. if the bug is that > someone passes in some %u encoded character and some cisco router doesn't > detect it properly.. I still don't see what Shindig has to do with that.. > If you're worried about that, outlaw "%u" encoding. Or decode all values > first, then re-encode them. (wait, we're already doing that). Quick! What happens if someone passes in "%ff%4fpensocial_owner_id" to our java code and then we pass it on to .NET code running in a japanese locale? The answer depends on the intersection of obscure behavior in two different codebases. 0xff 0x4f is a halfwidth unicode 'o', and some systems canonicalize it to a normal ascii 'o' and others don't. This kind of problem is why blacklisting invalid characters is a bad idea for security sensitive code. Whitelist what you know is safe. Reject everything else. > Plus, having Shindig fix for some broken detection system, I think is > totally off-base.. The reports of problems in IDS are an indication of the general type of attack. The root cause of the problem is having different platforms (Java vs .NET vs Perl vs Python vs C++ vs who-knows-what) trying to interpret arbitrary sequences of bytes in the exact same way. Because signed fetch involves our java code talking to arbitrary servers, we need to be concerned about the issue. The simplest fix is to disallow arbitrary sequences of bytes. Cheers, Brian
