Anzio in a web page

[Fairlight]

In the relative spacial/temporal region of
Wed, Apr 05, 2006 at 04:07:34PM -0700, Bob Rasmussen achieved the spontaneous
generation of the following:
> 
> There is very little here that is different from having the EXE versions
> of Anzio download-installable from the web. Someone could use that
> software (or telnet, or PuTTY) to access any site that had an open telnet
> or SSH port.

Noted.  But the fact remains that it's still enabling cross-site scripting.
You're using site 'x' to illicitly access site 'y'.  If this (and I
understand you haven't decided on licensing yet) happens to eat site x's
licenses in the process if it's done by hosting server, well that's not
very helpful to your direct customer.  The only thing saving it from being
really -bad- is that the client machine is the one making the connection,
not the server.  It's limited XSS admittedly, but XSS nonetheless.

> First, nothing requires the username and/or password to be included in the
> DEF file. If they are not provided, the program will prompt for them just
> as you would expect.
> 
> It should also be possible to password-protect the DEF file on the web
> server.
> 
> Finally, it IS possible to embed various parameters in the ActiveX
> object's resources.

The third sounds good.  The other two...  I realise that 'possible' can
be pointed to as a potential solution.  My opinion is that the developer
bears the onus for making everything they can that would be a security risk
impossible to implement.  No, you don't -have- to provide a user/pass pair,
you -can- protect the file, but in good practise there should be -zero-
ability to obtain these even if the implementing party was completely
clueless.  I can't help it if someone doesn't sanitise what OneGate gives
them froma submission, for example, but everything I -can- prevent, I -do-
prevent.  Due diligence really should apply to both sides when it comes to
security.

> Remember that not all web-based sites are accessible over the Internet.
> Many intranet applications are going web-based.
> 
> The intent of this program format was to have an object that visually
> resides within the web page, and over which the web page/server has some
> control.

And I'm sure that companies with intranet-based applications of this that
don't allow telnet or ssh clients, and who restrict network access will be
thrilled to learn that one of their employees was able to snarf umpteen
hours of 'net time talking to a site they weren't supposed to, possibly
putting their company in a position of legal exposure depending on use--all
because the application just happened to allow itself to be (ab)used that
way.  Intranets aren't always standalone and entirely disconnected from the
'net at-large.  It might not be accessible publicly for XSS, but it could
be (ab)used internally as XSS to access external sites.  Granted, that's
partly a policy and disciplinary problem, but why aggravate the customers
by helping it be possible, right? :)

Allowing the -server- to have control is a good thing.  Allowing the
-client- to have control is not.  And the second you let the page control
it, you let the client control it.  There's no escaping that binding.

I'm not trying to argue with you, but I really am used to looking at all
the angles I can think of.  I know that if I'm thinking it as a white-hat,
there are 200 black-hats out there thinking the same thing--or worse.
That's why I'm so stringent; it's impossible to cover every potential
factor, but one should really cover the ones that are already known.

The real question on my mind is..."Why?"  Especially, "Why now?"  There
are (and have been) Java applets out there for ages for telnet (dating
-wayyyy- back), and I believe I know of at least one ssh one, though I'd
have to verify.  They're freely available, have already invented the wheel,
and while they're likely not anywhere near as robust as Anzio in terms of
emulation abilities (most were vt100, period), I should think it would be
fairly hard to crack that (IMHO, tiny) segment of market at this point in
time.  A bit late to the party, to my mind.  I'm not saying it's unwise
or won't be successful, but it seems like there's dubious potential for
ROI--especially being a commercial product in a sea of OSS ones.  Another
list member had the same thoughts, voiced to me privately today.  I figured
I'd bring it up.  If I were a prospective customer, I'd be asking what
(besides more terminal types) this offers over the other solutions out
there.  Actually, it's been done commercially as well, and still is.
Tridia had CrossTie (since discontinued when the sole developer left), and
MultiView 2000 and Catalyst are both in the same vein with a rich feature
set.  Just seems like both the free and commercial competition is already a
bit steep to be diving in now.  But that's my observation.  Perhaps you
have more in-depth market data at your disposal than I do.

In any event, luck with it!

mark->