[Twisted-Python] Five Crazy Ideas to Start Your Week

[Tommi Virtanen]

On Tue, Oct 08, 2002 at 02:04:24AM -0500, Glyph Lefkowitz wrote:
> 1. Perspective Broker URLS
> ==========================

> These URLs need to be able to represent transport mechanism (TCP? UNIX socket?
> SSL? Weird firewall-tunneling stuff?)

	"Talk to subprocess that runs this command to connect to the other end"
	("ssh remotehost pbserver", "ssh remotehost
	connect-stdinout-to-unix-socket /path/socket")

	And yes, I may want that even after Twisted has a fully working
	SSH implementation. For rex :)

>                                       plus everything about the object that
> you're trying to access (location? authentication information? authentication
> format?)

	I think you may want to look at SASL for ideas on
	authentication. It seems to be the standard way to add generic
	authentication support to a protocol these days.

> The idea is that you pass in a string, you get a Deferred PB "endpoint", which
> should be the object that you're really wanting to interact with.  Here are
> some off-the-cuff examples:
> 
>     pb://pyramid/service#perspective

	What part talks about TCP/UNIX/etc? service? Then it needs
	more structure to it.

>     pb://pyramid/identity:password@service#perspective

	Eww. Passwords in URLs is baaad. Because users like to enter
	URLs on command line.

	I'd much rather see an explicit "--password-file filename" and
	"--password-fd n".

> Public-key authentication mechanism, using the same identity name.  Connection
> over SSH transport (sshkey auth only available this way).
> 
>     pb-ssl://pyramid/cert$identity@service#perspective
> 
> PB over SSL, using certificate auth.
> 
>     pb://pyramid/this/that/the-other/my-service#perspective

	Hmm. Idea. Allow one to specify when the server is trusted.
	"Connect to server X if its public key has fingerprint F."
	http://www.fs.net/

> 2. Automatic XSS input scrubbing for Woven
> ==========================================
> 
> Form input that is intended to be used as HTML can be scanned for potentially
> abusive input so that the web administration interface for a bulletin board
> written using Twisted doesn't fall prey to the usual "cross site scripting"
> vulnerabilities that plague feedback-capable web sites.
> 
> The problem formulation, generally, is that an attacker will place some
> malicious javascript in a web form.  When some article is viewed by an admin,
> that malicious javascript executes in their browser, taking advantage of the
> fact that they have an admin cookie for that website in their browser.  It will
> take advantage of a security flaw in the browser and perform administrative
> tasks with their authority on the website without the admin's approval.
> 
> There are pretty much only a few ways they can do this, and I believe each one
> has a simple solution.
> 
>     - <script /> tags
> 
> Don't allow script tags in input, ever.  Force input that uses tags into a DOM
> tree before it is even made to be preview-able.  (DOM parsing can be relaxed,
> but before the tree is output, it is converted to well-formed XML).
> 
>     - <a href="..." /> tags
> 
> Stick a little warning after any "off-site" link, and turn it into a redirect.
> Any admin clicking on such a link will first be bounced through a URL which
> revokes their admin cookie so the attacking site won't have the ability to call
> back.
> 
>     - attributes on other HTML tags, such as onmouseover, that execute js
>       expressions
> 
> Catalogue these and scrub them all off.
> 
>     - <img /> or <object /> tags that automatically download other items, which
>       may be webpages containing javascript.
> 
> Again, don't allow these tags.  Or, have the server-side site download the
> images and verify that they are PNGs (alternately also doing PIL stuff to
> remove steganographic information, if you're _really_ paranoid).

	Your basic problem here is that you are trying to disallow
	things you know are not safe. That assumes you are omnipotent.
	While not contesting that, I still feel the only sane
	architecture is to catalogue known safe things, and only allow
	those. Something like a DTD/schema should do the job.

> Even if I managed to get this right for the web, though, trying to avoid lock
> in to the web's way of thinking about forms is very tricky!  I have yet to
> seriously think about how GTK, PyUI, or Tkinter would work with this.  I have
> spent a little while thinking about how a text-based virtual world interface in
> twisted reality, though, and that should be pretty easy (building a machine
> with dials, knobs, etc, and a big button for "submit").

	You may also be interested in the W3C work on XForms.

	IMHO, form-based GUIs suck horribly. A GUI is good only if
	it is interactive -- dynamic in some way. Most of the current
	GUIs only try to reach rich with forms that change
	dynamically.

	Have you ever used mc-foo fan? While certainly not the greatest
	GUI in the world, imagine you had to use it through forms.

> squatting.  I think that by having a distributed naming system (where different
> people call the "python" group different things, but python at twistedmatrix.com
> will always get you to the one you're looking for) might circumvent squatting.

	So user A will see python at python.org as "python", user B will see
	python at twistedmatrix.com as "python", and if those two ever have
	to be squashed to the same namespace, user A will see
	"python (python at python.org)" and "python at twistedmatrix.com"
	and user B will see "python at python.org" and "python
	(python at twistedmatrix.com)"?

	All is fine as long as the users don't talk about the channel
	names that much :)

	This problem may be easier to think of in terms of nicks than of
	channels; IIRC there was some chat system that under the hood
	identified users with user at host (unix user id / email, whatever),
	but allowed them to set their list of "preferred nicknames".
	User A would see user B with the first available preferred
	nickname from B's list, or as userB at hostB if none was
	available. And this was, IIRC, done fully in A's client; if B
	and C saw different people (were on different channels), they
	could see A with a different nickname.

-- 
:(){ :|:&};: