Executive Summary

This vulnerability in Boruta, an authorization server implementing OAuth 2.0 and OpenID Connect, involves session cookies and identity "remember me" cookies being set without the Secure attribute prior to version 0.9.1.

Without the Secure attribute, these cookies could be transmitted over unencrypted HTTP connections if users accessed Boruta via plaintext HTTP. This allows an attacker who can observe or intercept network traffic to capture valid session or remember-me cookies.

An attacker could then reuse these cookies to impersonate the affected user, potentially gaining unauthorized access.

The issue affects components boruta_web, boruta_identity, and boruta_admin, and was fixed by enforcing the Secure attribute and setting SameSite to "Lax" on cookies in version 0.9.1.

Useful 0 Not Useful 0

Impact Analysis

If you use Boruta versions prior to 0.9.1 and allow users to access it over plaintext HTTP, attackers could intercept session and remember-me cookies.

This interception can lead to session hijacking, where attackers impersonate legitimate users, including administrators, gaining unauthorized access to sensitive resources.

Such unauthorized access can compromise user accounts, data confidentiality, and the integrity of your authentication system.

To mitigate this risk before upgrading, it is recommended to enforce HTTPS-only access, enable HSTS, or terminate plaintext HTTP traffic before it reaches Boruta.

Useful 0 Not Useful 0

Detection Guidance

To detect this vulnerability, verify if Boruta session and remember-me cookies are set without the Secure attribute, which means they could be transmitted over unencrypted HTTP connections.

You can inspect HTTP response headers or browser cookies to check if the Secure attribute is missing.

For example, use curl to inspect the Set-Cookie headers from the Boruta server responses:

• curl -I http://your-boruta-domain/path | grep Set-Cookie

Look for cookies named _boruta_web_key or _boruta_identity_web_user_remember_me and check if the Secure flag is present.

Alternatively, use browser developer tools (Network tab) to inspect cookies and confirm whether the Secure attribute is set.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps before upgrading include:

• Terminate or reject plaintext HTTP traffic before it reaches the Boruta server.
• Enforce HTTPS-only access at the reverse proxy or load balancer.
• Enable HTTP Strict Transport Security (HSTS) for Boruta domains to ensure browsers only connect over HTTPS.
• If cookie exposure is suspected, rotate SECRET_KEY_BASE and BORUTA_SESSION_COOKIE_SIGNING_SALT, then require users to re-authenticate.

Ultimately, upgrade Boruta to version 0.9.1 or later, which includes the fix that sets the Secure and SameSite attributes on session cookies.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability involves session and identity cookies being transmitted without the Secure attribute, allowing potential interception over unencrypted HTTP connections. Such exposure of authentication tokens can lead to unauthorized access and user impersonation.

From a compliance perspective, this weakness could negatively impact adherence to common standards and regulations like GDPR and HIPAA, which require protection of personal data and secure authentication mechanisms to prevent unauthorized access.

Failure to secure session cookies properly may result in breaches of confidentiality and integrity of user data, potentially leading to violations of data protection requirements and increased risk of regulatory penalties.

Mitigations such as enforcing HTTPS-only access, enabling HSTS, and applying the patch to set Secure and SameSite cookie attributes help align the system with security best practices expected by these standards.

Useful 0 Not Useful 0