[Encore] @URL security

[Daniel Jung]

Hi all

Darius Jack wrote:
> talk about security of @URL and how to modify @URL to contain any risk
> with malicious code being run on computers of guests/ users/ players 
> visiting
> enCore MOO.

The java applet for v4 and below allows to address two targets: webframe 
(its default) and _blank. The verb sends an "argument" (rather: part of 
the string sent) to the java applet which one to use. Comparing the code 
in v2.1.1 and v3 (released 15 Apr 2001) reveals what happened, how and why.

Jan Rune Holmevik (wisely) changed the verb in question so that 
obnoxious javasripts on the target page would not result in loss of the 
encore main frame. I am deliberately saying _obnoxious_ and not 
_malicious_. In the late 90's, there was a sport in writing (or: using) 
javascript code that checked if the content was in the top level view or 
inside a frame, and if it was in a frame, the script took control over 
the window and replaced it with the target content ("breaking out of 
frames"). In versions before v5, this means logout, so the breakout 
script is not really malicious per se, but obnoxious.

It seems to me that people (coders/designers) have become more mature 
and are not using this break-free code as much as before. Yet, you will 
still meet that code. @url commands, if used at all (I will come back to 
why not to), should thus not be forced to be displayed in webframe, at 
least not by default.

Obnoxious is not everything. There _are_ pages with malicious scripts, 
like cross-server scripting, which actually may harm the user's computer 
and security. This is not affected by where the URL is shown; the harm 
will be done regardless of the frame in which the script runs.

You cannot redesign the verb to prevent malicious code from running. The 
verb just sends an instruction to the user's applet (to open a given 
page), and Java's built-in showDocument() method displays this given 
page somewhere. Malicious code and its effect is thus due to an 
interaction between the user (his browser) and the given page; the MOO 
has nothing to do with it.

@url *is* dangerous, but it is dangerous because of the showDocument() 
method in Java and of the vulnerability in browsers. It is exactly as 
dangerous as surfing the web is - only that with the @url command, this 
is done _for_ you, not _by_ you.

AND in addition, since the user is logged in a database while surfing, 
visiting scripted pages or malicious URLs may harm the moo too, because 
the user's browser runs with the user's authentication against the MOO 
data processing. I won't go into detail on this one, but it is a major 
security hole, which, when used in conjunction with a few other v4 
vulnerabilities, is fatal for v4 and below.

Bottom line: I suggest not using @url, but rather type the URL and tell 
people to copy-paste this URL if they want to. This is tedious, I know. 
And it requires new windows, which you don't want, since changing back 
and forth is teadious. Maybe it's the price to pay for participating in 
the jungle out there?

It is quite possible to write a new verb that shows only the issuer of 
the command the url typed, à la

   @url-me http://somesite.org/someurl.html

and have that verb instruct the applet to open it in webframe. As a 
matter of fact, you can already use the subsyntax

   @url http://somesite.org/someurl.html Darius

to do so; only this implies the main syntax displaying the URL to 
everybody in the room as the default.

This being said, not using @url will not solve all problems and 
vulnerabilities. But it will prevent some of them.

Just a quick update on how this is solved in v5: The chat is HTML-based, 
so the text is clickable (as opposed to the applet in versions below, 
which is Java-drawn chat). This way, the user is alerted that someone 
wants to show him a page, and that he may click to open it. The user may 
refuse to do so (if he doesn't want the page to be opened--be it because 
he is away from the computer, or an untrusted stranger wants to show a 
page), or he may rightclick and specify a new window in the mouse 
context meny to look at the page, or he uses a leftclick to have it 
displayed in webframe. And by the way, loss of the main frame, if it 
should happen, doesn't mean automatic logout any more either.

HTH,
- Daniel