Mercurial > p > roundup > code
view doc/security-history.txt @ 8411:ef1ea918b07a reauth-confirm_id
feat(security): Add user confirmation/reauth for sensitive changes
Auditors can raise Reauth(reason) exception to require the user to
enter a token (e.g. account password) to verify the user is performing
the change.
Naming is subject to change.
actions.py: New ReauthAction class handler and verifyPassword() method
for overriding if needed.
client.py: Handle Reauth exception by calling Client:reauth() method.
Default client:reauth method. Add 'reauth' action declaration.
exceptions.py: Define and document Reauth exception as a subclass of
RoundupCGIException.
templating.py: Define method utils.embed_form_fields().
The original form making a change to the database has a lot of form
fields. These need to be resubmitted to Roundup as part of the form
submission that verifies the user's password.
This method turns all non file form fields into type=hidden inputs.
It escapes the names and values to prevent XSS.
For file form fields, it base64 encodes the contents and puts them
in hidden pre blocks. The pre blocks have data attributes for the
filename, filetype and the original field name. (Note the original
field name is not used.)
This stops the file content data (maybe binary e.g. jpegs) from
breaking the html page. The reauth template runs JavaScript that
turns the encoded data inside the pre tags back into a file. Then
it adds a multiple file input control to the page and attaches all
the files to it. This file input is submitted with the rest of the
fields.
_generic.reauth.html (multiple tracker templates): Generates a form
with id=reauth_form to:
display any message from the Reauth exception to the user (e.g. why
user is asked to auth).
get the user's password
submit the form
embed all the form data that triggered the reauth
recreate any file data that was submitted as part of the form and
generate a new file input to push the data to the back end
It has the JavaScript routine (as an IIFE) that regenerates a file
input without user intervention.
All the TAL based tracker templates use the same form. There is also
one for the jinja2 template. The JavaScript for both is the same.
reference.txt: document embed_form_fields utility method.
upgrading.txt: initial upgrading docs.
TODO:
Finalize naming. I am leaning toward ConfirmID rather than Reauth.
Still looking for a standard name for this workflow.
Externalize the javascript in _generic.reauth.html to a seperate file
and use utils.readfile() to embed it or change the script to load it
from a @@file url.
Clean up upgrading.txt with just steps to implement and less feature
detail/internals.
Document internals/troubleshooting in reference.txt.
Add tests using live server.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Mon, 11 Aug 2025 14:01:12 -0400 |
| parents | 485cecfba982 |
| children |
line wrap: on
line source
.. meta:: :description: Security mechanism implementation document for historical purposes. :orphan: ============================= Old Security Mechanisms Notes ============================= Current situation ================= Current logical controls: ANONYMOUS_ACCESS = 'deny' Deny or allow anonymous access to the web interface ANONYMOUS_REGISTER = 'deny' Deny or allow anonymous users to register through the web interface ANONYMOUS_REGISTER_MAIL = 'deny' Deny or allow anonymous users to register through the mail interface Current user interface authentication and controls: - command-line tool access controlled with passwords, but no logical controls - CGI access is by username and password and has some logical controls - mailgw access is through identification using sender email address, with limited functionality available The web interface implements has specific logical controls, preventing non-admin users from accessing: - other user's details pages - listing the base classes (not issues or their user page) - editing base classes Issues ====== 1. The current implementation is ad-hoc, and not complete for all use cases. 2. Currently it is not possible to allow submission of issues through email but restrict those users from accessing the web interface. 3. Only one user may perform admin functions. 4. There is no verification of users in the mail gateway by any means other than the From address. Support for strong identification through digital signatures should be added. 5. The command-line tool has no logical controls. 6. The anonymous control needs revising - there should only be one way to be an anonymous user, not two (currently there is user==None and user=='anonymous'). Possible approaches =================== Security controls in Roundup could be approached in three ways: 1) at the hyperdb level, with read/write/modify permissions on classes, items and item properties for all or specific transitions. 2) at the user interface level, with access permissions on CGI interface methods, mailgw methods, roundup-admin methods, and so on. 3) at a logical permission level, checked as needed. In all cases, the security built into roundup assumes restricted access to the hyperdatabase itself, through operating-system controls such as user or group permissions. Hyperdb-level control --------------------- Control is implemented at the Class.get, Class.set and Class.create level. All other methods must access items through these methods. Since all accesses go through the database, we can implement deny by default. Pros: - easier to implement as it only affects one module - smaller number of permissions to worry about Cons: - harder to determine the relationship between user interaction and hyperdb permission. - a lot of work to define - must special-case to handle by-item permissions (editing user details, having private messages) User-interface control ---------------------- The user interfaces would have an extra layer between that which parses the request to determine action and the action method. This layer controls access. Since it is possible to require methods be registered with the security mechanisms to be accessed by the user, deny by default is possible. Pros: - much more obvious at the user level what the controls are Cons: - much more work to implement - most user interfaces have multiple uses which can't be covered by a single permission Logical control --------------- At each point that requires an action to be performed, the security mechanisms are asked if the current user has permission. Since code must call the check function to raise a denial, there is no possibility to have automatic default of deny in this situation. Pros: - quite obvious what is going on - is very similar to the current system Cons: - large number of possible permissions that may be defined, possibly mirroring actual user interface controls. - access to the hyperdb must be strictly controlled through program code that implements the logical controls. Action ====== The CGI interface must be changed to: - authenticate over a secure connection - use unique tokens as a result of authentication, rather than pass the user's real credentials (username/password) around for each request (this means sessions and hence a session database) - use the new logical control mechanisms - implement the permission module - implement a Role editing interface for users - implement htmltemplate tests on permissions - switch all code over from using config vars for permission checks to using permissions - change all explicit admin user checks for Role checks - include config vars for initial Roles for anonymous web, new web and new email users The mail gateway must be changed to: - use digital signatures - use the new logical control mechanisms - switch all code over from using config vars for permission checks to using permissions The command-line tool must be changed to: - use the new logical control mechanisms (only allowing write access by admin users, and read-only by everyone else)