[Twisted-Python] Five Crazy Ideas to Start Your Week
tv at twistedmatrix.com
Tue Oct 8 13:08:14 EDT 2002
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
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
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:
What part talks about TCP/UNIX/etc? service? Then it needs
more structure to it.
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
> Public-key authentication mechanism, using the same identity name. Connection
> over SSH transport (sshkey auth only available this way).
> PB over SSL, using certificate auth.
Hmm. Idea. Allow one to specify when the server is trusted.
"Connect to server X if its public key has fingerprint F."
> 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
> 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
> - attributes on other HTML tags, such as onmouseover, that execute js
> Catalogue these and scrub them all off.
> - <img /> or <object /> tags that automatically download other items, which
> 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
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.
More information about the Twisted-Python