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 Java code uses Jackson 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 ~/user_info.json:

...

JsonFactory jfactory = new JsonFactory();

JsonGenerator jGenerator = jfactory.createJsonGenerator(new File("~/user_info.json"), JsonEncoding.UTF8);

jGenerator.writeStartObject();

jGenerator.writeFieldName("username");
jGenerator.writeRawValue("\"" + username + "\"");

jGenerator.writeFieldName("password");
jGenerator.writeRawValue("\"" + password + "\"");

jGenerator.writeFieldName("role");
jGenerator.writeRawValue("\"default\"");

jGenerator.writeEndObject();

jGenerator.close();

Yet, because the JSON serialization is performed using JsonGenerator.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 ~/user_info.json would be:

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

If this serialized JSON file were then deserialized to an HashMap object with Jackson's JsonParser as so:

JsonParser jParser = jfactory.createJsonParser(new File("~/user_info.json"));

while (jParser.nextToken() != JsonToken.END_OBJECT) {

  String fieldname = jParser.getCurrentName();

  if ("username".equals(fieldname)) {
    jParser.nextToken();
    userInfo.put(fieldname, jParser.getText());
  }

  if ("password".equals(fieldname)) {
    jParser.nextToken();
    userInfo.put(fieldname, jParser.getText());
  }

  if ("role".equals(fieldname)) {
    jParser.nextToken();
    userInfo.put(fieldname, jParser.getText());
  }

  if (userInfo.size() == 3)
    break;
}

jParser.close();

The resulting values for the username, password, and role keys in the HashMap 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 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 : 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.

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.

The application fails to validate the type of data received from a web form. It is a good practice to validate that the received data satisfy the requirements defined for the expected data.

Example 1: The following code defines a Spring WebFlow FormAction which fails to validate the data against the expected requirements:

    <bean id="customerCriteriaAction" class="org.springframework.webflow.action.FormAction">
        <property name="formObjectClass"
            value="com.acme.domain.CustomerCriteria" />
        <property name="propertyEditorRegistrar">
            <bean
                class="com.acme.web.PropertyEditors" />
        </property>
    </bean>

Example 2: The following code defines a Spring WebFlow action state which fails to validate the data against the expected requirements:

    <action-state>
        <action bean="transferMoneyAction" method="bind" />
    </action-state>

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following ABAP code instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

...
DATA: str_dest TYPE c.

str_dest = request->get_form_field( 'dest' ).
response->redirect( str_dest ).
...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following ActionScript code instructs the user's browser to open a URL read from the dest request parameter when a user clicks the link.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var strDest:String = String(params["dest"]);
        host.updateLocation(strDest);
        ...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks. Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications use redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that an attacker can control.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following Visualforce action method returns a PageReference object consisting of a URL from the dest request parameter.

public PageReference pageAction() {
    ...
    PageReference ref = ApexPages.currentPage();
    Map<String,String> params = ref.getParameters();
    return new PageReference(params.get('dest'));
}

If a victim receives an email instructing them to follow a link to "http://trusted.vf.force.com/apex/vfpage?dest=www.wilyhacker.com", the user might click on the link believing they will visit a trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails and make sure the link specifies a trusted site they know. However, if the attacker encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user might be fooled into following the link.

By default, The ASP.NET login page will not allow URL redirection to outside the hosted domain during the user authentication process. However, this functionality can be modified using the aspnet:AllowRelaxedRelativeUrl setting to allow unrestricted URL redirection. An attacker who successfully exploited this vulnerability would be able to redirect a user to a website of the attacker's choosing without the user's consent. The attacker could then perform a phishing attack to gain information from the user they did not intend to disclose.

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

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

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following JSP code instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

    ...
    final server = await HttpServer.bind(host, port);
      await for (HttpRequest request in server) {
        final response = request.response;
        final headers = request.headers;
        final strDest = headers.value('strDest');
        response.headers.contentType = ContentType.text;
        response.redirect(Uri.parse(strDest!));
        await response.close();
      }
    ...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user might be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that an attacker can control.

Attackers can utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example: The following code instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

    ...
    strDest := r.Form.Get("dest")
    http.Redirect(w, r, strDest, http.StatusSeeOther)
    ...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they will be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 redirects the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination URL as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user can be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following Spring WebFlow flow state definition instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

    <end-state id="redirectView" view="externalRedirect:#{requestParameters.dest}" />

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following JavaScript code instructs the user's browser to open a URL read from the dest request parameter when a user clicks the link.

	...
	strDest = form.dest.value;
	window.open(strDest,"myresults");
	...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following PHP code instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

    <%
        ...
        $strDest = $_GET["dest"];
        header("Location: " . $strDest);
        ...
    %>

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.php?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.php?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following procedure instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

      ...
      -- Assume QUERY_STRING looks like dest=http://www.wilyhacker.com
      dest := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 6);
      OWA_UTIL.redirect_url('dest');
      ...
  

If a victim received an email instructing them to follow a link to "http://trusted.example.com/pls/hr/showemps?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/pls/hr/showemps?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following Python code instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

        ...
        strDest = request.field("dest")
        redirect(strDest)
        ...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following Ruby code instructs the user's browser to open a URL parsed from the dest request parameter:

...
str_dest = req.params['dest']
...
res = Rack::Response.new
...
res.redirect("http://#{dest}")
...

If a victim received an email instructing them to follow a link to "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Attackers might utilize open redirects to trick users into visiting a URL to a trusted site, but then redirecting them to a malicious site. By encoding the URL, an attacker can make it difficult for end-users to notice the malicious destination of the redirect, even when it is passed as a URL parameter to the trusted site. Open redirects are often abused as part of phishing scams to harvest sensitive end-user data.

Example 1: The following VB code instructs the user's browser to open a URL parsed from the dest request parameter when a user clicks the link.

	...
	strDest = Request.Form('dest')
	HyperLink.NavigateTo strDest
	...

If a victim received an email instructing them to follow a link to "http://www.trustedsite.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", the user would likely click on the link believing they would be transferred to the trusted site. However, when the victim clicks the link, the code in Example 1 will redirect the browser to "http://www.wilyhacker.com".

Many users have been educated to always inspect URLs they receive in emails to make sure the link specifies a trusted site they know. However, if the attacker Hex encoded the destination url as follows:
"http://www.trustedsite.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

then even a savvy end-user may be fooled into following the link.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example: The following code reads a password from a properties file and uses the password to set default authentication credentials for URL requests.

...
var fs:FileStream = new FileStream();
fs.open(new File("config.properties"), FileMode.READ);
var password:String = fs.readMultiByte(fs.bytesAvailable, File.systemCharset);

URLRequestDefaults.setLoginCredentialsForHost(hostname, usr, password);
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's configuration files or other data store.
Example: The following code reads a password from the registry and uses the password to create a new network credential.

...
string password = regKey.GetValue(passKey).ToString());
NetworkCredential netCred =
           new NetworkCredential(username,password,domain);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's configuration files or other data store.
Example: The following code reads a password from the registry and uses the password to connect to a database.

...
RegQueryValueEx(hkey,TEXT(.SQLPWD.),NULL,
                NULL,(LPBYTE)password, &size);
rc = SQLConnect(*hdbc, server, SQL_NTS, uid,
                SQL_NTS, password, SQL_NTS);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
01  RECORD.
     05  UID              PIC X(10).
     05  PASSWORD         PIC X(10).
...
EXEC CICS
  READ
  FILE('CFG')
  INTO(RECORD)
  RIDFLD(ACCTNO)
  ...
END-EXEC.

EXEC SQL
  CONNECT :UID
  IDENTIFIED BY :PASSWORD
  AT :MYCONN
  USING :MYSERVER
END-EXEC.
...

This code will run successfully, but anyone who has access to CFG can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is accepted from a user or is stored in plain text in an application's configuration files or database.
Example: The following code reads a password from a web form and uses the password to connect to a database.

<cfquery name = "GetCredentials" dataSource = "master">
SELECT   Username, Password
FROM     Credentials
WHERE    DataSource="users"
</cfquery>
...
<cfquery name = "GetSSNs" dataSource = "users"
 username = "#Username#" password = "#Password#">
SELECT   SSN
FROM     Users
</cfquery>
...

This code will run successfully, but anyone who has access to the table master can read the value of Username and Password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example 1: The following code reads a password from a JSON file and uses the password to set the request's authorization header:

...
file, _ := os.Open("config.json")
decoder := json.NewDecoder(file)
decoder.Decode(&values)

request.SetBasicAuth(values.Username, values.Password)
...

This code will run successfully, but anyone who has access to config.json can read the value of values.Password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example 1: The following code reads a password from a properties file and uses the password to connect to a database.

...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");

DriverManager.getConnection(url, usr, password);
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. Any devious employee with access to this information can use it to break into the system.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.
Example 2: The following code reads username and password from an Android WebView store and uses them to setup authentication for viewing protected pages.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    handler.proceed(username, password);
  }
});
...

By default, WebView credentials are stored in plain text and are not hashed. So if a user has a rooted device (or uses an emulator), she is able to read stored passwords for given sites.

Password management issues occur when a password is stored in plain text in an application.
Example: The following code uses a hardcoded password to connect to an application and retrieve address book entries:

    ...
    obj = new XMLHttpRequest();
    obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','tiger');
    ...

This code will run successfully, but anyone who accesses the containing web page can view the password.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example: The following code reads a password from a plist file and uses it to unzip a password-protected file.

...
NSDictionary *dict= [NSDictionary dictionaryWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Config" ofType:@"plist"]];
NSString *password = [dict valueForKey:@"password"];
[SSZipArchive unzipFileAtPath:zipPath toDestination:destPath overwrite:TRUE password:password error:&error];
...

In the mobile environment, password management is especially important given that there is such a high chance of device loss.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
$props = file('config.properties', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
$password = $props[0];

$link = mysql_connect($url, $usr, $password);
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is hardcoded or stored in plain text in an application's configuration files or other data store. It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. After the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system must choose between security and availability
Example: The following code authenticates the user by reading the password that the user used to log into the database server and comparing it to an expected value.

...
ip_address := OWA_SEC.get_client_ip;
IF ((OWA_SEC.get_user_id = 'scott') AND
    (OWA_SEC.get_password = 'tiger') AND
    (ip_address(1) = 144) and (ip_address(2) = 25)) THEN
        RETURN TRUE;
ELSE
        RETURN FALSE;
END IF;
...

This code will run successfully, but anyone who has access to it will have access to the password. After the program ships, there is likely no way to change the database user "scott" with a password of "tiger" unless the program is patched. An employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
props = os.open('config.properties')
password = props[0]

link = MySQLdb.connect (host = "localhost",
                           user = "testuser",
                           passwd = password,
                           db = "test")
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's configuration files or other data store.
Example: The following code reads a password from an environment variable and uses the password to connect to a database.

require 'pg'
...
passwd = ENV['PASSWD']
...
conn = PG::Connection.new(:dbname => "myApp_production", :user => username, :password => passwd, :sslmode => 'require')

This code will run successfully, but anyone who has access to the environment variable used to store the password can read the value of PASSWD. Any devious employee with access to this information can use it to break into the system.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example 1: The following code reads a password from a plist file and uses it to unzip a password-protected file.

...
var myDict: NSDictionary?
if let path = NSBundle.mainBundle().pathForResource("Config", ofType: "plist") {
    myDict = NSDictionary(contentsOfFile: path)
}
if let dict = myDict {
    zipArchive.unzipOpenFile(zipPath, password:dict["password"])
}
...

In the mobile environment, password management is especially important given that there is such a high chance of device loss.

Password management issues occur when a password is stored in plain text in an application's properties or configuration file.
Example: The following code reads a password from a properties file and uses the password to connect to a database.

...
Private Declare Function GetPrivateProfileString _
  Lib "kernel32" Alias "GetPrivateProfileStringA" _
  (ByVal lpApplicationName As String, _
  ByVal lpKeyName As Any, ByVal lpDefault As String, _
  ByVal lpReturnedString As String, ByVal nSize As Long, _
  ByVal lpFileName As String) As Long
...
Dim password As String
...
password = GetPrivateProfileString("MyApp", "Password", _
  "", value, Len(value), _
   App.Path & "\" & "Config.ini")
...
con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=" & password &";"
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. Any devious employee with access to this information can use it to break into the system.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: This code initializes an empty password variable.

...
password = ''.
...

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to set default authentication credentials for URL requests, supplying an empty string for a password.

    ...
    URLRequestDefaults.setLoginCredentialsForHost(hostname, "scott", "");
    ...

The code in Example 1 indicates that the user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    var storedPassword:String = "";
    var temp:String;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(storedPassword.equals(userPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

It is never a good idea to have an empty password. If the account protected by the empty password is compromised, the owners of the system must choose between security and availability because it can be extremely difficult to patch the system after the code is in production.

Example 1: The following code uses an empty password to authenticate a client certificate:

...
HttpRequest req = new HttpRequest();
req.setClientCertificate('mycert', '');
...

If the code runs successfully, it indicates that the certificate is configured with an empty password, which an attacker can easily guess.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1:

    ...
    NetworkCredential netCred = new NetworkCredential("scott", "", domain);
    ...

If the code in Example 1 succeeds, it indicates that the network credential login "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = "";
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if(storedPassword.Equals(userPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    rc = SQLConnect(*hdbc, server, SQL_NTS, "scott", SQL_NTS, "", SQL_NTS);
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    char *stored_password = "";

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for user_password.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    <cfquery name = "GetSSNs" dataSource = "users"
     username = "scott" password = "">
    SELECT   SSN
    FROM     Users
    </cfquery>
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
      var password = "";
      var temp;
      if ((temp = readPassword()) != null) {
        password = temp;
      }
      if(password == userPassword()) {
         // Access protected resources
        ...
      }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a database with an empty password.

...
response.SetBasicAuth(usrName, "")
...

If the code in the Example succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    DriverManager.getConnection(url, "scott", "");
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    String storedPassword = "";
    String temp;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(storedPassword.equals(userPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for userPassword.

In the mobile environment, password management is especially important given that there is such a high chance of device loss.
Example 3: The following code initializes username and password variables to empty strings, reads credentials from an Android WebView store if they have not been previously rejected by the server for the current request, and uses them to setup authentication for viewing protected pages.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String username = "";
    String password = "";

    if (handler.useHttpAuthUsernamePassword()) {
      String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
      username = credentials[0];
      password = credentials[1];
    }
    handler.proceed(username, password);
  }
});
...

Similar to Example 2, if useHttpAuthUsernamePassword() returns false, an attacker will be able to view protected pages by supplying an empty password.

It is never a good idea to have an empty password. It also makes fixing the problem extremely difficult once the code is in production. The password cannot be changed without patching the software. If the account protected by the empty password is compromised, the owners of the system must choose between security and availability.
Example: The following code has an empty password to connect to an application and retrieve address book entries:

...
obj = new XMLHttpRequest();
obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','');
...

This code will run successfully, but anyone can access when they know the username.

Never assign an empty string to a password variable. If the empty password is successfully used to authenticate against a system, then the corresponding account's security is likely compromised because it accepts an empty password.

Example: The following JSON initializes an empty password.

{
  ...
  "password" : ""
  ...
}

It is never a good idea to assign an empty string to a password variable. The use of empty passwords can introduce a significant point of weakness into an otherwise secure system. Even if the empty password is merely a placeholder until a legitimate value can be assigned to the variable, it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password:

...
rc = SQLConnect(*hdbc, server, SQL_NTS, "scott", SQL_NTS, "", SQL_NTS);
...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value:

...
NSString *stored_password = "";

readPassword(stored_password);

if(safe_strcmp(stored_password, user_password)) {
    // Access protected resources
    ...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for user_password.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a database with an empty password.

<?php
    ...
    $connection = mysql_connect($host, 'scott', '');
    ...
?>

If the code in the Example succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code initializes an empty password variable.

DECLARE
    password VARCHAR(20);
BEGIN
    password := "";
END;

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example: The following code attempts to connect to a database with an empty password.

...
db = mysql.connect("localhost","scott","","mydb")
...

If the code in the Example succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    conn = Mysql.new(database_host, "scott", "", databasename);
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Due to the dynamic nature of Ruby, many functions also take an optional number of arguments, so the password may be set to "" as a default value when none is specified. In this case you also need to make sure that the correct number of arguments are specified in order to make sure a password is passed to the function.

It is never a good idea to assign an empty string to a password variable. The use of empty passwords can introduce a significant point of weakness into an otherwise secure system. Even if the empty password is merely a placeholder until a legitimate value can be assigned to the variable, it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password:

...
let password = ""
let username = "scott"
let con = DBConnect(username, password)
...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Example 2: The following code initializes a password variable to an empty string, attempts to read a stored value for the password, and compares it against a user-supplied value:

...
var stored_password = ""

readPassword(stored_password)

if(stored_password == user_password) {
// Access protected resources
...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing an empty string for user_password.

It is never a good idea to assign an empty string to a password variable. If the empty password is used to successfully authenticate against another system, then the corresponding account's security is likely compromised because it accepts an empty password. If the empty password is merely a placeholder until a legitimate value can be assigned to the variable, then it can confuse anyone unfamiliar with the code and potentially cause problems on unexpected control flow paths.

Example 1: The following code attempts to connect to a database with an empty password.

    ...
    Dim con As New ADODB.Connection
    Dim cmd As New ADODB.Command
    Dim rst As New ADODB.Recordset

    con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=;"
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.