Without assertions, a unit test doesn’t actually verify anything, making it ineffective in catching potential bugs or regressions. It will always pass, regardless of the implementation of the unit. This can lead to a false sense of security, as you may believe that your code is working correctly when it might not be.
-This rule raises an issue when the assertion library chai is imported but no assertion is used in a test.
This rule raises an issue when the assertion library chai or sinon is imported but no assertion is used in a test.
const expect = require("chai").expect;
@@ -34,5 +34,6 @@ Resources
Documentation
diff --git a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5689.html b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5689.html
index 179252fa8c7..e7795762869 100644
--- a/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5689.html
+++ b/sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S5689.html
@@ -1,36 +1,50 @@
-Disclosing technology fingerprints allows an attacker to gather information about the technologies used to develop the web application and to -perform relevant security assessments more quickly (like the identification of known vulnerable components).
+Disclosure of version information, usually overlooked by developers but disclosed by default by the systems and frameworks in use, can pose a +significant security risk depending on the production environement.
+Once this information is public, attackers can use it to identify potential security holes or vulnerabilities specific to that version.
+Furthermore, if the published version information indicates the use of outdated or unsupported software, it becomes easier for attackers to exploit +known vulnerabilities. They can search for published vulnerabilities related to that version and launch attacks that specifically target those +vulnerabilities.
x-powered-by HTTP header or similar is used by the application. There is a risk if you answered yes to any of these questions.
It’s recommended to not disclose technologies used on a website, with x-powered-by HTTP header for example.
In addition, it’s better to completely disable this HTTP header rather than setting it a random value.
+In general, it is recommended to keep internal technical information within internal systems to control what attackers know about the underlying +architectures. This is known as the "need to know" principle.
+The most effective solution is to remove version information disclosure from what end users can see, such as the "x-powered-by" header.
This
+can be achieved directly through the web application code, server (nginx, apache) or firewalls.
Disabling the server signature provides additional protection by reducing the amount of information available to attackers. Note, however, that
+this does not provide as much protection as regular updates and patches.
Security by obscurity is the least foolproof solution of all. It should
+never be the only defense mechanism and should always be combined with other security measures.
Express.js name is disclosed by default into the x-powered-by HTTP header:
In Express.js, version information is disclosed by default in the x-powered-by
+HTTP header:
let express = require('express');
-let app = express(); // Sensitive
-app.get('/', function (req, res) {
- res.send('hello')
+let example = express(); // Sensitive
+
+example.get('/', function (req, res) {
+ res.send('example')
});
x-powered-by HTTP header should be disabled in Express.js with
-app.disable or with helmet hidePoweredBy middleware:
app.disable:
let express = require('express');
-let app1 = express(); // Compliant
-app1.disable("x-powered-by");
-
+let example = express();
+example.disable("x-powered-by");
+
+Or with helmet’s hidePoweredBy middleware:
+
let helmet = require("helmet");
-let app2 = express(); // Compliant
-app2.use(helmet.hidePoweredBy());
+
+let example = express();
+example.use(helmet.hidePoweredBy());
An attacker may trick a user into using a predetermined session identifier. Consequently, this attacker can gain unauthorized access and +impersonate the user’s session. This kind of attack is called session fixation, and protections against it should not be disabled.
Session fixation attacks occur when an attacker can force a legitimate user to use a session ID that he knows. To avoid fixation attacks, it’s a -good practice to generate a new session each time a user authenticates and delete/invalidate the existing session (the one possibly known by the -attacker).
-For Passport.js:
-+Session fixation attacks take advantage of the way web applications manage session identifiers. Here’s how a session fixation attack typically +works:
+
Session fixation attacks pose a significant security risk to web applications and their users. By exploiting this vulnerability, attackers can gain +unauthorized access to user sessions, potentially leading to various malicious activities. Some of the most relevant scenarios are the following:
+Once an attacker successfully fixes a session identifier, they can impersonate the victim and gain access to their account without providing valid +credentials. This can result in unauthorized actions, such as modifying personal information, making unauthorized transactions, or even performing +malicious activities on behalf of the victim. An attacker can also manipulate the victim into performing actions they wouldn’t normally do, such as +revealing sensitive information or conducting financial transactions on the attacker’s behalf.
+If an attacker gains access to a user’s session, they may also gain access to sensitive data associated with that session. This can include +personal information, financial details, or any other confidential data that the user has access to within the application. The compromised data can +be used for identity theft, financial fraud, or other malicious purposes.
+In some cases, session fixation attacks can be used to escalate privileges within a web application. By fixing a session identifier with higher +privileges, an attacker can bypass access controls and gain administrative or privileged access to the application. This can lead to unauthorized +modifications, data manipulation, or even complete compromise of the application and its underlying systems.
+Upon user authentication, it is crucial to regenerate the session identifier to prevent fixation attacks. Passport provides a mechanism to achieve
+this by using the req.session.regenerate() method. By calling this method after successful authentication, you can ensure that each user
+is assigned a new and unique session ID.
app.post('/login',
passport.authenticate('local', { failureRedirect: '/login' }),
function(req, res) {
- // Sensitive - no session.regenerate after login
+ // Noncompliant - no session.regenerate after login
res.redirect('/');
});
-For Passport.js:
-+Compliant solution
+app.post('/login', passport.authenticate('local', { failureRedirect: '/login' }), function(req, res) { let prevSession = req.session; - req.session.regenerate((err) => { // Compliant + req.session.regenerate((err) => { Object.assign(req.session, prevSession); res.redirect('/'); }); });+How does this work?
+The protection works by ensuring that the session identifier, which is used to identify and track a user’s session, is changed or regenerated +during the authentication process.
+Here’s how session fixation protection typically works:
++
+- When a user visits a website or logs in, a session is created for them. This session is assigned a unique session identifier, which is stored + in a cookie or passed through URL parameters.
+- In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. This allows + the attacker to potentially gain unauthorized access to the user’s session.
+- To protect against session fixation attacks, session fixation protection mechanisms come into play during the authentication process. When a + user successfully authenticates, this mechanism generates a new session identifier for the user’s session.
+- The old session identifier, which may have been manipulated by the attacker, is invalidated and no longer associated with the user’s session. + This ensures that any attempts by the attacker to use the fixed session identifier are rendered ineffective.
+- The user is then assigned the new session identifier, which is used for subsequent requests and session tracking. This new session identifier + is typically stored in a new session cookie or passed through URL parameters.
+By regenerating the session identifier upon authentication, session fixation protection helps ensure that the user’s session is tied to a new, +secure identifier that the attacker cannot predict or control. This mitigates the risk of an attacker gaining unauthorized access to the user’s +session and helps maintain the integrity and security of the application’s session management process.
Resources
+Documentation
+
Within IAM, identity-based policies grant permissions to users, groups, or roles, and enable specific actions to be performed on designated +resources. When an identity policy inadvertently grants more privileges than intended, certain users or roles might be able to perform more actions +than expected. This can lead to potential security risks, as it enables malicious users to escalate their privileges from a lower level to a higher +level of access.
AWS Identity and Access Management (IAM) is the service that defines access to AWS resources. One of the core components of IAM is the policy -which, when attached to an identity or a resource, defines its permissions. Policies granting permission to an Identity (a User, a Group or Role) are -called identity-based policies. They add the ability to an identity to perform a predefined set of actions on a list of resources.
-Here is an example of a policy document defining a limited set of permission that grants a user the ability to manage his own access keys.
-
-{
- "Version": "2012-10-17",
- "Statement": [
- {
- "Action": [
- "iam:CreateAccessKey",
- "iam:DeleteAccessKey",
- "iam:ListAccessKeys",
- "iam:UpdateAccessKey"
- ],
- "Resource": "arn:aws:iam::245500951992:user/${aws:username}",
- "Effect": "Allow",
- "Sid": "AllowManageOwnAccessKeys"
- }
- ]
-}
-
-Privilege escalation generally happens when an identity policy gives an identity the ability to grant more privileges than the ones it already has. -Here is another example of a policy document that hides a privilege escalation. It allows an identity to generate a new access key for any user from -the account, including users with high privileges.
-
-{
- "Version": "2012-10-17",
- "Statement": [
- {
- "Action": [
- "iam:CreateAccessKey",
- "iam:DeleteAccessKey",
- "iam:ListAccessKeys",
- "iam:UpdateAccessKey"
- ],
- "Resource": "*",
- "Effect": "Allow",
- "Sid": "AllowManageOwnAccessKeys"
- }
- ]
-}
-
-Although it looks like it grants a limited set of permissions, this policy would, in practice, give the highest privileges to the identity it’s -attached to.
-Privilege escalation is a serious issue as it allows a malicious user to easily escalate to a high privilege identity from a low privilege identity -it took control of.
-The example above is just one of many permission escalation vectors. Here is the list of vectors that the rule can detect:
-| Vector name | -Summary | -
|---|---|
Create Policy Version |
- Create a new IAM policy and set it as default |
-
Set Default Policy Version |
- Set a different IAM policy version as default |
-
Create AccessKey |
- Create a new access key for any user |
-
Create Login Profile |
- Create a login profile with a password chosen by the attacker |
-
Update Login Profile |
- Update the existing password with one chosen by the attacker |
-
Attach User Policy |
- Attach a permissive IAM policy like "AdministratorAccess" to a user the attacker controls |
-
Attach Group Policy |
- Attach a permissive IAM policy like "AdministratorAccess" to a group containing a user the attacker controls |
-
Attach Role Policy |
- Attach a permissive IAM policy like "AdministratorAccess" to a role that can be assumed by the user the attacker controls |
-
Put User Policy |
- Alter the existing inline IAM policy from a user the attacker controls |
-
Put Group Policy |
- Alter the existing inline IAM policy from a group containing a user that the attacker controls |
-
Put Role Policy |
- Alter an existing inline IAM role policy. The rule will then be assumed by the user that the attacker controls |
-
Add User to Group |
- Add a user that the attacker controls to a group that has a larger range of permissions |
-
Update Assume Role Policy |
- Update a role’s "AssumeRolePolicyDocument" to allow a user the attacker controls to assume it |
-
EC2 |
- Create an EC2 instance that will execute with high privileges |
-
Lambda Create and Invoke |
- Create a Lambda function that will execute with high privileges and invoke it |
-
Lambda Create and Add Permission |
- Create a Lambda function that will execute with high privileges and grant permission to invoke it to a user or a service |
-
Lambda triggered with an external event |
- Create a Lambda function that will execute with high privileges and link it to an external event |
-
Update Lambda code |
- Update the code of a Lambda function executing with high privileges |
-
CloudFormation |
- Create a CloudFormation stack that will execute with high privileges |
-
Data Pipeline |
- Create a Pipeline that will execute with high privileges |
-
Glue Development Endpoint |
- Create a Glue Development Endpoint that will execute with high privileges |
-
Update Glue Dev Endpoint |
- Update the associated SSH key for the Glue endpoint |
-
The general recommendation to protect against privilege escalation is to restrict the resources to which sensitive permissions are granted. The -first example above is a good demonstration of sensitive permissions being used with a narrow scope of resources and where no privilege escalation is -possible.
-The following policy allows an attacker to update the code of any Lambda function. An attacker can achieve privilege escalation by altering the -code of a Lambda that executes with high privileges.
-
-import {aws_iam as iam} from 'aws-cdk-lib'
+which, when attached to an identity or a resource, defines its permissions. Policies granting permission to an identity (a user, a group or a role)
+are called identity-based policies. They add the ability to an identity to perform a predefined set of actions on a list of resources.
+For such policies, it is easy to define very broad permissions (by using wildcard "*" permissions for example.) This is especially
+true if it is not yet clear which permissions will be required for a specific workload or use case. However, it is important to limit the amount of
+permissions that are granted and the amount of resources to which these permissions are granted. Doing so ensures that there are no users or roles
+that have more permissions than they need.
+If this is not done, it can potentially carry security risks in the case that an attacker gets access to one of these identities.
+What is the potential impact?
+AWS IAM policies that contain overly broad permissions can lead to privilege escalation by granting users more access than necessary. They may be
+able to perform actions beyond their intended scope.
+Privilege escalation
+When IAM policies are too permissive, they grant users more privileges than necessary, allowing them to perform actions that they should not be
+able to. This can be exploited by attackers to gain unauthorized access to sensitive resources and perform malicious activities.
+For example, if an IAM policy grants a user unrestricted access to all S3 buckets in an AWS account, the user can potentially read, write, and
+delete any object within those buckets. If an attacker gains access to this user’s credentials, they can exploit this overly permissive policy to
+exfiltrate sensitive data, modify or delete critical files, or even launch further attacks within the AWS environment. This can have severe
+consequences, such as data breaches, service disruptions, or unauthorized access to other resources within the AWS account.
+How to fix it in AWS CDK
+Code examples
+In this example, the IAM policy allows an attacker to update the code of any Lambda function. An attacker can achieve privilege escalation by
+altering the code of a Lambda that executes with high privileges.
+Noncompliant code example
+
+import { aws_iam as iam } from 'aws-cdk-lib'
new iam.PolicyDocument({
statements: [new iam.PolicyStatement({
@@ -164,26 +35,42 @@ Noncompliant code example
actions: ["lambda:UpdateFunctionCode"],
resources: ["*"], // Noncompliant
})],
-})
+});
-Compliant solution
-Narrow the policy such that only updates to the code of certain Lambda functions are allowed.
-
-import {aws_iam as iam} from 'aws-cdk-lib'
+Compliant solution
+The policy is narrowed such that only updates to the code of certain Lambda functions (without high privileges) are allowed.
+
+import { aws_iam as iam } from 'aws-cdk-lib'
new iam.PolicyDocument({
statements: [new iam.PolicyStatement({
effect: iam.Effect.ALLOW,
actions: ["lambda:UpdateFunctionCode"],
- resources: ["arn:aws:lambda:us-east-2:123456789012:function:my-function:1"], // Noncompliant
+ resources: ["arn:aws:lambda:us-east-2:123456789012:function:my-function:1"],
})],
-})
+});
+How does this work?
+Principle of least privilege
+When creating IAM policies, it is important to adhere to the principle of least privilege. This means that any user or role should only be granted
+enough permissions to perform the tasks that they are supposed to, and nothing else.
+To successfully implement this, it is easier to start from nothing and gradually build up all the needed permissions. When starting from a policy
+with overly broad permissions which is made stricter at a later time, it can be harder to ensure that there are no gaps that might be forgotten about.
+In this case, it might be useful to monitor the users or roles to verify which permissions are used.
Resources
+Documentation
+