Security: Finish first stage of audit

What we've done: We've tried to protect against attacks by the "public".
Most of our attention has been directed towards XSS, CSRF and other
attacks by users who aren't logged in.

Our security audit was based on the following principles:

 1) Users with access to /admin are (unfortunately) fully trusted.
    There are simply too many ways for them to escalate their privileges
    right now, if they're willing to use XSS and other attacks.
 2) Things which look "suspicious" were simply fixed, without any
    attempt to determine whether they could be exploited in the wild.
 3) Whenever possible, we instituted broad, automatic protections
    against entire classes of attacks.  These include SafeERB and
    read-only GET requests.  This means that we don't need to audit
    every single view, controller and plugin for subtle errors.

What still needs work: My hacked version of SafeERB is currently
breaking script/generate.

RAILS-2.2-TODO.txt

@@ -3,7 +3,8 @@ release based on Rails 2.2.
 
 / Try to upgrade to gem version of coderay
 / Fix TZInfo to work again
-  Security audit--see below
+/ Security audit--see below
+  Fix script/generate
   Make sure we know what's up with plugins
   We need to review our TODO comments
 
@@ -28,28 +29,32 @@ X   Can we restrict admin cookies to /admin ? No--need /accounts, too.
 /   Do we have trackback support to check? No.
 / Password change
 /   Verify token required to change e-mail and password
-  Everything else
+/ Everything else
 /   Don't ship :session_key in environment.rb!
 /   Do we need to override verifiable_request_format? No.
 /   Check redirection in lib/authenticated_system.rb
 /   Review mass assignment in public controllers - comments
 /   Check regexes for ^ and $
 /   Filter IMG tags
-    Block database updates on POST requests
-    Review http://guides.rubyonrails.org/security.html again
+/   Block database updates on POST requests
+/   Review http://guides.rubyonrails.org/security.html again
 
   Admin only
     For now, we'll assume that users with access to /admin don't try XSS
     Filter file names for uploads
+    Can we block file uploads into public?  What about caching?
     Review mass assignment in admin controllers
+    Only allow global admin functions on site 1 (or admin domain?)
+    Can we isolate articles, etc., from admin to prevent XSS?
+    Review http://guides.rubyonrails.org/security.html another time
 
   Later
     Improve password changing
     Can we use SafeERB for Liquid templates?
     Expire sessions after a while?
     Do we need to upgrade to an industrial-strength HTML sanitizer?
     Require the user to enter the old password when changing it
-      This will break our password reset system, actually
+      This will break our password reset system--need a major fix
     Require password to change e-mail address?
     Detect mass assignment failures in unit tests - not really security issue