Mercurial > p > roundup > code
annotate doc/security-history.txt @ 8575:b1024bf0d9f7
feature: add nonceless/tokenless CSRF protection
Add tokenless CSRF protection following:
https://words.filippo.io/csrf/
Must be enabled using use_tokenless_csrf_protection in config.ini. By
default it's off. If enabled the older csrf_* settings are ignored.
The allowed_api_origins setting is still used for Origin comparisons.
This should also improve performance as a nonce isn't required so
generating random nonce and saving it to the otks database is
eliminated.
doc/admin_guide.txt, doc/reference.txt doc/upgrading.txt
doc updates.
roundup/configuration.py
add use_tokenless_csrf_protection setting.
move allowed_api_origins directly after
use_tokenless_csrf_protection and before the older csrf_* settings.
It's used by both of them.
Rewrite description of allowed_api_origins as its applied to all
URLs with tokenless protection, not just API URLs.
roundup/anypy/urllib_.py
import urlsplit, it is used in new code.
urlparse() is less efficient and splits params out of the path
component.
Since Roundup doesn't require that params be split from the path. I
expect future patch will replace urlparse() with urlsplit() globally
and not need urlparse().
roundup/cgi/client.py
add handle_csrf_tokenless() and call from handle_csrf() if
use_tokenless_csrf_protection is enabled.
refactor code that expires csrf tokens when used with the wrong
methods (i.e. GET) into expire_exposed_keys(). Call same from
handle_csrf and handle_csrf_tokenless. Also improve logging if this
happens including both Referer and Origin headers if available.
Arguably we dont care about CSRF tokens exposed via
GET/HEAD/OPTIONS in the tokenless case, but this cleans them up in
case the admin has to switch back. At some future date we can
delete all the nonce based CSRF from 2018.
Update handle_csrf() docstring about calling/returning
handle_csrf_tokenless() when enabled. Call
expire_exposed_keys(method) if token is supplied with wrong method.
roundup/cgi/templating.py
disable nonce generation/save and always return "0" when
use_tokenless_csrf_protection enabled.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Sun, 19 Apr 2026 20:50:07 -0400 |
| parents | 485cecfba982 |
| children |
| rev | line source |
|---|---|
| 7092 | 1 .. meta:: |
| 2 :description: | |
| 3 Security mechanism implementation document for historical purposes. | |
| 4 | |
| 5 :orphan: | |
| 6 | |
|
7322
485cecfba982
Simplify TOC; older docs pushed a level down; Consolidate debugging
John Rouillard <rouilj@ieee.org>
parents:
7092
diff
changeset
|
7 ============================= |
|
485cecfba982
Simplify TOC; older docs pushed a level down; Consolidate debugging
John Rouillard <rouilj@ieee.org>
parents:
7092
diff
changeset
|
8 Old Security Mechanisms Notes |
|
485cecfba982
Simplify TOC; older docs pushed a level down; Consolidate debugging
John Rouillard <rouilj@ieee.org>
parents:
7092
diff
changeset
|
9 ============================= |
| 3940 | 10 |
| 11 Current situation | |
| 12 ================= | |
| 13 | |
| 14 Current logical controls: | |
| 15 | |
| 16 ANONYMOUS_ACCESS = 'deny' | |
| 17 Deny or allow anonymous access to the web interface | |
| 18 ANONYMOUS_REGISTER = 'deny' | |
| 19 Deny or allow anonymous users to register through the web interface | |
| 20 ANONYMOUS_REGISTER_MAIL = 'deny' | |
| 21 Deny or allow anonymous users to register through the mail interface | |
| 22 | |
| 23 Current user interface authentication and controls: | |
| 24 | |
| 25 - command-line tool access controlled with passwords, but no logical controls | |
| 26 - CGI access is by username and password and has some logical controls | |
| 27 - mailgw access is through identification using sender email address, with | |
| 28 limited functionality available | |
| 29 | |
| 30 The web interface implements has specific logical controls, | |
| 31 preventing non-admin users from accessing: | |
| 32 | |
| 33 - other user's details pages | |
| 34 - listing the base classes (not issues or their user page) | |
| 35 - editing base classes | |
| 36 | |
| 37 Issues | |
| 38 ====== | |
| 39 | |
|
4732
8ee41c7372e7
doc: Fix some Sphinx warnings.
anatoly techtonik <techtonik@gmail.com>
parents:
4567
diff
changeset
|
40 1. The current implementation is ad-hoc, and not complete for all use cases. |
| 3940 | 41 2. Currently it is not possible to allow submission of issues through email |
| 42 but restrict those users from accessing the web interface. | |
| 43 3. Only one user may perform admin functions. | |
| 44 4. There is no verification of users in the mail gateway by any means other | |
| 45 than the From address. Support for strong identification through digital | |
| 46 signatures should be added. | |
| 47 5. The command-line tool has no logical controls. | |
| 48 6. The anonymous control needs revising - there should only be one way to be | |
| 49 an anonymous user, not two (currently there is user==None and | |
| 50 user=='anonymous'). | |
| 51 | |
| 52 | |
| 53 Possible approaches | |
| 54 =================== | |
| 55 | |
| 56 Security controls in Roundup could be approached in three ways: | |
| 57 | |
| 58 1) at the hyperdb level, with read/write/modify permissions on classes, items | |
| 59 and item properties for all or specific transitions. | |
| 60 2) at the user interface level, with access permissions on CGI interface | |
| 61 methods, mailgw methods, roundup-admin methods, and so on. | |
| 62 3) at a logical permission level, checked as needed. | |
| 63 | |
| 64 In all cases, the security built into roundup assumes restricted access to the | |
|
4567
32b24abfe98e
Documentation polishing.
Eric S. Raymond <esr@thyrsus.com>
parents:
4557
diff
changeset
|
65 hyperdatabase itself, through operating-system controls such as user or group |
| 3940 | 66 permissions. |
| 67 | |
| 68 | |
| 69 Hyperdb-level control | |
| 70 --------------------- | |
| 71 | |
| 72 Control is implemented at the Class.get, Class.set and Class.create level. All | |
| 73 other methods must access items through these methods. Since all accesses go | |
| 74 through the database, we can implement deny by default. | |
| 75 | |
| 76 Pros: | |
| 77 | |
| 78 - easier to implement as it only affects one module | |
| 79 - smaller number of permissions to worry about | |
| 80 | |
| 81 Cons: | |
| 82 | |
| 83 - harder to determine the relationship between user interaction and hyperdb | |
| 84 permission. | |
| 85 - a lot of work to define | |
| 86 - must special-case to handle by-item permissions (editing user details, | |
| 87 having private messages) | |
| 88 | |
| 89 | |
| 90 User-interface control | |
| 91 ---------------------- | |
| 92 | |
| 93 The user interfaces would have an extra layer between that which | |
| 94 parses the request to determine action and the action method. This layer | |
| 95 controls access. Since it is possible to require methods be registered | |
| 96 with the security mechanisms to be accessed by the user, deny by default | |
| 97 is possible. | |
| 98 | |
| 99 Pros: | |
| 100 | |
| 101 - much more obvious at the user level what the controls are | |
| 102 | |
| 103 Cons: | |
| 104 | |
| 105 - much more work to implement | |
| 106 - most user interfaces have multiple uses which can't be covered by a | |
| 107 single permission | |
| 108 | |
| 109 Logical control | |
| 110 --------------- | |
| 111 | |
| 112 At each point that requires an action to be performed, the security mechanisms | |
| 113 are asked if the current user has permission. Since code must call the | |
| 114 check function to raise a denial, there is no possibility to have automatic | |
| 115 default of deny in this situation. | |
| 116 | |
| 117 Pros: | |
| 118 | |
| 119 - quite obvious what is going on | |
| 120 - is very similar to the current system | |
| 121 | |
| 122 Cons: | |
| 123 | |
| 124 - large number of possible permissions that may be defined, possibly | |
| 125 mirroring actual user interface controls. | |
| 126 - access to the hyperdb must be strictly controlled through program code | |
| 127 that implements the logical controls. | |
| 128 | |
| 129 | |
| 130 Action | |
| 131 ====== | |
| 132 | |
| 133 The CGI interface must be changed to: | |
| 134 | |
| 135 - authenticate over a secure connection | |
| 136 - use unique tokens as a result of authentication, rather than pass the user's | |
| 137 real credentials (username/password) around for each request (this means | |
| 138 sessions and hence a session database) | |
| 139 - use the new logical control mechanisms | |
| 140 | |
| 141 - implement the permission module | |
| 142 - implement a Role editing interface for users | |
| 143 - implement htmltemplate tests on permissions | |
| 144 - switch all code over from using config vars for permission checks to using | |
| 145 permissions | |
| 146 - change all explicit admin user checks for Role checks | |
| 147 - include config vars for initial Roles for anonymous web, new web and new | |
| 148 email users | |
| 149 | |
| 150 The mail gateway must be changed to: | |
| 151 | |
| 152 - use digital signatures | |
| 153 - use the new logical control mechanisms | |
| 154 | |
| 155 - switch all code over from using config vars for permission checks to using | |
| 156 permissions | |
| 157 | |
| 158 The command-line tool must be changed to: | |
| 159 | |
| 160 - use the new logical control mechanisms (only allowing write | |
| 161 access by admin users, and read-only by everyone else) | |
| 162 | |
| 163 |