issue 2550690 - Adding anti-csrf measures to roundup following

  https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

and

  https://seclab.stanford.edu/websec/csrf/csrf.pdf

Basically implement Synchronizer (CSRF) Tokens per form on a page.
Single use (destroyed once used). Random input data for the token
includes:

   system random implementation in python using /dev/urandom
     (fallback to random based on timestamp as the seed. Not
      as good, but should be ok for the short lifetime of the
      token??)
   the id (in cpython it's the memory address) of the object
     requesting a token. In theory this depends on memory layout, the
     history of the process (how many previous objects have been
     allocated from the heap etc.) I claim without any proof that for
     long running processes this is another source of randomness. For
     short running processes with little activity it could be guessed.
  last the floating point time.time() value is added. This may
     only have 1 second resolution so may be guessable.

Hopefully for a short lived (2 week by default) token this is
sufficient. Also in the current implementation the user is notified when
validation fails and is told why. This allows the roundup admin to find
the log entry (at error level) and try to resolve the issue. In the
future user notification may change but for now this is probably best.

Author: rouilj

CHANGES.txt

@@ -178,8 +178,16 @@ Features:
   be deprecated. See ``upgrading.txt`` for details.
 - New property for permissions added to simplify the model. See
   ``customizing.txt`` and search for props_only and
-    set_props_only_default in the section 'Adding a new Permission'.
-    (John Rouillard)
+  set_props_only_default in the section 'Adding a new Permission'.
+  (John Rouillard)
+- issue2550690 - Inadequate CSRF protection. Improvements in
+  Cross Site Request Forgery protection to check HTTP headers
+  and nonces. If the header/nonce is present, they are
+  validated. But if headers or nonces are missing access is
+  granted. The enforcement policy can be set in config.ini.
+  Requiring enforcement will need some changes to
+  templates. Support for protecting xmlrpc endpoint not well
+  tested.  See ``upgrading.txt``. (John Rouillard)
 
 Fixed:
 

doc/customizing.txt

@@ -1644,6 +1644,54 @@ for each action are:
 **search**
  Determine whether the user has permission to view this class.
 
+Protecting users from web application attacks
+---------------------------------------------
+
+There is a class of attacks known as Cross Site Request Forgeries
+(CSRF). Malicious code running in the browser can making a
+request to roundup while you are logged into roundup.  The
+malicious code piggy backs on your existing roundup session to
+make changes without your knowledge. Roundup 1.6 has support for
+defending against this by analyzing the
+
+* Referer,
+* Origin, and
+* Host or 
+* X-Forwarded-Host
+
+HTTP headers. It compares the headers to the value of the web setting
+in the [tracker] section of the tracker's ``config.ini``.
+
+Also a per form token (also called a nonce) can be enabled for
+the tracker using the ``csrf_enforce_token`` option in
+config.ini.  When enabled, roundup will validate a hidden form
+field called ``@csrf``. If the validation fails (or the token
+is used more than one) the request is rejected.  The ``@csrf``
+input field is added automatically by calling the ``submit``
+function/path. It can also be added manually by calling
+anti_csrf_nonce() directly. For example:
+
+   <input name="@csrf" type="hidden"
+      tal:attributes="value python:utils.anti_csrf_nonce(lifetime=10)">
+
+By default a nonce lifetime is 2 weeks. However the lifetime (in
+minutes) can be set by passing a lifetime argument as shown
+above. The example above makes the nonce lifetime 10 minutes.
+ 
+Search for @csrf in this document for more examples. There are
+more examples and information in ``upgrading.txt``.
+
+The token protects you because malicious code supplied by another
+site is unable to obtain the token. Thus many attempts they make
+to submit a request are rejected.
+
+The protection on the xmlrpc interface is untested, but is based
+on a valid header check against the roundup url and the presence
+of the ``X-REQUESTED-WITH`` header. Work to improve this is a
+future project after the 1.6 release.
+
+The enforcement levels an be modified in ``config.ini``. Refer to
+that file for details.
 
 Special form variables
 ----------------------
@@ -2366,7 +2414,7 @@ classhelp   display a link to a javascript popup containing this class'
             javascript help_window function - it's the name of the form
             the "property" belongs to.
 
-submit      generate a submit button (and action hidden element)
+submit      generate a submit button (and action and @csrf hidden elements)
 renderWith  render this class with the given template.
 history     returns 'New node - no history' :)
 is_edit_ok  is the user allowed to Edit the current class?
@@ -2399,7 +2447,7 @@ There are several methods available on these wrapper objects:
 =============== ========================================================
 Method          Description
 =============== ========================================================
-submit          generate a submit button (and action hidden element)
+submit          generate a submit button (and action and @csrf hidden elements)
 journal         return the journal of the current item (**not
                 implemented**)
 history         render the journal of the current item as HTML
@@ -3610,6 +3658,12 @@ Then a submit button so that the user can submit the new category::
      </td>
     </tr>
 
+The ``context/submit`` bit generates the submit button but also
+generates the @action and @csrf hidden fields. The @action field is
+used to tell roundup how to process the form. The @csrf field provides
+a unique single use token to defend against CSRF attacks. (More about
+anti-csrf measures can be found in ``upgrading.txt``.)
+
 Finally we finish off the tags we used at the start to do the METAL
 stuff::
 
@@ -5097,16 +5151,21 @@ To edit the status of all items in the item index view, edit the
 
     <tr>
      <td tal:attributes="colspan python:len(request.columns)">
+      <input name="@csrf" type="hidden"		
+           tal:attributes="value python:utils.anti_csrf_nonce()">
       <input type="submit" value=" Save Changes ">
       <input type="hidden" name="@action" value="edit">
       <tal:block replace="structure request/indexargs_form" />
      </td>
     </tr>
 
-   which gives us a submit button, indicates that we are performing an edit
-   on any changed statuses. The final ``tal:block`` will make sure that the
-   current index view parameters (filtering, columns, etc) will be used in 
-   rendering the next page (the results of the editing).
+   which gives us a submit button, indicates that we are performing an
+   edit on any changed statuses, and provides a defense against cross
+   site request forgery attacks.
+
+   The final ``tal:block`` will make sure that the current index view
+   parameters (filtering, columns, etc) will be used in rendering the
+   next page (the results of the editing).
 
 
 Displaying only message summaries in the issue display
@@ -5189,6 +5248,8 @@ Setting up a "wizard" (or "druid") for controlled adding of issues
 
     <form method="POST" onSubmit="return submit_once()"
           enctype="multipart/form-data">
+       <input name="@csrf" type="hidden"
+          tal:attributes="value python:utils.anti_csrf_nonce()">
       <input type="hidden" name="@template" value="add_page1">
       <input type="hidden" name="@action" value="page1_submit">
 
@@ -5205,6 +5266,8 @@ Setting up a "wizard" (or "druid") for controlled adding of issues
           tal:condition="context/is_edit_ok"
           tal:define="cat request/form/category/value">
 
+      <input name="@csrf" type="hidden"
+          tal:attributes="value python:utils.anti_csrf_nonce()">
       <input type="hidden" name="@template" value="add_page2">
       <input type="hidden" name="@required" value="title">
       <input type="hidden" name="category" tal:attributes="value cat">

doc/upgrading.txt

@@ -23,6 +23,84 @@ Contents:
 Migrating from 1.5.1 to 1.6.0
 =============================
 
+Cross Site Request Forgery Detection Added
+------------------------------------------
+
+Roundup 1.6. supports a number of defenses against CSRF.
+
+Http header verification against the tracker's ``web``
+setting in the ``[tracker]`` section of config.ini for the
+following headers:
+
+# Analyze the ``Referer`` HTTP header to make sure it
+  includes the web setting.
+# Analyse the ``Origin`` HTTP header to make sure the
+  schema://host matches the web setting.
+# Analyze the ``X-Forwarded-Host`` header set by a proxy
+  running in front of roundup to make sure it agrees with
+  the host part of the web setting.
+# Analyze the ``Host`` header to make sure it agrees with
+  the host part of the web setting. This is not done if
+  ``X-Forwarded-Host`` is set.
+
+By default roundup 1.6 does not require any specific header
+to be present. However at least one of the headers above
+*must* pass validation checks (usually ``Host`` or
+``Referer``) or the submission is rejected with an error.
+If any header fails validation, the submission is
+rejected. (Note the user's form keeps all the data they
+entered if it was rejected.)
+
+Also the admin can include unique csrf tokens for all forms
+submitted via post (delete and put methods are also
+included, but not currently used by roundup)). The csrf
+token (nonce) is tied to the user's session. When the user
+submits the form and nonce, the nonce is checked to make
+sure it was issued to the user and the same session. If this
+is not true the post is rejected and the user is notified.
+
+The standard context/submit templating item creates CSRF
+tokens by default. If you have forms that are not using the
+standard submit routine, you should add the following field
+to all forms:
+
+   <input name="@csrf" type="hidden"
+      tal:attributes="value python:utils.anti_csrf_nonce()">
+
+A unique random token is generated by every call to
+utils.anti_csrf_nonce() and is put in a database to be
+retreived if the token is used. Token lifetimes are 2 weeks
+by default but can be configured in config.ini. Roundup will
+automatically prune old tokens. Calling anti_csrf_nonce with
+an integer lifetime, for example
+
+   <input name="@csrf" type="hidden"
+      tal:attributes="value python:utils.anti_csrf_nonce(lifetime=10)">
+
+sets the lifetime of that nonce to 10 minutes.
+
+If you want to change the default settings, you have to
+update the web section in your tracker's config.ini's. To do
+this backup your existing config.ini.  Run:
+
+   roundup-admin -i /path/to/tracker genconfig config.ini.new
+
+to create a new config.ini in the file config.ini.new. Then
+merge the new csrf settings into your tracker's config.
+Look for settings that start with csrf. The config.ini.new
+file includes detailed descriptions of the settings.
+
+In general one of four values can be set for these
+settings. The default is ``yes``, which validates the header
+or nonce and blocks access if the validation fails. If the
+field/header is missing it allows access. Setting these
+fields to ``required`` blocks access if the header/nonce is
+missing.
+
+It is suggested that you change your templates so every form
+has an @csrf field and change the setting to 'required' for
+the csrf_enforce_token.
+
 Fix for path traversal changes template resolution
 --------------------------------------------------
 

roundup/cgi/actions.py

@@ -1141,6 +1141,14 @@ def handle(self):
         self.client.nodeid = None
         self.client.template = None
 
+        # Redirect to a new page on logout. This regenerates
+        # CSRF tokens so they are associated with the
+        # anonymous user and not the user who logged out. If
+        # we don't the user gets an invalid CSRF token error
+        # As above choose the home page since everybody can
+        # see that.
+        raise exceptions.Redirect, self.base
+
 class LoginAction(Action):
     def handle(self):
         """Attempt to log a user in.