• last updated 10 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Consider failures obtaining the token as failure to verify the value and report into the log file

reduce verbosity

improve spelling

  1. … 9 more files in changeset.
Make use of new API "ad_mktmpdir" and "ad_opentmpfile" instead of "ad_tmpnam"

  1. … 7 more files in changeset.
Minor CSP improvements

- provided ability to add "trusted-types" and "require-trusted-types-for"

directives (Trusted Types policies)

For details, see:

https://blog.bitsrc.io/trusted-types-api-for-javascript-dom-security-fcdafa927e73

- changed default "object-src" from 'self' to 'none'

improve Oracle compatibility

Document public api

improve spelling

  1. … 6 more files in changeset.
tmpfile page contract filter reform:

do not allow acs-subsite TmpDir parameter to define where the tmpfolder is located anymore. This MUST be the one configured in the server-wide configuration. Tmpfiles cannot be in a subfolder of the tmpfolder, they MUST be direct children instead. A tmpfile MUST exist beforehand and be owned, be readable and writable by the user running the nsd process. This complies with the definition of a tmpfile by AolServer/NaviServer when they are created to store content coming from a file upload.

  1. … 4 more files in changeset.
Reimplement ad_page_contract_filter_proc_tmpfile using security::safe_tmpfile_p

Some of the features implemented by this filter have been ported into the api, namely the possibility to fetch the valid temp folders from the subsite TmpDir parameter and the possibility to relax the check and allow also files deeper in the tmpfolder hierachy.

Notably, the hardcoded tmpfolders "/var/tmp" and "/tmp" have NOT been ported. One should configure these values via the many available options. security::safe_tmpfile_p is also more restrictive when a file exists, because it checks for ownership and read and write permissions on the file.

  1. … 2 more files in changeset.
Add must_exist flag to enforce a safe tmpfile to already exist

  1. … 2 more files in changeset.
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.