Salt values should be created using a cryptographic pseudorandom number generator. Not using a random salt value makes the resulting hash or hmac much more predictable and susceptible to a dictionary attack.

Example 1: The following code reuses the password as the salt:

function register(){
  $password = $_GET['password'];
  $username = $_GET['username'];

  $hash = hash_pbkdf2('sha256', $password, $password, 100000);
...

Salt values should be created using a cryptographic pseudorandom number generator. Not using a random salt value makes the resulting hash or hmac much more predictable and susceptible to a dictionary attack.

Example 1: The following code reuses the password as the salt:

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']

  dk = hashlib.pbkdf2_hmac('sha256', password, password, 100000)
  hash = binascii.hexlify(dk)
  store(username, hash)
...

Salt values should be created using a cryptographic pseudorandom number generator. Not using a random salt value makes the resulting hash or HMAC much more predictable and susceptible to a dictionary attack.

Example 1: The following code reuses the password as the salt:

require 'openssl'
...
req = Rack::Response.new
password = req.params['password']
...
key = OpenSSL::PKCS5::pbkdf2_hmac(password, password, 100000, 256, 'SHA256')
...

Weak Cryptographic Hash: User-Controlled Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a cryptographic hashing function.

As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a cryptographic hash.

The problem with having a user-controlled salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for the data being hashed. From this, it would be trivial to quickly hash the data being hashed under his control using a number of different hashing algorithms to leak information about the hashing implementation used within your application. This could make "cracking" other data values easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses a user-controlled salt for password hashing:

    ...
    salt = getenv("SALT");
    password = crypt(getpass("Password:"), salt);
    ...

Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to hash the password by modifying the environment variable SALT. Additionally, this code uses the crypt() function, which should not be used for cryptographic hashing of passwords. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled Salt issues occur when:

1. Data enters a program through an untrusted source.

2. The user-controlled data is included within the salt, or used entirely as the salt in a cryptographic hash function.


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a cryptographic hash function.

User-defined salt can enable various types of attacks:

1. Attackers can use this vulnerability to specify an empty salt for the hashed data. Then attackers can quickly hash the data under their control using many different hashing algorithms to leak the hashing implementation your application. This could make "cracking" other data values easier by limiting the particular variant of hash used.
2. If the attacker can manipulate other users' salts, or trick other users into using an empty salt, this enables them to compute "rainbow tables" for the application and easily determine the hashed values.

Example 1: The following code uses a user-controlled salt for password hashing:

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  salt := r.FormValue("salt")
  password := r.FormValue("password")
  ...
  sha256.Sum256([]byte(salt + password))
}

The code in Example 1 will run successfully, but anyone who can get to this functionality can to manipulate the salt used to hash the password by modifying the environment variable salt. Additionally, this code uses the Sum256 cryptographic hash function, which should not be used for cryptographic hashing of passwords. After the program ships, it is nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled Salt issues occur when:

1. Data enters a program through an untrusted source.

2. The user-controlled data is included within the salt, or used entirely as the salt within a cryptographic hash function.


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a cryptographic hash function.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for the data being hashed. From this, it would be trivial to quickly hash the data being hashed under his control using a number of different hashing algorithms to leak information about the hashing implementation used within your application. This could make "cracking" other data values easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses a user-controlled salt for password hashing:

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']
  salt = os.environ['SALT']

  hash = hashlib.md5("%s:%s" % (salt, password,)).hexdigest()
  store(username, hash)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to hash the password by modifying the environment variable SALT. Additionally, this code uses the md5() cryptographic hash function, which should not be used for cryptographic hashing of passwords. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled Salt issues occur when:

1. Data enters a program through an untrusted source

2. The user-controlled data is included within the salt, or used entirely as the salt within a cryptographic hashing function.

As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, this is then used as a salt in a cryptographic hash.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for the data being hashed. From this, it would be trivial to quickly hash the data being hashed under his control using a number of different hashing algorithms to leak information about the hashing implementation used within your application. This could make "cracking" other data values easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses a user-controlled salt for password hashing:

    ...
    salt = req.params['salt']
    hash = @userPassword.crypt(salt)
    ...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to hash the password by modifying the parameter salt. Additionally, this code uses the String#crypt() function, which should not be used for cryptographic hashing of passwords. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.

The following code receives an uploaded file and assigns it to the posted object. FileUpload is of type System.Web.UI.HtmlControls.HtmlInputFile.
Example:

HttpPostedFile posted = FileUpload.PostedFile;

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the PHP interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the Web root. Attackers may upload malicious PHP source files to this program and subsequently request them from the server, which will cause them to be executed by the PHP interpreter.

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the Python interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the web root. Attackers may upload malicious files to this program and subsequently request them from the server.

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
  files = request.FILES
  for f in files.values():
    path = default_storage.save('upload/', File(f))
...

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a publicly executable directory, then they can cause malicious code contained in these files to execute on the server.

Even if a program stores uploaded files under a directory that isn't publicly accessible, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.
Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

An <input> tag of type file indicates the program accepts file uploads.
Example:

<input type="file">

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: A configuration that results in the session cookie being added to the response without setting the Secure flag.

...
<configuration>
   <system.web>
   <authentication mode="Forms">
      <forms requireSSL="false" loginUrl="login.aspx">
      </forms>
   </authentication>
   </system.web>
</configuration>
...

If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example: The following configuration entry turns off the Secure bit for session cookies.

...
session.cookie_secure=0
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers may then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a cookie's value confidential. This is especially important if the cookie contains private data, session identifiers, or carries a CSRF token.
Example 1: The following configuration entry does not explicitly set the Secure bit for session cookies.

...
MIDDLEWARE_CLASSES = (
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'csp.middleware.CSPMiddleware',
    'django.middleware.security.SecurityMiddleware',
    ...
)
...

If an application uses both HTTPS and HTTP, but does not set the Secure flag, cookies sent during an HTTPS request will also be sent during subsequent HTTP requests. Attackers may then compromise the cookie by sniffing the unencrypted network traffic, which is particularly easy over wireless networks.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.

By default, Visualforce pages are rendered with hidden form fields that serve as anti-CSRF tokens. These tokens are included in the requests that are sent from within the page, and the server checks the validity of the tokens before executing the corresponding action methods or commands. However, this built-in defense does not apply to page action methods and custom page controller constructors because they are executed before the anti-CSRF tokens are generated during page load.

Example 1: The following Visualforce page declares a custom contoller MyAccountActions and a page action method pageAction(). The pageAction() method is executed when visiting the page URL, and the server does not check for anti-CSRF tokens.

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>

public class MyAccountActions {

    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

An attacker might set up a malicious website that contains the following code:

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

If an administrator for the Visualforce page visits the malicious page while having an active session on the site, they will unwittingly delete accounts for the attacker.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.



A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a web application that uses session cookies has to take special precautions to ensure that an attacker can't trick users into submitting bogus requests. Imagine a web application that allows administrators to create new accounts as follows:

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

An attacker might set up a malicious web site that contains the following code.

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

If an administrator for example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.
CSRF is entry number five on the 2007 OWASP Top 10 list.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.

A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a Web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a Web application that allows administrators to create new accounts by submitting this form:

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

An attacker might set up a Web site with the following:

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

If an administrator for example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.

A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a Web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a Web application that allows administrators to create new accounts as follows:

By default Play Framework adds protection against CSRF, but it can be disabled globally or for certain routes.

Example: The following route definition disables the CSRF protection for the buyItem controller method.

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

If a user is tricked into visiting a malicious page while she has an active session for shop.com, she will unwittingly buy items for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.



A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a Web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a Web application that allows administrators to create new accounts by submitting this form:

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

An attacker might set up a Web site with the following:

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

If an administrator for example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

CSRF is entry number five on the 2007 OWASP Top 10 list.

YAML serialization libraries, which convert object graphs into YAML formatted data may include the necessary metadata to reconstruct the objects back from the YAML stream. If attackers can specify the classes of the objects to be reconstructed and are able to force the application to run arbitrary setters with user-controlled data, they may be able to execute arbitrary code during the deserialization of the YAML stream.

Example: The following example deserializes an untrusted YAML string using the YamlDotNet parser.

    var yamlString = getYAMLFromUser();

    // Setup the input
    var input = new StringReader(yamlString);

    // Load the stream
    var yaml = new YamlStream();
    yaml.Load(input);

YAML serialization libraries, which convert object graphs into YAML formatted data may include the necessary metadata to reconstruct the objects back from the YAML stream. If attackers can specify the classes of the objects to be reconstructed and are able to force the application to run arbitrary setters with user-controlled data, they may be able to execute arbitrary code during the deserialization of the YAML stream.

Example 1: The following example deserializes an untrusted YAML string using an insecure YAML parser.

var yaml = require('js-yaml');

var untrusted_yaml = getYAMLFromUser();
yaml.load(untrusted_yaml) 

YAML serialization libraries, which convert object graphs into YAML formatted data may include the necessary metadata to reconstruct the objects back from the YAML stream. If attackers can specify the classes of the objects to be reconstructed and are able to force the application to run arbitrary setters with user-controlled data, they may be able to execute arbitrary code during the deserialization of the YAML stream.

Example 1: The following example deserializes an untrusted YAML string using an insecure YAML loader.

import yaml

yamlString = getYamlFromUser()
yaml.load(yamlString)

The X-XSS-Protection header is typically enabled by default in modern browsers. When the header value is set to false (0), cross-site scripting protection is disabled.

The header can be set in multiple locations and should be checked for both misconfiguration as well as malicious tampering.

The X-XSS-Protection header is typically enabled by default in modern browsers. When the header value is set to false (0), cross-site scripting protection is disabled.
The header can be set in multiple locations and should be checked for both misconfiguration as well as malicious tampering.

The X-XSS-Protection header is typically enabled by default in modern browsers. When the header value is set to false (0), cross-site scripting protection is disabled.

The header can be set in multiple locations and should be checked for both misconfiguration as well as malicious tampering.