Permalink
Browse files

Organized notes

  • Loading branch information...
1 parent a2732fb commit c394d99e296ab03e70f2ae052deec766ab47fa89 Philip (flip) Kromer committed May 18, 2008
View
@@ -1,9 +1,8 @@
-Changes since fork from technoweenie's branch
-
-I've made a few security changes based on best practices recommended in
+Following best practices recommended in
* "The OWASP Guide to Building Secure Web Applications":http://www.owasp.org/index.php/Category:OWASP_Guide_Project
* "Secure Programming for Linux and Unix HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html
+* http://www.coresecuritypatterns.com/patterns.htm
They're described in more detail below.
@@ -45,8 +44,11 @@ h3. authenticated_system
* added uniform logout! methods
* format.any (as found in access_denied) doesn't work until
http://dev.rubyonrails.org/changeset/8987 lands.
-* cookies, just like session tokens, should be refreshed each time we cross the
- logged out/in barrier http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+
+* cookies are now refreshed each time we cross the logged out/in barrier
+ http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens
+ http://palisade.plynt.com/issues/2004Jul/safe-auth-practices/
+
* !!!! Possibly stupid !!!
Made current_user and logged_in? be public methods. I did this for the worst
possible reason -- so that I could write story steps that call it directly.
@@ -87,9 +89,32 @@ resubmiting an earlier form will. I think it's Mostly Harmless but I've left it
commented out.
I'd like to get the advice of someone who understands CSRF better than I on this
-change.
+change. This says we _should_ reset the session:
+
+ (http://tinyurl.com/5vdvuq) Regenerate session IDs upon privilege
+ changes. Most Web applications assign a session ID upon the first request for
+ a URL, even for anonymous users. If the user logs in, then the application
+ should create and assign a new session ID to the user. This not only
+ represents that the user has authenticated, but it reduces the chances of
+ eavesdropping attacks if the initial access to the application wasn't
+ conducted over SSL. It also mitigates against session fixation attacks
+ discussed earlier in the chapter, where an attacker goes to a site and gets a
+ session ID, then e-mails it to the victim and allows them to log in using the
+ ID that the attacker already knows
+
+
+
+h2. Non-backwards compatible Changes
+
+Here are a few changes that increase "Defense in Depth" but will invalidate
+existing login/passwords without a migration.
-h3. Non-backwards compatible Changes
+* If you have an existing site, none of these changes are compelling enough to
+ warrant migrating your userbase.
+* If you are generating for a new site, all of these changes are low-impact.
+ You should apply them.
+
+h3. minor changes
* login in /\w+\.\-_@/ This allows (most) email addresses and is safe for urls, database expressions (@, technically reserved in a url, will survive in most browsers)
If you want to be more permissive:
@@ -102,7 +127,7 @@ h3. Non-backwards compatible Changes
* Added site key to generator, users.yml.
* Made site key generation idempotent in the most crude and hackish way
-h4. Site key
+h3. Site key
A Site key gives additional protection against a dictionary attack if your
DB is ever compromised. With no site key, we store
@@ -122,7 +147,7 @@ Please note: if you change this, all the passwords will be invalidated, so DO
keep it someplace secure. Use the random value given or type in the lyrics to
your favorite Jay-Z song or something; any moderately long, unpredictable text.
-* Stretch
+h3. Password Encryption Stretching
Repeated applications of the hash make brute force (even with a compromised
database and site key) harder, and scale with Moore's law.
@@ -166,16 +191,3 @@ h3. Stories
* added them
-
-h3. Authentication security projects for a later date
-
-A couple little projects
-
-* Track 'failed logins this hour' and demand a captcha after say 5 failed logins
- ("RECAPTCHA plugin.":http://agilewebdevelopment.com/plugins/recaptcha)
- "De-proxy-ficate IP address": http://wiki.codemongers.com/NginxHttpRealIpModule
-
-* Make cookie spoofing a little harder: we set the user's cookie to
- (remember_token), but store digest(remember_token, request_IP). A CSRF cookie
- spoofer has to then at least also spoof the user's originating IP
- (see "Secure Programs HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html)
View
@@ -1,3 +1,26 @@
+This is mrflip's fork of "technoweenie's restful-authentication":/technoweenie/restful-authentication/
+plugin. The goal is to
+
+* Modularize to match security design patterns:
+** Authentication (currently: password, browser cookie token, HTTP basic)
+** Trust metric (email validation)
+** Authorization (stateful roles)
+* Add full RSpec and Story test suite
+* Leave a flexible framework that will play nicely with other access control / policy definition / trust metric plugins
+
+See the "wiki":http://github.com/mrflip/restful-authentication/wikis/home for notes on
+* "Security Design Patterns":Security-Patterns
+* [[Authentication]] -- Lets a visitor identify herself (and lay claim to her corresponding Roles and measure of Trust)
+* "Trust Metrics":Trustification -- Confidence we can rely on the outcomes of this visitor's actions.
+* "Authorization and Policy":Authorization -- Based on trust and identity, what actions may this visitor perform?
+* "Access Control":Access-Control -- How the Authorization policy is actually enforced in your code (hopefully without turning it into a spaghetti of if thens)
+* "Rails Security Plugins":RailsPlugins -- for Authentication, Trust, Authorization and Access Control
+
+These best versions are in the notes/ directory in the "source code":http://github.com/mrflip/restful-authentication/tree/master -- look there for the latest version.
+The wiki versions are taken (manually) from there.
+
+===========================================================================
+
Restful Authentication Generator
====
View
@@ -0,0 +1,15 @@
+
+h3. Authentication security projects for a later date
+
+
+* Track 'failed logins this hour' and demand a captcha after say 5 failed logins
+ ("RECAPTCHA plugin.":http://agilewebdevelopment.com/plugins/recaptcha)
+ "De-proxy-ficate IP address": http://wiki.codemongers.com/NginxHttpRealIpModule
+
+* Make cookie spoofing a little harder: we set the user's cookie to
+ (remember_token), but store digest(remember_token, request_IP). A CSRF cookie
+ spoofer has to then at least also spoof the user's originating IP
+ (see "Secure Programs HOWTO":http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/web-authentication.html)
+
+* Log HTTP request on authentication / authorization failures
+ http://palisade.plynt.com/issues/2004Jul/safe-auth-practices
@@ -1,3 +1,4 @@
+# -*- coding: mule-utf-8 -*-
module Authentication
module ByCookieToken
@@ -47,6 +48,11 @@ def refresh_token
end
end
+ #
+ # Deletes the server-side record of the authentication token. The
+ # client-side (browser cookie) and server-side (this remember_token) must
+ # always be deleted together.
+ #
def forget_me
self.remember_token_expires_at = nil
self.remember_token = nil
@@ -0,0 +1,2 @@
+
+See the notes in Authorization
@@ -0,0 +1,153 @@
+h2. Authorization
+
+"Best Practices for Authorization":http://www.owasp.org/index.php/Guide_to_Authorization
+# auth system should deny by default
+# Principle of least privilege (fine-grain)
+# each non-anonymous entry point have an access control check
+# authorization check at or near the beginning of code implementing sensitive activities
+# Ensure that Model code checks to ensure that the requesting user should have access to the protected resource.
+# Reauthorization for high value activities or after idle out
+# If custom code is required to perform authorization functions, consider
+ fail-safe authentication and exception handling – ensure that if an exception
+ is thrown, the user is logged out or at least prevented from accessing the
+ protected resource or function.
+# Well written applications centralize access control routines, so if any bugs
+ are found, they can be fixed once and the results apply throughout the
+ application immediately.
+
+h2. Authorization in a trust context
+
+* remember: goal is **prediction** not **control**
+
+h2. Patterns for Policy definition / Authorization / access control
+
+*Reference Monitor (SecPatt p256)
+** Set of authorization rules
+** Actor, Action, Resource => Monitor+(rules) => ctrlr
+* Role based:
+ subj, role, right. action, resource
+ RBAC, access is controlled at the system level, outside of the user's control
+* Filter based
+ User x Controller x Action x Params --
+* Object based
+ model security delegation
+* Access Control Matrix http://en.wikipedia.org/wiki/Access_Control_Matrix
+* CommandProcessor pattern (DSL approach)
+* DENY FROM ... / ALLOW FROM ... approach
+* Capability based control: bundle together the designation of an object and the permission to access that object
+ ie. I can name it if and only if I am allowed to get at it.
+
+h2. Notes from "Security patterns":http://www.amazon.com/Security-Patterns-Integrating-Engineering-Software/dp/0470858842
+by M Schumacher ("website for book":http://www.securitypatterns.org/)
+
+Reference Monitor (SecPatt p256)
+ * Set of authorization rules
+ * Actor, Action, Resource => Monitor+(rules) => ctrlr
+
+= Full access with Errors (SecPatt p305)
+
+* Users should not be able to view data or perform operations for which they
+ have no permissions.
+* Hiding an available and accessible function is inappropriate, because users
+ must be able to see what they can do.
+* The visual appeal and usability of a graphical user interface (GUI) can be de-
+ graded by varying layouts depending on the (current) access rights of a
+ user. For example, blank space might appear for some users where others see
+ options they can access, or sequence and number of menu items might differ,
+ depending on the current user’s rights, and thus ‘blind’ operation of the menu
+ by an expe- rienced user is no longer possible.
+* Showing currently unavailable functions can tease users to into upgrading
+ their access rights, for example by paying for the access or buying a license
+ after us- ing a demo version.
+* Trial and error are ineffective means of learning which functions are
+ accessible. Invoking an operation only to learn that it doesn’t work with
+ your access rights is confusing.
+* The privilege grouping of the typical user community might not be known at the
+ design time of the GUI, and it might change over time, for example through
+ organizational or business process changes, so that providing a few special
+ modes of the GUI depending on the corresponding user roles is inappropriate.
+* Checking whether a function is allowed by a user is most efficient, robust and
+ secure, if done by the function itself—at least the code performing the checks
+ is then closely related to the code performing the subsequent operation
+ afterwards.
+
+h2. Outcomes / Obligations
+
+-- forbid
+-- ask for trust escalation (eg log in, prove_as_human, validate_email, are_you_sure, send_me_ten_cents)
+-- drag ass
+-- permit
+
+-- reinterpret past actions based on future evolution of trust
+-- prioritize changesets based on trust.
+
+
+h2. Notes from "Core Security Patterns":http://www.coresecuritypatterns.com/patterns.htm website
+
+# Authentication Enforcer who the hell are you
+# Intercepting Validator Is your request well-formed
+# Authorization Enforcer Are you allowed to do that
+# Secure Logger Know what's happening/happened
+#
+
+h2. notes from "XACML":http://www.nsitonline.in/hemant/stuff/xacml/XACML%20Tutorial%20with%20a%20Use%20Case%20Scenario%20for%20Academic%20Institutions.htm
+
+PolicySets [Policy Combining Algorithm]
+Policy [Rule Combining Algorithm] (defines access to particular resources.)
+# Target
+## Subject Attributes
+## Resource Attributes
+## Action Attributes
+## Environment Attributes
+# Rule [Effect] Identify various conditions or cases under which a policy may become applicable
+## Subject Attributes user who has made an access request
+## Resource Attributes object to which access is requested
+## Action Attributes action the subject wants to take on the resource
+## Environment Attributes request environment (time of day, ip, etc)
+## Conditions
+# Obligations
+
+Roles -- student, janitor, dean, stranger, ...
+Branches -- Departments, etc.
+
+* Examine applicable rules until you get an outcome, failure or passes thru (in which case rejected)
+* Rule combining Algorithms
+
+* Obligations -- things to do once requests have been denied or permitted
+
+Reference Monitor (SecPatt p256)
+ * Set of authorization rules
+ * Actor, Action, Resource --> Monitor+(rules) --> ctrlr
+
+#
+# ask for permissions on arbitrary (subject, action, resource)
+ * roles
+# get filtered object based on action (:public_info, :admin_info, etc.)
+# attach a rule to a (subject|role, action, resource) triple
+ "subject should have role R"
+ "subject should have role R on resource X"
+ "should meet the
+
+* Role supervisor:
+ * adds, defines, removes roles. no policy -- just attaches roles to users
+
+* Policy
+ answers "can Actor do Action to Resource"
+ * Rules
+ * Rule resolution
+ * outcome, obligations.
+ policy definitions can come from many places, go to policy mgr.
+* Hall monitor
+ enforces policy (before filters)
+* Policy observers
+ handle policy obligations
+
+* Athentication -- identification, really: securely attach visitor to identity
+* Validation -- qualify trust
+* Access control -- define policy
+** Roles
+** Acc. matrix
+* Authorization -- enforce policy (reference monitor ; filter chain)
+* Obligations
+** Audit -- (observer)
+
@@ -0,0 +1,81 @@
+h1. Rails Authentication, Authorization and Access Control plugins
+
+h2. Authentication plugins
+
+* http://github.com/technoweenie/restful-authentication/tree/master -- the accepted standard for authentication
+* http://github.com/mrflip/restful-authentication/tree/master -- my fork of restful_authentication with more modularity, more specs and a few security tweaks
+* http://github.com/josh/open_id_authentication/tree/master -- OpenID authentication
+
+h2. Authorization plugins
+
+From
+* http://agilewebdevelopment.com/plugins/tag/security
+* http://www.vaporbase.com/postings/Authorization_in_Rails
+
+
+== maybe ==================================================================
+
+* http://github.com/jbarket/restful-authorization/tree/master
+
+* http://agilewebdevelopment.com/plugins/rolerequirement
+ http://code.google.com/p/rolerequirement/
+ http://rolerequirement.googlecode.com/svn/tags/role_requirement/
+ 9 votes
+
+* http://github.com/ezmobius/acl_system2/
+ http://agilewebdevelopment.com/plugins/acl_system
+ http://opensvn.csie.org/ezra/rails/plugins/dev/acl_system2/
+ last touched 2006
+ 57 votes on AWD
+ * also: http://agilewebdevelopment.com/plugins/acl_system2_ownership
+
+ bq. access_control [:new, :create, :update, :edit] => '(admin | user |
+ moderator)', :delete => 'admin'
+ <% restrict_to "(admin | moderator) & !blacklist" do %>
+ <%= link_to "Admin & Moderator only link", :action =>'foo' %>
+ <% end %>
+
+* Authorization Recipe (from Rails Recipes #32)
+ http://www.vaporbase.com/postings/Authorization_in_Rails
+ http://opensvn.csie.org/mabs29/plugins/simple_access_control
+
+* Active ACL
+ http://phpgacl.sourceforge.net/demo/phpgacl/docs/manual.html
+ (Access-matrix driven)
+
+* http://github.com/aiwilliams/access_controlled_system
+
+* http://agilewebdevelopment.com/plugins/access
+
+* http://robzon.aenima.pl/2007/12/base-auth-is-out.html
+ http://agilewebdevelopment.com/plugins/base_auth
+ http://base-auth.googlecode.com/svn/trunk/
+ 40 votes
+
+* http://agilewebdevelopment.com/plugins/authorization
+ http://www.writertopia.com/developers/authorization
+ http://github.com/DocSavage/rails-authorization-plugin/tree/master
+ Opaque policy descriptions
+ 19 votes
+
+* http://github.com/shuber/access_control_list/
+ Not much there yet
+
+* https://opensvn.csie.org/traccgi/tobionrails
+ http://agilewebdevelopment.com/plugins/access_control
+ http://opensvn.csie.org/tobionrails/plugins/access_control
+ last touched 1 year ago
+
+* http://github.com/mdarby/restful_acl/
+ -- google code too --
+ Just does REST? More of an app than a plugin.
+
+* http://github.com/stonean/lockdown/tree/master
+ http://lockdown.rubyforge.org
+ http://groups.google.com/group/stonean_lockdown?hl=en
+ "Lockdown stores an array of access rights in the session"
+
+h2. Trust / Validation etc. plugins
+
+
+* http://agilewebdevelopment.com/plugins/recaptcha
Oops, something went wrong.

0 comments on commit c394d99

Please sign in to comment.