• last updated 17 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce security::safe_tmpfile_p checking whether a file belongs to the configured tmpfolder and respects other constraints

The plan is to use it to improve input validations

  1. … 2 more files in changeset.
Deactivated script-dynamic again

activating "script-dynamic" for script-src prevents resources as the following from loading

<script type="text/javascript" src="/resources/xowiki/bootstrap-treeview/1.2.0/bootstrap-treeview.min.js" nonce="F8843D5CD542FB1CDB4C94C5D13C4E5ECC2E1DCA">

Properly escape "<" and ">" in api-doc documentation.

Since all documentation is rendered via HTML, the characters

"<" and ">" have to be HTML-quoted, otherwise strange things

(omission, unintended renderings) might occur.

E.g. the sentence

Define an interface between a page and an

ADP <include> similar to the page_contract.

was rendered as

Define an interface between a page and an

ADP similar to the page_contract.

which is incorrect.

  1. … 13 more files in changeset.
security::cookie_name: since this is used in acs-lang, it has to be public

  1. … 4 more files in changeset.
flipping of session_id apparently works without keeping track of the old session_id, so there is no need of keeping track of it

reduce verbosity

new API call ::security::csp::add_static_resource_header

The API call set the CSP rule on the current connection for a static

resource depending on the MIME type.

# Sample definition for custom CSP rules for static files in the

# OpenACS configuration file.

#

# ns_section ns/server/$server/acs {

# ...

# ns_param StaticCSP {

# image/svg+xml "script-src 'none'"

# }

# ...

# }

bump version number of acs-tcl to 5.10.1d13

  1. … 3 more files in changeset.
New feature: cookie namespaces

So far, all OpenACS versions used "ad_" as a prefix for cookies (such

as ad_login, ad_session_id, ...). In certain situations this can lead

to confusion, since cookies are managed by browsers via domain names,

and running multiple OpenACS instances in the same domain will cause

overwriting of such cookies by these instances. The can happen e.g.

when running multiple instances on the same machine, or using

port-forwarding to virtual machines/containers, using reverse proxies,

etc. Note that the cookie overwriting problem does not exist for

host-node-mapped subsites, since host-node-mapping depends on domain

names.

One could consider using the port in the cookie name (as

sometimes noted as an option), but this would not work, in case the

same server should be reachable over multiple ports.

Therefore, one can now specify a "CookieNamespace" in the OpenACS

configuration file, which is per default "ad_", which is sufficient

for the majority of installations. In cases, where it is needed, a

different CookieNamespace can now be configured.

To manage the cookie names internally, OpenACS provides a new API call

security::cookie_name to derive the namespaced cookie name from a stem.

Snippet of the OpenACS configuration file for setting the CookieNamespace

#---------------------------------------------------------------------

# OpenACS specific settings (per server)

#---------------------------------------------------------------------

ns_section ns/server/${server}/acs {

ns_param CookieNamespace "ad_"

...

}

  1. … 2 more files in changeset.
check that provided signature is a list, otherwise lassign will fail afterwards

improve spelling

  1. … 2 more files in changeset.
improve comment

align to the usual naming convention (use "_not_cached" suffix)

added comments and portlets locations for default ports

security::locations: return configured servers from the driver/servers section

additionally, improve caching

  1. … 1 more file in changeset.
improve spelling

added support for SCRYPT (RFC 7914) as password hash function.

The use of scrypt requires NaviServer compiled with OpenSSL 3.0 or newer

  1. … 1 more file in changeset.
stick to the original names with the "-" since this is also the naming convention outside of OpenACS (e.g. "scram-sha-256")

  1. … 7 more files in changeset.
Complete reform introduced in https://cvs.openacs.org/changelog/OpenACS?cs=oacs-5-10%3Agustafn%3A20210928124647

- add datamodel change to the creation script

- refactor algorithm names in a way that the new procs will comply with acs-tcl.naming__proc_naming automated test

  1. … 6 more files in changeset.
Stronger password hashes for OpenACS

This change introduces the possibility to use either the classical

OpenACS password hash algorithm "salted-sha1" or the SCRAM passord

function "scram-sha-256". The latter can be used by (a) using the

most recent version of NaviServer (from Sept 28, 2021 or newer) and

(b) by configuring the password hash preferences via Kernel package

parameter "PasswordHashAlgorithm". The package parameter can contain a

list of multiple hash algorithms in preference order. The most

preferred available algorithm is chosen.

By default, the "PasswordHashAlgorithm" is "salted-sha1", and the

behavior is as before. After upgrading to the new version of acs-tcl

and acs-kernel, the preference list can be configured. When a user

logs in and the preferred available algorithm is different from the

previously used algorithm, the upgrade is performed for the user

automatically.

The usage of SHA1 in OpenACS is easily target of security audits (see

[1]). The biggest danger is that if somebody gets full access to the

"users" table (e.g. when decommissioning a hard disk). In this case

the hashes can be attacked with dictionaries by using some crypto

hardware (when someone gets raw access to the DB, one has usually some

other big problems). However, by using the "scram-sha-256" hash

function this danger is substantially reduced. This function computes

a password hash using PBKDF2 (Password-Based Key Derivation Function

2). This function is used to reduce vulnerabilities of brute-force

attacks against password hashes. The hash function of SCRAM is PBKDF2

[RFC2898] with HMAC as the pseudorandom function (PRF) and with dkLen

== output length of HMAC == output length of the digest function. So,

it uses a better hash algorithm (sha-256 vs. sha1) and applies this a

high number of times (15K times for a password hash computation).

NaviServer supports as well the even better SCRYPT algorithm, but this

is only available when NaviServer is compiled with OpenSSL 3.0 or

newer. On the contrary, scram-sha-256 (actually PKCS5_PBKDF2_HMAC) is

available since OpenSSL 1.0.0 (2015).

All the improved hash functions require NaviServer with its tight

integration to the crypto functions of OpenSSL.

[1] https://openacs.org/forums/message-view?message_id=5522562

  1. … 6 more files in changeset.
Mark 'sec_get_random_cached_token_id' as public, as it is used in 'acs-subsite'

Improve robustness over invalid configurations

Previouly, the configuration of invalid hostnames (i.e. hostnames,

which cannot be resolved via the OS means) for a network driver

lead to runtime errors under certain conditions.

Make api public, complies with acs-api-browser.graph__bad_calls automated test

  1. … 2 more files in changeset.
remove protection "private", since function has to be called from other packages

  1. … 6 more files in changeset.
mark functions called only internally as private

  1. … 15 more files in changeset.
improve comment

avoid array notation for per_thread caches to ease flushing

  1. … 5 more files in changeset.
make call more robust in case "location" is not provided via config file

use 'self' for "security::csp::require object-src" instead of 'none' since the latter is non-incremental

Fix acs-tcl.logout_from_everywhere test case and support again invalidating of all existing user logins, useful e.g. to make sure no device still holds a valid login when we change our password on a device

Don't rely on configured "location" value of driver, since this does not work for virtual hosting

Instead, get the "host", "port" and "defaultport" directly from "ns_driver info" when available