[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] GCS Spoofing
I agree that Nat has an excellent point - the spoofing problem buried in Unicode's massive repertoire has no silver bullet solution, user education and application-level intelligence is definitely needed. I have started collecting the characters, and will be done by tomorrow. I will then post the results to this list. Be warned, there is a whole bunch of them, as Nat said, and some are gray areas. Drummond, thanks for translating the problem statement into the wiki proposal page. wil. Drummond Reed wrote: > Nat, this is an extremely good point. I agree with you, that's the > full-scale solution. > > However, I think that Wil's suggestion that we could actaully block the > direct look-alike characters that would result in an "IDN-like" semantic > attack on the GCS characters and other XRI delimiter characters (focusing > particularly on @, =, +, !, *, and /) is still one we should look at > closely. > > Even if these would be blocked/converted by NFKC, a semantic attacker would > ignore that rule. So Wil's suggestion is that we disallow all Unicode > homographs for the XRI delimiters from the IRI iunreserved set might make it > easier for others in the XRI resolution chain (such as resolvers and > browsers) to block such an attack. > > Wil (and everyone), on Friday's TC call it was agreed to add this issue as > Issue #8 (IRI Authority Spoofing) Syntax change management page > (http://www.oasis-open.org/committees/download.php/11852/xri-syntax-v2.0-cd- > 01.pdf). The proposal page is at: > > > http://wiki.oasis-open.org/xri/Xri2Cd02/SynTax/I8IriAuthoritySpoofing > > Wil, the TC members wanted to know how many Unicode characters would be > involved (i.e., what's the scope of eliminating these homographs at the XRI > spec level?) And how long do you estimate it would take for you to create a > list of these characters that could be excluded from the iunreserved > production? > > Thanks - this was indeed a good catch. > > =Drummond > > -----Original Message----- > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] > Sent: Sunday, September 18, 2005 9:48 AM > To: Chetan Sabnis > Cc: xri@lists.oasis-open.org > Subject: RE: [xri] GCS Spoofing > > Actually, when it comes to internationalized characters, there are whole > bunch of possibility on Visual-Look-Alike base spoofing. Forcing NFKC > normalization would ease the problem a bit, but far from completely. > IMHO, it has to be dealt with trust and reputation mechanism being > coupled with client side support for the user so that user can view the > trust level easily. > > Nat > > >> -----Original Message----- >> From: Chetan Sabnis [mailto:chetan.sabnis@epok.net] >> Sent: Friday, September 16, 2005 11:30 PM >> Cc: xri@lists.oasis-open.org >> Subject: Re: [xri] GCS Spoofing >> >> >> Great find. I think the TC needs to address this in order >> for XRIs to be used as links in an email, as URIs would be >> used in an email today. >> The authority accessed by the resource needs to be be >> well-understood based on looking at the XRI if XRIs are >> indeed intended for human viewing. I think this is not a >> GCS-only issue. It certainly seems like the potential is >> there to spoof authorities in private cross-reference domains as well. >> >> Forgive my ignorance, but does the IRI spec address this? It >> seems like there might be some guidance there. >> >> Chetan >> >> William Tan wrote: >> >> >>> The ABNF for XRI accommodates two types of authority: XRI authority >>> and IRI authority. >>> An XRI authority must begin with a GCS character: "!", "=", >>> >> "@", "+" >> >>> or "$". However, if the XRI reference begins with a >>> >> character that is >> >>> visually indistinguishable from one of the GCS characters, and the >>> code point is allowed in the the "iunreserved" production, >>> >> a machine >> >>> processor would treat it as an IRI authority. This may be a >>> >> cause for >> >>> concern since it opens the door for spoofing. For example, >>> >> an actual >> >>> XRI may be: xri://@paypal*services/send-money >>> >>> and it could be spoofed (although not exactly) by using: >>> >>> xri://@paypal*services/send-money/sub.bad-domain.com/trustme.html >>> >>> And the "@" sign above is U+FE6B (small commercial at), "*" >>> >> is U+FE61 >> >>> (small asterisk), and the 4th and 5th "/" are U+2215 >>> >> (division slash). >> >>> In effect, the XRI would be interpreted as having an IRI >>> >> authority (an >> >>> IDN) of: "@paypal*services/send-money/sub.bad-domain.com". This is >>> possible largely because IDNA allows the slash-like character in an >>> IDN label, giving rise to the possibility of syntax spoofing. And >>> because sub domains appear to right of their parent domains, the >>> malicious domain can be created as a third (or higher) level sub >>> domain so that it is outside of the registry's control. >>> >>> This is merely a subclass of syntax spoofing homograph >>> >> attacks on IDN >> >>> which applies to XRIs. >>> >>> I'm not sure where is the best place to address it, or if it would >>> even be deemed a problem that the XRI TC would want to solve. If we >>> do, there are at least ways to go about fixing it, at the >>> >> syntax level >> >>> (i.e. by mapping or limiting the use of GCS characters) or as a >>> recommendation for XRI clients to disallow or warn the user of >>> GCS-like characters appearing at the beginning of an XRI reference. >>> >>> wil. >>> >>> >>> >> --------------------------------------------------------------------- >> >>> To unsubscribe from this mail list, you must leave the >>> >> OASIS TC that >> >>> generates this mail. You may a link to this group and all >>> >> your TCs in >> >>> OASIS >>> at: >>> >>> >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS >> TC that generates this mail. You may a link to this group >> and all your TCs in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr >> oups.php >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]