Server Security and Auditing

Session management

Sessions are stored on the server in Posit Package Manager. Package Manager generates a cryptographically secure identifier for each session, which is stored in the ppm cookie. The cookie is HttpOnly by default (ensuring that it cannot be accessed by JavaScript), and uses the Secure attribute if Package Manager is configured to require HTTPS.

When signing into Posit Package Manager, a browser cookie is used to keep the user logged in. See the Limiting Session Lifetime section for details about the default session lifetime and how to change it.

The server periodically checks the data store for expired cookies and removes them. This happens once per hour by default, but is configurable using the Authentication.CookieSweepDuration configuration setting. This does not affect the lifetime of web sessions, which is controlled by the Authentication.Lifetime configuration setting.

Browser Security

There are a variety of security settings that can be configured in Posit Package Manager. Some of these settings are enabled by default but can be customized, while others are opt-in. Below are some of the security features worth considering.

Limiting session lifetime

The default Posit Package Manager configuration enforces the following limits on authenticated sessions:

  1. Sessions are invalidated after 72 hours, regardless of activity.
  2. Inactive sessions are considered idle and invalidated after 24 hours.

Once a session is considered invalid, the user needs to reauthenticate before continuing to interact with Posit Package Manager.

The session lifetime and inactive threshold are configurable settings. Adjust the maximum session lifetime by changing the Authentication.Lifetime setting. Session inactivity is controlled with the Authentication.Inactivity setting.

Configure these session settings according to your organization’s security policies.

Our first configuration example has shorter thresholds than the configured defaults. Users need to reauthenticate after being idle for 30 minutes or after their session lasts for 12 hours. The 30 minute inactivity limit means that sessions may be idle “no longer than a lunch break.”

/etc/rstudio-pm/rstudio-pm.gcfg
[Authentication]
Lifetime = 12h
Inactivity = 30m

This second configuration example has longer thresholds than our configured defaults. Users need to reauthenticate once a week, or after being inactive for 2 days. Adopt this type of configuration with care; your organization may want users to reauthenticate more frequently.

/etc/rstudio-pm/rstudio-pm.gcfg
[Authentication]
Lifetime = 7d
Inactivity = 2d

Posit Package Manager uses session cookies to track and enforce both the session lifetime and inactive threshold.

Guaranteeing HTTPS

If you can guarantee that your server should only ever be accessed over a TLS/SSL connection (HTTPS), then you can consider enabling the HTTPS.Permanent setting. This elevates the security of your server by requiring that future interactions between your users and this server must be encrypted.

For more information on using SSL Certificates with Package Manager, see the Configuring SSL Certificates in Posit Package Manager section.

Note

Enabling this setting may prevent users from being able to access your Package Manager instance if you later disable HTTPS or if your certificate expires. Only use this setting if you will permanently provide a valid TLS/SSL certificate on this server.

Behind the scenes, this setting makes two changes:

  1. Introduces HTTP Strict Transport Security (HSTS) by adding a Strict-Transport-Security HTTP header with a max-age set to 30 days. HSTS ensures that your users’ browsers will not trust a service hosted at this location unless it is protected with a trusted TLS/SSL certificate.
  2. Enforces the Secure flag on cookies that are set. This prohibits your users’ browsers from sending their Package Manager cookies to a server without an HTTPS-secured connection.

Strong HTTPS

You can constrain the TLS version used by HTTPS. This may help you meet the security policy for your organization.

The HTTPS.MinimumTLS setting specifies the minimum TLS version. Clients using a lower TLS version will be rejected. The default minimum TLS version is TLS 1.1. You can configure this setting to 1.0, 1.1, 1.2, or 1.3.

We recommend that you check that the browsers and clients used within your organization are compatible with your minimum TLS version choice. The SSL Labs User Agent List enumerates the TLS capabilities for most popular browsers.

Here is an HTTPS configuration permitting TLS versions 1.2 and above:

/etc/rstudio-pm/rstudio-pm.gcfg
[HTTPS]
Listen = 443
MinimumTLS = 1.2

We recommend using a secure proxy if you need finer control over HTTPS.

Using a Secure Proxy

If you would prefer that the Package Manager process not have access to your TLS/SSL certificates, you may wish to configure a proxy to handle HTTPS requests. To accomplish this:

  • Ensure that your Server.Address is set to the proxy address and uses the https scheme.

  • Set HTTP.ForceSecure to true, which sets the Secure flag on all cookies.

  • Set HTTP.NoWarning to true to suppress the warning regarding running Posit Package Manager over an unsecured connection, because the connection between the client and the proxy is secured.

  • If necessary, enable the HttpRedirect.Listen option to redirect proxied plain HTTP connections to HTTPS.

Note

Since the connection between the proxy and Package Manager is not secured in this case, please ensure that the proxy and Package Manager are connecting on a trusted network, where an adversary would not be able to capture plain-text credentials. For example, many cloud providers allow isolating servers from the internet while permitting load balancers to access them. Please see your cloud provider’s documentation for more details.

Content Sniffing

The Server.ContentTypeSniffing setting can be used to configure the X-Content-Type-Options HTTP header. This protects your users from a certain class of malicious uploads and is enabled by default.

When disabled (the default), the X-Content-Type-Options HTTP header will be set to a value of nosniff to tell browsers not to sniff the content type. If enabled, no such header will be provided.

Content Embedding

The X-Frame-Options HTTP header is used to control what content can be embedded inside other content in a web browser. The relevant attack is commonly referred to as a “clickjack attack” and involves users interacting with a sensitive service without their knowledge.

Note

Some advertised values for this header are not supported across all browsers. Package Manager does not restrict the values of these headers.

SameSite cookies

Posit Package Manager returns cookies with the attribute SameSite=Lax by default. This provides some protection against cross-site request forgery (CSRF) attacks.

The SameSite attribute can also be omitted or set to None by configuring the Server.SameSite setting.

Custom Headers

If you need to include additional HTTP headers that are not covered by any of the above features, you can include your own custom headers on all responses from Package Manager using the Server.CustomHeader setting.

This feature can be used to accommodate various other security practices that are not explicitly available as options elsewhere in Package Manager. For instance, X-XSS-Protection, Content Security Policy (CSP), HTTP Public Key Pinning (HPKP), and Cross-origin Resource Sharing (CORS) could all be configured using custom headers.

Note

Custom headers are added to the HTTP response early during request processing. Values may be overwritten later, or modified by other header settings. This includes both the security preferences described earlier in this section and other headers used internally by Package Manager. You should not depend on a custom header that conflicts with a header already in use by Package Manager.

The Server.CustomHeader takes a value of the header name and its value separated by a colon. Whitespace surrounding the header name and its value are trimmed. You can use this setting multiple times as in the following example:

/etc/rstudio-pm/rstudio-pm.gcfg
[Server]
CustomHeader = “HeaderA: some value”
CustomHeader = “HeaderB: another value”

CSRF cookies

Cross-Site Request Forgery (often abbreviated as CSRF or XSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated.

Note

References:

How does Package Manager mitigate CSRF attacks?

Posit Package Manager uses a common mitigation strategy referred to as “Cookie-to-header” token validation.

In order to mitigate CSRF attacks, upon an initial user session, the Package Manager server creates a cookie (PPM-XSRF) containing a cryptographically secure, random token. JavaScript operating on the client side reads the value from this secure cookie and copies it into a custom HTTP header (X-Ppm-Xsrf) sent with each transactional request. The server validates the presence and integrity of the token by comparing the request header with the cookie. An attacker cannot perform the CSRF attack without the header which is made unavailable by TLS.

Important

The PPM-XSRF cookie cannot be set as “http-only” as it is required that JavaScript is able to read the cookie value in order to set the request header.

Not setting “http-only” is not specific to Package Manager, but is a universal requirement for using “cookie-to-header” mitigation. This technique is implemented by many modern frameworks, such as Django and Angular.

Package Security

For information on package level security, see Package Security.

Back to top