The web application should specify a session identifier length of at least 128 bits long. If attackers can guess an authenticated user's session identifier, they can take over the user's session, which enables them to launch impersonation attacks against the application.

A class annotated with @SessionAttributes will mean Spring replicates changes to model attributes in the session object. If an attacker is able to store arbitrary values within a model attribute, these changes will be replicated in the session object where they may be trusted by the application. If the session attribute is initialized with trusted data which the user should not be able to modify, the attacker may be able to conduct a Session Puzzling attack and abuse the application logic.

Example 1: The following controller contains a method which loads the user data into the session upon a successful login.

@Controller
@SessionAttributes("user")
public class HomeController {
    ...
    @RequestMapping(value= "/auth", method=RequestMethod.POST)
    public String authHandler(@RequestParam String username, @RequestParam String password, RedirectAttributes attributes, Model model) {
        User user = userService.findByNamePassword(username, password);
        if (user == null) {
            // Handle error
            ...
        } else {
            // Handle success
            attributes.addFlashAttribute("user", user);
            return "redirect:home";
        }
    }
    ...
}

A different controller handles the reset password feature. It tries to load the User instance from the session since the class is annotated with @SessionAttributes("user") and uses it to verify the reset password question.

@Controller
@SessionAttributes("user")
public class ResetPasswordController {

    @RequestMapping(value = "/resetQuestion", method = RequestMethod.POST)
    public String resetQuestionHandler(@RequestParam String answerReset, SessionStatus status, User user, Model model) {

        if (!user.getAnswer().equals(answerReset)) {
            // Handle error
            ...
        } else {
            // Handle success
            ...
        }
    }
}

The developer's intention was to load the user instance from the session where it was stored during the login process. However Spring will check the request and will try to bind its data into the model user instance. If the received request contains data that can be bound to the User class, Spring will merge the received data into the user session attribute. This scenario can be abused by submitting both an arbitrary answer in the answerReset query parameter and the same value to override the value stored in the session. This way, the attacker may set an arbitrary new password for random users.

Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.



Because setting manipulation covers a diverse set of functions, any attempt to illustrate it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Example 1: The following Java code snippet reads a string from an HttpServletRequest and sets it as the active catalog for a database Connection.

...
conn.setCatalog(request.getParamter("catalog"));
...

In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of your attacker.

Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Allowing a user to control the character encoding used to parse the HTTP response of a given request can allow an attacker to evade certain validation mechanisms used for Cross-site Scripting.
The response character encoding is used by a web browser to decide how to interpret the characters in the body of the HTTP response. The most common encoding used by web applications today is UTF-8. The character set (charset) declaration is usually done through a header in the HTTP response or using the HTML <meta> tag. Only the application should control these declarations. If this declaration is controlled through user input, then an attacker can use this feature to modify the charset that the browser uses and modify the interpretation of the contents of the response. This can enable Cross-site Scripting attacks that would otherwise not have succeeded while using UTF-8 encoding.


Example 1:

+ADw-script+AD4-alert(document.location)+ADw-/script+AD4

The previous string means nothing in most encoding types, and therefore is "safe", but when a victim views this under utf-7 encoding, it is interpreted as valid HTML tag and, the script is executed.

Frameworks often have allow lists for validation to protect against vulnerabilities.

Example 1: The following allows a malicious user to set the allow list that is used by AngularJS to determine what types of links images can retrieve.

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(userInput);
});

This may seem fine, but if the user sets the regular expression to /^(http(s)?|javascript):.*/, the application will then allow the use of inline JavaScript within image source URLs, which may lead to cross-site scripting attacks.
Other instances of allow lists may be preventing all different types of attacks, especially injection attacks such as cross-site scripting, command injection, SQL injection, along with business logic flaws.

If users are allowed to control the action for processing an approval request, a malicious user can potentially reject legitimate requests or approve fraudulent ones, leading to data corruption, denial of service, or privilege escalation.

Example 1: The following code allows external user input to control the approval action in a ProcessWorkitemRequest.setAction() call.

void processRequest() {
  String workItemId = ApexPages.currentPage().getParameters().get('Id');
  String action = ApexPages.currentPage().getParameters().get('Action');

  Approval.ProcessWorkitemRequest req = new Approval.ProcessWorkitemRequest();
  req.setWorkitemId(workItemId);
  req.setAction(action);

  Approval.ProcessResult res =  Approval.process(req);
  ...
}

One way an attacker could exploit this code is by initially submitting an approval request to modify the roles or access permissions associated with their account. They could then tamper with the query parameters to ensure their request gets improperly approved, potentially resulting in unauthorized privilege escalation.

When you allow users to define the delimiters used by templating engines it means that protections that were previously implemented may no longer work, or may be invalid. In the most benign version of this, it may lead to functionality not working as expected or leaking information, but this also may allow malicious users to get around protections in the engine that lead to cross-site scripting vulnerabilities.

Example 1: In the following code an AngularJS module is configured to use a start symbol defined from the hash inside the URL.

var hash = window.location.hash;
var myStartSymbol = decodeURIComponent(hash.substring(1, hash.length));

myModule.config(function($interpolateProvider){
    $interpolateProvider.startSymbol(myStartSymbol);
});

This is usually done to enable multiple template engines to work together, which in itself is extremely dangerous [1], but this may lead to engines being run which may not be compatible with AngularJS expressions, potentially leading to users being able to bypass regular validation and run their own code within the browser.

By default, Silverlight applications are subject to the Same-Origin Policy which ensures that a Silverlight application can access data on a service only if they come from the same domain. Silverlight allows developers to alter the policy via appropriate settings in the clientaccesspolicy.xml configuration file on the host. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious applications to communicate with the victim service in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following configuration shows clientaccesspolicy.xml using a wildcard to specify with which domains the service is allowed to communicate.

<allow-from http-request-headers="*">
	<domain uri="*"/>
</allow-from>

Using the * as the value of the domain element's uri attribute indicates that applications on any domain can connect to the service.

When developing a Solidity smart contract, developers can set the access modifier of a function to control who can invoke it. If a developer does not specify an access modifier, the function defaults to public, allowing a malicious actor to call the function without authorization.

Example 1: The following code fails to set the access modifier in both functions and therefore anyone can invoke them, allowing a user to bypass the call to require.

function withdrawWinnings() {
    require(uint32(msg.sender) == 0);
    _sendWinnings();
}

function _sendWinnings() {
    msg.sender.transfer(this.balance);
}

Assuming the contract has a specific Ether balance can lead to erroneous or unexpected behavior because the balance of a contract can be forcibly altered, for example by sending Ether to the contract.

Example 1: The following code uses an assert to check that the balance of the Lock contract instance is a specific value (msg.value).

contract Lock {
    constructor (address owner, uint256 unlockTime) public payable {
        ...
    }
}

contract Lockdrop {
    ...
    function lock(...) {
        uint256 eth = msg.value;
        address owner = msg.sender;
        uint256 unlockTime = unlockTimeForTerm(term);

        Lock lockAddr = (new Lock).value(eth)(owner, unlockTime);

        assert(address(lockAddr).balance == msg.value);
    }
}

The transaction cost in terms of gas can vary based on current network conditions, for example, the gas cost of EVM (Ethereum Virtual Machine) instructions during a hard fork might significantly be affected. This can break existing functionality that relies on fixed amounts of gas or can affect transactions utilized for value transfer such as transfer() and send(), which use a fixed amount of 2300 gas.

Example 1: The following code carries out a call and specifies a fixed amount of gas.

interface ICallable {
    function callMe() external;
}

contract HardcodedNotGood {
    function callWithArgs() public {
        callable.callMe{gas: 10000}();
    }
}

When developing a Solidity smart contract, developers must set the visibility of state variables to control who can get or set them.

Explicitly setting the visibility on state variables makes it easier to catch incorrect assumptions about who can access the variable.

Example 1: The following code fails to set an explicit level of visibility to a variable.

bytes16 data = "data";

When using Solidity compiler versions prior to version 0.5.0, developers can define a constructor by creating a function with the same name as the containing contract. Constructors in general are reserved for sensitive functionality and meant to be run only at contract creation. If the constructor has a typo such that the name does not match the contract name, then the sensitive functionality in the constructor is exposed.

Example 1: The following code uses a Solidity compiler version earlier than 0.5.0 and tries to declare a constructor with a name that does not exactly match the contract name. In this example, the case of the contract name and the constructor name do not match (Missing vs missing).

pragma solidity 0.4.20;

contract Missing {
    address private owner;
    function missing() public {
        owner = msg.sender;
    }
}

When creating a Solidity smart contract developers can specify the compiler version to use in order to clarify what version it has been tested against and prevent any problems from using a different version of the compiler. However, many compiler-related vulnerabilities have been publicly disclosed over the years and newer patched versions of the compiler have been created to address those issues.

Developers can specify a range of compatible Solidity compiler versions to use when creating a smart contract. This is not recommended because the contract is usually developed and tested in only one of the possible versions. This leaves open the possibility of compiling it using an outdated version of the compiler that has known security vulnerabilities.

Example 1: The following line of code sets the pragma so that the smart contract will not compile in versions earlier than 0.4.5 and it will also not work on compilers of version 0.5.0 and later.

pragma solidity ^0.4.5;

The Salesforce Object Query Language (SOQL) is intended to retrieve specific information from the application database; one cannot change such data using SOQL queries.

Salesforce Object Query Language (SOQL) injection errors occur when:

1. Data enters a program from an untrusted source.


2. The data is used to dynamically construct a SOQL query without any pre-processing or sanitization.
Example 1: The following code dynamically constructs and executes a SOQL query that searches for contacts with a specified name.

...
public String inputValue {
  get { return inputValue; }
  set { inputValue = value; }
}
...
String queryString = 'SELECT Id FROM Contact WHERE (IsDeleted = false AND Name like \'%' + inputValue + '%\')';
result = Database.query(queryString);
...

This code intends to execute the query as follows:

SELECT Id FROM Contact WHERE (IsDeleted = false AND Name like '%inputValue%')

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if inputValue does not contain a single-quote character. If an attacker enters the string name') OR (Name like '% for inputValue, then the query becomes the following:

SELECT Id FROM Contact WHERE (IsDeleted = false AND Name like '%name') OR (Name like '%%')

The addition of the name') OR (Name like '% condition causes the where clause to use the LIKE '%%' condition, which will force the query to output all possible ID values, since it becomes logically equivalent to the much simpler query:

SELECT Id FROM Contact WHERE ... OR (Name like '%%')

Unlike most of database interfaces, SOQL in the force.com platform does not support multiple SOQL statements separated by semicolons, which means that it is not possible to concatenate several commands in a single query as is the case with regular SQL injection attacks. Also, note that Apex database does not support comments, so every single quote, parenthesis or other special character must be paired.

Salesforce Object Search Language (SOSL) is the Salesforce platform search language that is used to perform text searches in records. Use SOSL to search fields across multiple standard and custom object records in Salesforce.

Salesforce Object Search Language (SOSL) injection errors occur when:

1. Data enters a program from an untrusted source.


2. The data is used to dynamically construct a SOSL query without any pre-processing or sanitization.
Example 1: The following code dynamically constructs and executes a SOSL query that searches for contacts with a specified name.

...
public String inputValue {
  get { return inputValue; }
  set { inputValue = value; }
}
...
String queryString = 'Name LIKE \'%' + inputValue + '%\'';
String searchString = 'Acme';
String searchQuery = 'FIND :searchString IN ALL FIELDS RETURNING Contact (Id WHERE ' + queryString + ')';
List<List<SObject>> results = Search.query(searchQuery);
...

This code intends to execute the query as follows:

String searchQuery = 'FIND :searchString IN ALL FIELDS RETURNING Contact (Id WHERE Name LIKE '%' + inputValue + '%')';

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if inputValue does not contain a single-quote character. If an attacker enters the string 1%' OR Name LIKE ' for inputValue, then the query becomes the following:

String searchQuery = 'FIND :searchString IN ALL FIELDS RETURNING Contact (Id WHERE Name LIKE '%1%' OR Name LIKE '%%')';

The addition of the OR Name like '%%' condition causes the where clause to use the LIKE '%%' condition, which will force the query to output all the records that contain phrase 'map', since it becomes logically equivalent to the much simpler query:

FIND 'map*' IN ALL FIELDS RETURNING Contact (Id WHERE Name LIKE '%%')

Unlike most of database interfaces, SOSL in the force.com platform does not support multiple SOSL statements separated by semicolons, which means that it is not possible to concatenate several commands in a single query as is the case with regular SQL injection attacks. Also, note that Apex database does not support comments, so every single quote, parenthesis or other special character must be paired.

Spring enables developers to load Bean definitions from multiple resources including local files and remote URLs. If an attacker is able to control the contents of the Bean definition resource, they will be able to inject malicious Bean definitions which may execute arbitrary code upon their initialization.

Example: The following example loads a bean definition resource from a user-controlled location:

String beans = getBeanDefinitionFromUser();
GenericApplicationContext ctx = new GenericApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
xmlReader.loadBeanDefinitions(new UrlResource(beans));
ctx.refresh();

Spring Boot applications can be configured to deploy Actuators, which are REST endpoints that allow users to monitor different aspects of the application. There are different built-in Actuators which may expose sensitive data and are labeled as "sensitive". By default all sensitive HTTP endpoints are secured such that only users that have an ACTUATOR role may access them.

This application is either disabling the authentication requirement for sensitive endpoints:

Example 1:

management.security.enabled=false

Or marking sensitive endpoints as non-sensitive:

Example 2:

endpoints.health.sensitive=false

Or a custom Actuator is set as non-sensitive:

@Component
public class CustomEndpoint implements Endpoint<List<String>> {

    public String getId() {
        return "customEndpoint";
    }

    public boolean isEnabled() {
        return true;
    }

    public boolean isSensitive() {
        return false;
    }

    public List<String> invoke() {
        // Custom logic to build the output
        ...
    }
}

Spring Boot allows developers to enable admin-related features for the application by specifying the spring.application.admin.enabled property. This exposes the SpringApplicationAdminMXBean on the platform MBeanServer. Developers could use this feature to administer the Spring Boot application remotely, however this feature exposes an additional attack surface in the form of a remote JMX endpoint. Depending on the configuration of the MBeanServer the MBean can be exposed locally or remotely, and may or may not require authentication. In the worst case, attackers will be able to manage the application remotely, including shutting it down without any authentication. In the best case, the service will be as strong as the credentials used to protect the server.

Note: If using a JRE version vulnerable to CVE-2016-3427 (fixed in Java 8 Update 91, April 2016), an attacker will be able to pass any serialized Java object as the credentials, which may lead to arbitrary code execution when the remote JVM deserializes it.