The WS-SecurityPolicy standard supports seven assertions when specifying supporting tokens: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, SignedEndorsingSupportingTokens, SignedEncryptedSupportingTokens, EndorsingEncryptedSupportingTokens, and SignedEndorsingEncryptedSupportingTokens.
It might be possible to breach the integrity or confidentiality of tokens that are not signed or encrypted. Endorsing tokens sign the message signature to prevent tampering of the message signature.

Example 1: The following WS-SecurityPolicy policy entry allows UsernameTokens to be sent in SOAP messages without a signature or encryption:

<sp:SupportingTokens>
  <wsp:Policy>
    <sp:UsernameToken
      sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
        <sp:WssUsernameToken10/>
      </wsp:Policy>
    </sp:UsernameToken>
  </wsp:Policy>
</sp:SupportingTokens>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry uses asymmetric binding, but does not specify an initiator signature token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorEncryptionToken>
    <sp:RecipientEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientEncryptionToken>
    <sp:RecipientSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientSignatureToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry uses asymmetric binding, but does not specify a recipient signature token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorEncryptionToken>
    <sp:InitiatorSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorSignatureToken>
    <sp:RecipientEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientEncryptionToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry uses symmetric binding, but does not specify a signature token:

<sp:SymmetricBinding>
    <wsp:Policy>
        <sp:EncryptionToken>
            <wsp:Policy>
                ...
            </wsp:Policy>
        </sp:EncryptionToken>
        ...
    </wsp:Policy>
</sp:SymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry omits the <ProtectTokens> tag:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorToken>
    ...
    </sp:InitiatorToken>
    <sp:RecipientToken>
    ...
    </sp:RecipientToken>
    <sp:AlgorithmSuite>
    ...
    </sp:AlgorithmSuite>
    <sp:Layout>
    ...
    </sp:Layout>
    <sp:IncludeTimestamp/>

    <sp:OnlySignEntireHeadersAndBody/>
  </wsp:Policy>
</sp:AsymmetricBinding>

Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.

It is never a good idea to hardcode a password. Storing password details within comments is equivalent to hardcoding passwords. Not only is the password visible to the project's developers, it also makes fixing the problem extremely difficult. After the code is in production, the password is now leaked to the outside world and cannot be protected or changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability.
Example 1: The following comment specifies the default password to connect to a database:

...
// Default username for database connection is "scott"
// Default password for database connection is "tiger"
...

This code will run successfully, but anyone who has access to it will have access to the password. An employee with access to this information can use it to break into the system.

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The VirtualLock function is intended to lock pages in memory to prevent them from being paged to disk. However, on Windows 95/98/ME the function is implemented as stub only and has no effect.

By default, the ASP.NET forms authentication validates the user credentials before passing it to native APIs during the authentication process. The issue is, this functionality can be modified using the aspnet:UseLegacyFormsAuthenticationTicketCompatibility setting to allow unvalidated input to be passed to the native APIs and may lead to an attacker being able to bypass authentication. An attacker who successfully exploites this vulnerability would be able to bypass ASP.NET forms authentication for any known username without its password. The attacker could then take any action in the context of the victim user, including executing arbitrary commands on the site.

Example 1: In the following example, aspnet:UseLegacyFormsAuthenticationTicketCompatibility is set to true.

...
  <appSettings>
    <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />
  </appSettings>
...

Unvalidated input is one of the leading causes of vulnerabilities in ASP.NET Web API services. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, access control, and SQL injection. Although ASP.NET Web API services are generally not susceptible to memory corruption attacks, if an ASP.NET Web API service calls into native code which does not perform array bounds checking, an attacker may be able to use an input validation weakness in the ASP.NET Web API service to launch a buffer overflow attack.

To prevent such attacks:
1. use validation attributes to programmatically annotate validation checks on parameters or members of model-binding object parameters to ASP.NET Web API service actions.
2. use ModelState.IsValid to check if model validation passes.

Some web frameworks collapse the POST and GET parameters into a single collection. This is a flawed design pattern from a security standpoint. If a page accepts POST parameters as GET parameters an attacker would be able to affect change on websites through Cross-Site Request Forgery or leverage this design flaw with other vulnerabilities to attack the system hosting the web application.

Application resources containing sensitive information or providing privileged functionality are generally at a greater risk of exploitation. During the reconnaissance phase, an attacker will make attempts to discover such files and directories. Using predictable naming schemes for such resources makes it easier for the attacker to locate them. All the application resources that deal with sensitive functionality such as authentication, administrative tasks, or handling of private information must be sufficiently protected from discovery.

Example 1: In the following example, the admin application is deployed in a predictable URL:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Resources responsible for storing data must be separated from those that implement application functionality. Programmers must exercise caution when creating temporary or backup resources.

Attackers may be able to modify the format string argument such that an exception is thrown. If this exception is left uncaught, it may crash the application. Alternatively, if sensitive information is used within the other arguments, attackers may change the format string to reveal this information.

Example 1: The following code allows a user to specify the format string argument to Formatter.format().

  ...
  Formatter formatter = new Formatter(Locale.US);
  String format = "The customer: %s %s has the balance %4$." + userInput + "f";
  formatter.format(format, firstName, lastName, accountNo, balance);
  ...

The intention of this program is to let the user specify the decimal points to which it shows the balance. In reality though, there are no restrictions on this. If the user can specify anything, it may cause an exception such as java.util.MissingFormatArgumentException to be thrown, and since this is not within a try block, could lead to application failure.
Even more critical within this example, if an attacker can specify the user input "2f %3$s %4$.2", the format string would be "The customer: %s %s has the balance %4$.2f %3$s %4$.2". This would then lead to the sensitive accountNo to be included within the resulting string.

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.

ASP.NET Core allows for application actions to require authorization by adding the [Authorize] attribute to a class or a method. Additionally, the specified authorization requirement of an application class or method can be bypassed by adding the [AllowAnonymous] attribute. When both are specified, the [AllowAnonymous] attribute takes precedence and bypasses the [Authorize] attribute. This can result in the arbitrary and anonymous access of sensitive data and actions by an attacker.

Example 1: The following example shows the [AllowAnonymous] attribute at the class level overriding an [Authorize] attribute set on the method. The secretAction() method does not require authorization despite having the [Authorize] attribute.

...
[AllowAnonymous]
public class Authorization_Test
{
    [Authorize]
    public IActionResult secretAction()
    {
        
    }
}
...

Example 2: The following example shows the [AllowAnonymous] attribute at the class level of a superclass overriding an [Authorize] attribute set on the method of a subclass. Due to the inherited class Inherit_AA having the [AllowAnonymous] attribute, the secretAction() method does not require authorization despite specifying the [Authorize] attribute.

...
[AllowAnonymous]
public abstract class Inherit_AA
{
    
}

public class Authorization_Test:Inherit_AA
{
    [Authorize]
    public IActionResult secretAction()
    {
        
    }
}
...

Example 3: The following shows the [AllowAnonymous] attribute overriding an [Authorize] attribute at the method level with inheritance. Due to the inherited method secretAction() having the [AllowAnonymous] attribute, the secretAction() method does not require authorization despite specifying the [Authorize] attribute on the overriding method.

...
public abstract class Inherit_AA
{
    [AllowAnonymous]
    public abstract IActionResult secretAction()
    {
        
    }
}

public class Authorization_Test:Inherit_AA
{
    [Authorize]
    public override IActionResult secretAction()
    {
        
    }
}
...

It is common practice to output the values of variables for debugging or testing purposes with code that is not intended to be shipped or remain active in the deployed application. When this sort of debug code is accidentally left in the application, the application may provide information to an attacker in unintended ways. Not all debugging statements leak sensitive or private information. However, the presence of a debugging statement often indicates that the surrounding code has been neglected and may be in a state of disrepair.

The most common example of forgotten debug code in ColdFusion is the <cfdump> tag. Although use of <cfdump> is a acceptable during product development, developers responsible for code that is part of a production web application should carefully consider whether any use of the <cfdump> tag should be allowed.

Hardcoding LDAP queries into the application code or revealing them in error messages can expose sensitive information such as variable names or path information. It can also disclose valuable information about the structure of an LDAP query. An attacker can use this information to manipulate the LDAP statement or filter and retrieve user records or execute arbitrary LDAP commands.

Bean property names and values need to be validated before populating any bean. Bean population functions let developers to set a bean property or a nested property. Attackers can leverage this functionality to access special bean properties such as class.classLoader that enable them to override system properties and potentially execute arbitrary code.

Example 1: The following code sets a user-controlled bean property without proper validation of the property name or value:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);