[sldev] [POLICY] Browser and web security vs the client.

Argent Stonecutter secret.argent at gmail.com
Wed Nov 28 06:54:08 PST 2007


On 28-Nov-2007, at 04:46, Callum Lerwick wrote:
> Which requires time. Time enough to detect the intrusion and reset
> everyone's  password, instantly invalidating the stolen database.

They have reset everyone's password at least once, and it took some  
people months (I've heard figures of up to 10 months) to get their  
accounts back, if at all. People lost accounts with real money  
involved. There is no scenario involving a compromise of the back-end  
database that isn't disastrous. Back-end security compromises are a  
red herring.

URI attacks are a real problem, but mostly for browsers.

SSL may mitigate one kind of URI quoting attack through the Windows  
ShellExecute API that has already been resolved in other ways for the  
SL client, but can't be resolved in general for browsers on Windows.  
This incident is pretty much done with, based on the brute-force but  
effective changes to the browser's command line parsing code.

Most other web-based security problems don't apply to the SL client,  
even in theory, right now, unless you use the in-game browser on user- 
provided content. This is one reason I don't use the in-game browser  
on profiles at all. Examples:

* Cross-zone attacks (only an issue for Internet Explorer).
* Cross-site attacks.
* Cross-site privacy exploits ("web bugs", which is where HTML-on-a- 
prim and web textures come in).
* Attacks through helper applications and plugins (a reason I was  
pushing an arms-length plugin mechanism through local TCP sockets).
* Attacks through privilege elevation of scripts (client-side  
scripting needs to be carefully designed).
* Attacks through remote plugin mechanisms like ActiveX and XPI  
installers.
* Social-engineering attacks through fake OS dialogs.
* Social-engineering attacks through look-alike web pages (which is a  
concern for web-based login).
* ...



More information about the SLDev mailing list