Sander Tekelenburg wrote: > I think it's up to the OS to offer such protection 3rd party apps can register their own protocol handlers. Adrian mentioned eDonkey, Lothar mentioned games. Certainly one could question whether this should be permitted, but it is. > leaving such things up to individual web sites seems like > relying on drops in an ocean. The number of protocol handlers commonly used is pretty small. Most wikis could just use some sensible defaults - http, https, ftp, mailto, maybe nntp and news. > As to implementation: besides needing a "complete" whitelist > of protocols for the default I don't think we need (nor want) a complete whitelist. Opera, for example, had a telnet protocol hander vulnerability. It's a matter of reducing surface area. > what about the user experience? <snip> > If suspect that if Dokuwiki isn't verbose > enough about it, such a protection scheme could result in > troubleshooting issues for Dokuwiki users and admins. Though I certainly have no evidence to back this up, I suspect anyone using an uncommon protocol handler in a link is one of two people: a) a user experienced enough to know what a protocol handler is, and to contact the admin if it's not working b) a malicious user who will give up if it's not working > Should Dokuwiki flat out not > accept content that contains an unregistered protocol? Should > it accept but silently drop? Should it accept, but not display? > Should it accept but display the links as plain text, instead > of a hyperlink? Should it display a warning/error message that > explains the problem? If it were my site I wouldn't want the link to display at all. But there's no way we can protect users completely. Even HTTP links can point to a malicious payload. I'd be fine with just rendering it as text. Maybe insert a space somewhere to make it harder for users to copy-and-paste. Walter -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist