09:55 am, 11 May 05
xss and conventions
Joel Spolsky writes about conventions and uses defending against XSS as an example. He's more verbose than usual, so the paraphrased summary is this: If you prefix all variables holding user-provided strings with 'us' (unsafe) and all checked strings with 's' (safe) your errors will become apparent, as you never write code like Output(usFoo). In fact, you can rename your functions to be prefixed with the sort of data they accept to make it even more apparent.
I think it's well-intended but not a good example.
I think it's well-intended but not a good example.
- As I've written before, many programming conventions come from limitations in your language's type system, and this one in particular is just screaming for it. Here, you want GetStringFromUser() to return an "unsafe" string, and OutputString() to only accept "safe" strings. If these were separate datatypes (along with a no-op function ThisStringIsNowSafe() that goes from unsafe to safe while documenting the programmer's knowledge) you couldn't make these mistakes.
This sort of approach is even done by dynamically-typed languages: Perl's "taint" mode is a problem-specific hack for this. (Briefly, you add a flag to the interpreter(!), then all user input variables become "tainted", and applying a regular expression with grouping(!!) untaints the string.) Ruby has a similar but slightly more general approach. And the Amrita HTML templating system for Ruby escapes all inputs to templates, which the programmer can circumvent by calling SanitizedString on the strings.
I imagine that SantizedString wraps an object around the string and that the template expansion knows to look for the object. In fact, this sort of trick (making a new type that's the same as the old but has to be constructed explicitly) is common enough in Haskell there's a keyword for it that tells the compiler that the wrapping is only for typing and can be dropped when compiling (after it's checked to be typesafe)*. - But this points out a broader point: real websites don't/shouldn't have series of print statements to construct web pages, they just/should provide arguments to a template. This not only allows for programmer sanity with XSS (basically, everything's escaped and if you want otherwise you have to think about it / write more code), it also keeps consistency across pages, makes translation easier, etc. etc. (all the typical advantages of separating code from data).
By the way, several people in the Joel On Software Forums made similar points about using special types instead of naming conventions...
I oughta lj-cut more often. :)
Much of a template is static, right? Reprocessing the immutable parts seems wasteful. It'd be great to write a page template, xslt (2.0 hopefully) it ONCE into xhtml, wap, html, and then simply memcpy that out the door afterwards.
Simple dynamic values, like a user name, could be pulled from cookies. Remote/complex dynamic values could be loaded via XmlHttpRequest.
Piling the buzzwords on, the controller-side code could emit the model's output into a web service format like SOAP or YA ad hoc RESTish blob. That output could be immedately vended for web services, or translated into the page template language, then reprocessed into html. I've got toy code that does this, where "this" is waaay limited.
As for the templating thing; that only buys you so much, even on the XSS issue. You have to worry about idiot programmers calling things like eval(), exec(), and, most importantly, include() on tainted values. And, oh my god, do they ever do it a lot.
I, too, am curious about why the compiler can't tell the difference in Haskell. Maybe it just wasn't an issue in their design?
...All of this works using a data declaration instead of a newtype declaration. However, the data declaration incurs extra overhead in the representation of Natural values. The use of newtype avoids the extra level of indirection (caused by laziness) that the data declaration would introduce. See section 4.2.3 of the report for a more discussion of the relation between newtype, data, and type declarations. [Except for the keyword, the newtype declaration uses the same syntax as a data declaration with a single constructor containing a single field. This is appropriate since types defined using newtype are nearly identical to those created by an ordinary data declaration.
A declaration of the form
newtype cx => T u1 ... uk = N t
introduces a new type whose representation is the same as an existing type. The type (T u1 ... uk) renames the datatype t. It differs from a type synonym in that it creates a distinct type that must be explicitly coerced to or from the original type. Also, unlike type synonyms, newtype may be used to define recursive types. The constructor N in an expression coerces a value from type t to type (T u1 ... uk). Using N in a pattern coerces a value from type (T u1 ... uk) to type t. These coercions may be implemented without execution time overhead; newtype does not change the underlying representation of an object.
New instances (see Section 4.3.2) can be defined for a type defined by newtype but may not be defined for a type synonym. A type created by newtype differs from an algebraic datatype in that the representation of an algebraic datatype has an extra level of indirection. This difference may make access to the representation less efficient. The difference is reflected in different rules for pattern matching (see Section 3.17). Unlike algebraic datatypes, the newtype constructor N is unlifted, so that N _|_ is the same as _|_.