La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código C# utiliza JSON.NET para serializar la información de autenticación de las cuentas de usuario para los usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con privilegios con un rol de "admin") a partir de las variables de entrada controladas por el usuario username y password al archivo JSON ubicado en 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());

Aun así, dado que la serialización de JSON se realiza mediante el uso de JsonWriter.WriteRawValue(), los datos que no son de confianza de username y password no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirlo en la solicitud que establece el valor de la variable username, el JSON resultante guardado en C:\user_info.json sería:

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

Si el archivo JSON serializado se fuese a deserializar en un objeto Dictionary con JsonConvert.DeserializeObject() de este modo:

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

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

Los valores resultantes para las claves de username, password y role del objeto Dictionary serían mallory, Evil123! y admin, respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.

La inyección JSON se produce cuando sucede lo siguiente:

1. Los datos se introducen en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y puede contener información confidencial. Cuando se usa para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y puede transmitir información confidencial, como las credenciales de autenticación.

Los atacantes pueden alterar la semántica de mensajes y documentos JSON si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede insertar elementos extraños y hacer que una aplicación genere una excepción mientras se están analizando un documento o una solicitud JSON. En casos más graves, como aquellos que impliquen la inyección JSON, un atacante puede insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En ocasiones, la inyección JSON puede dar lugar a scripts de sitios o una evaluación de código dinámico.

Ejemplo 1: El siguiente código serializa la información de autenticación de las cuentas de usuario para los usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con privilegios con un rol de "admin") a partir de variables de entrada controladas por el usuario username y password al archivo JSON ubicado en ~/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)
    }
    

Debido a que el código realiza la serialización de JSON mediante el uso de la concatenación de cadenas, los datos que no son de confianza en username y password no se validan a fin de omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, lo cual posiblemente pueda cambiar la estructura del archivo JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! anexó ","role":"admin cuando ingresó su nombre de usuario, el archivo JSON resultante guardado en ~/user_info.json sería el siguiente:

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

Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asigna de forma accidental al usuario mallory privilegios de "admin".

La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código Java utiliza Jackson para serializar la información de autenticación de las cuentas de usuario para los usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con privilegios con un rol de "admin") a partir de variables de entrada controladas por el usuario username y password al archivo JSON ubicado en ~/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();

Aun así, dado que la serialización de JSON se realiza mediante el uso de JsonGenerator.writeRawValue(), los datos que no son de confianza de username y password no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirlo en la solicitud que establece el valor de la variable username, el JSON resultante guardado en ~/user_info.json sería:

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

Si el archivo JSON serializado se fuese a deserializar en un objeto HashMap con JsonParser de Jackson de este modo:

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();

Los valores resultantes para las claves de username, password y role del objeto HashMap serían mallory, Evil123! y admin, respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.

La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código JavaScript utiliza jQuery para analizar JSON, donde un valor procede de una dirección 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 + '"}');
    ...
  }
  ...
});

Aquí, los datos que no son de confianza en name no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory fuese a agregar ","role":"admin al parámetro de nombre en la dirección URL, el JSON resultante sería:

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

Esto es analizado por jQuery.parseJSON() y establecido como objeto simple, lo que significa que obj.role devolverá "admin" en lugar de "user".

La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: el siguiente código Objective-C serializa la información de la autenticación de cuenta de usuario para usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con un rol de "admin") a JSON de los campos controlables por el usuario _usernameField y _passwordField:

...

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

Aun así, dado que la serialización de JSON se realiza mediante el uso de NSString.stringWithFormat:, los datos que no son de confianza de _usernameField y _passwordField no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirla en el campo _usernameField, el JSON resultante sería:

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

Si esta cadena JSON serializada se fuese a deserializar en un objeto NSDictionary con NSJSONSerialization.JSONObjectWithData: de este modo:

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

Los valores resultantes para username, password y role en el objeto NSDictionary serían mallory, Evil123! y admin respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.

La inyección JSON se produce cuando sucede lo siguiente:

1. Los datos se introducen en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en caché y puede contener información confidencial. Cuando se usa para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y puede transmitir información confidencial, como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada no validada. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación genere una excepción mientras se están analizando un documento o una solicitud JSON. En casos más graves, como aquellos que implican una inyección JSON, un atacante puede insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección de código JSON puede dar lugar a secuencias de comandos en sitios cruzados (Cross-Site Scripting) o a la evaluación de código dinámico.

Ejemplo: El siguiente código de Python actualiza un archivo json con un valor que no es fiable y proviene de una 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)

...

Aquí, los datos que no son fiables en name no se validarán para escapar de los caracteres especiales relacionados con JSON. Esto permite que un usuario inserte arbitrariamente claves JSON, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory agregara ","role":"admin al parámetro de nombre en la URL, el JSON se convertiría en:

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

El archivo JSON ahora está manipulado con datos maliciosos y el usuario tiene un acceso privilegiado de "administrador" en lugar de "usuario".

La inyección JSON se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en una secuencia JSON.

Las aplicaciones suelen utilizar la secuencia JSON para almacenar datos o enviar mensajes. Cuando se utiliza para almacenar datos, JSON a menudo se trata como datos almacenados en la caché y pueden contener información probablemente confidencial. Cuando se utiliza para enviar mensajes, JSON a menudo se utiliza junto con un servicio RESTful y se puede utilizar para transmitir información confidencial como las credenciales de autenticación.

La semántica de los documentos y mensajes JSON se puede modificar si una aplicación construye JSON a partir de una entrada sin validar. En un caso relativamente benigno, un atacante puede ser capaz de insertar elementos extraños y hacer que una aplicación produzca una excepción mientras se está analizando un documento o una solicitud JSON. En un caso más grave, como uno que implique la inyección JSON, un atacante puede ser capaz de insertar elementos extraños que permitan la manipulación predecible de los valores críticos para el negocio dentro de un documento o una solicitud JSON. En algunos casos, la inyección JSON puede dar lugar a cross-site scripting o evaluación de código dinámico.

Ejemplo 1: El siguiente código Swift serializa la información de la autenticación de cuenta de usuario para usuarios sin privilegios (aquellos con un rol "predeterminado" a diferencia de los usuarios con un rol de "admin") a JSON de los campos controlables por el usuario usernameField y passwordField:

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

Aún así, dado que la serialización de JSON se realiza mediante el uso de la interpolación de cadenas, los datos que no son de confianza en usernameField y passwordField no se validarán para omitir caracteres especiales relacionados con JSON. Esto permite a un usuario introducir claves JSON de forma arbitraria, posiblemente cambiando la estructura del JSON serializado. En este ejemplo, si el usuario sin privilegios mallory con la contraseña Evil123! fuese a agregar ","role":"admin a su nombre de usuario al introducirla en el campo usernameField, el JSON resultante sería:

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

Si esta cadena JSON serializada se fuese a deserializar en un objeto NSDictionary con NSJSONSerialization.JSONObjectWithData: de este modo:

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

Los valores resultantes para username, password y role en el objeto NSDictionary serían mallory, Evil123! y admin respectivamente. Sin más comprobaciones de que los valores JSON deserializados son válidos, la aplicación asignará de forma incorrecta privilegios de "admin" al usuario mallory.

La aplicación no valida el tipo de datos recibidos de un formulario web. Es recomendable validar que los datos recibidos satisfagan los requisitos definidos para los datos esperados.

Ejemplo 1: El siguiente código define un elemento FormAction de Spring WebFlow que no valida los datos contra los requisitos esperados:

    <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>

Ejemplo 2: El siguiente código define un estado de acción de Spring WebFlow que no valida los datos con respecto a los requisitos esperados:

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

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: El siguiente código ABAP indica al explorador del usuario que abra una dirección URL que se analiza desde el parámetro de solicitud de dest cuando un usuario hace clic en el vínculo.

...
DATA: str_dest TYPE c.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: el siguiente código ActionScript indica al explorador del usuario que abra una dirección URL leída desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede ayudar a los ataques de suplantación de identidad. Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades Open Redirect se producen cuando una aplicación web redirige a los clientes a una dirección URL arbitraria que pueda estar controlada por un atacante.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: El siguiente método de acción de Visualforce devuelve un objeto PageReference que consiste en una URL del parámetro de solicitud dest.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.vf.force.com/apex/vfpage?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios para que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico y se aseguren de que el vínculo especifique un sitio de confianza que conocen. Sin embargo, si el atacante codifica la dirección URL de destino de la siguiente manera:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

es posible que incluso un usuario final experimentado caiga en la trampa y siga el vínculo.

De forma predeterminada, la página de inicio de sesión de ASP.NET no permitirá la redirección de direcciones URL fuera del dominio hospedado durante el proceso de autenticación del usuario. Sin embargo, esta funcionalidad se puede modificar utilizando el parámetro aspnet:AllowRelaxedRelativeUrl para permitir la redirección de direcciones URL sin restricciones. Un atacante que aproveche con éxito esta vulnerabilidad podría redirigir a un usuario a un sitio web de su elección sin su consentimiento. El atacante podría entonces realizar un ataque de suplantación de identidad (phishing) para obtener información del usuario que no tenía la intención de revelar.

Ejemplo 1: en el siguiente ejemplo, aspnet:AllowRelaxedRelativeUrl está definido como true.

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

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto (Open Redirect) se producen cuando una aplicación web redirige a los clientes a una dirección URL arbitraria que puede estar controlada por un atacante.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: El siguiente código JSP indica al explorador del usuario que abra una dirección URL analizada desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

    ...
    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();
      }
    ...

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifique un sitio de confianza que conocen. Sin embargo, si el atacante codifica la dirección URL de destino mediante Hex de la siguiente manera:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D",

es posible que incluso un usuario final experimentado caiga en la trampa y siga el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades Open Redirect se producen cuando una aplicación web redirige a los clientes a una dirección URL arbitraria que pueda estar controlada por un atacante.

Los atacantes pueden utilizar ataques Open Redirect para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo: El siguiente código indica al explorador del usuario que abra una dirección URL analizada desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que será transferido al sitio de confianza. Sin embargo, cuando la víctima hace clic en el vínculo, el código del Example 1 redirecciona el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifique un sitio de confianza que conocen. Sin embargo, si el atacante codifica la dirección URL de destino mediante Hex de la siguiente manera:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D",

es posible que incluso un usuario final experimentado caiga en la trampa y siga el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto (Open Redirect) se producen cuando una aplicación web redirige a los clientes a una dirección URL arbitraria que puede estar controlada por un atacante.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: La siguiente definición de estado de flujo de Spring WebFlow indica al explorador del usuario que abra una dirección URL analizada desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifique un sitio de confianza que conocen. Sin embargo, si el atacante codifica la dirección URL de destino mediante Hex de la siguiente manera:
"http://trusted.example.com/ecommerce/redirect?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

es posible que incluso un usuario final experimentado caiga en la trampa y siga el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: el código JavaScript siguiente proporciona instrucciones al explorador del usuario para que abra una lectura de URL desde el parámetro de solicitud dest cuando un usuario hace clic en el enlace.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: el siguiente código PHP indica al explorador del usuario que abra una dirección URL analizada desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

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

Si una víctima recibe un correo electrónico que le indica que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.php?dest=www.wilyhacker.com", es probable que haga clic creyendo que el vínculo le transferirá al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/ecommerce/redirect.php?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: El siguiente procedimiento indica al navegador del usuario que abra una dirección URL analizada desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

      ...
      -- 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');
      ...
  

Si una víctima recibe un correo electrónico que le indica que siga un vínculo a "http://trusted.example.com/pls/hr/showemps?dest=www.wilyhacker.com", es probable que haga clic creyendo que el vínculo le transferirá al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/pls/hr/showemps?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: El siguiente código Python indica al explorador del usuario que abra una dirección URL que se analiza desde el parámetro de solicitud dest cuando un usuario haga clic en el vínculo.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: El código de Ruby siguiente indica al explorador del usuario que abra una dirección URL analizada desde el parámetro de solicitud dest.

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

Si una víctima recibe un mensaje de correo electrónico indicándole que siga un vínculo a "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", el usuario puede hacer clic en el mismo creyendo que se le redireccionará al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los redireccionamientos permiten a las aplicaciones web dirigir a los usuarios a distintas páginas dentro de la misma aplicación o a sitios externos. Las aplicaciones utilizan los redireccionamientos para ayudar con la navegación del sitio y, en algunos casos, para realizar un seguimiento de cómo los usuarios salen del sitio. Las vulnerabilidades de redireccionamiento abierto se producen cuando una aplicación web redirige a los clientes a cualquier dirección URL arbitraria que un usuario malintencionado pueda controlar.

Los atacantes pueden utilizar ataques de redireccionamiento abierto (Open Redirect) para engañar a los usuarios a que visiten una dirección URL en un sitio de confianza y redirigirlos a un sitio malintencionado. Mediante la codificación de la dirección URL, un atacante puede hacer que los usuarios finales tengan mayor dificultad para reconocer el destino malintencionado del redireccionamiento, incluso cuando se pasa como un parámetro de URL al sitio de confianza. A menudo se abusa de los redireccionamientos abiertos como parte de las estafas de suplantación de identidad (phishing) para recopilar datos confidenciales del usuario final.

Ejemplo 1: el código VB siguiente proporciona instrucciones al explorador del usuario para que abra una URL analizada desde el parámetro de solicitud dest cuando un usuario hace clic en el vínculo.

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

Si una víctima recibe un correo electrónico que le indica que siga un vínculo a "http://www.trustedsite.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", es probable que haga clic creyendo que el vínculo le transferirá al sitio de confianza. Sin embargo, cuando la víctima haga clic en el vínculo, el código del Example 1 redireccionará el explorador a "http://www.wilyhacker.com".

Se ha educado a muchos usuarios a que analicen siempre las direcciones URL que reciben en mensajes de correo electrónico para asegurarse de que el vínculo especifica un sitio de confianza que conocen. Sin embargo, si el usuario malintencionado codifica la dirección URL de destino mediante Hex como se indica a continuación:
"http://www.trustedsite.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

, incluso un usuario final más experimentado puede ser engañado en el vínculo.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo: el siguiente código lee una contraseña de un archivo de propiedades y utiliza la contraseña para establecer las credenciales de autenticación predeterminadas para las solicitudes de URL.

...
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);
...

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a config.properties puede leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se almacena sin cifrar en los archivos de configuración de una aplicación u otro almacén de datos.
Ejemplo: el siguiente código lee una contraseña del Registro y la utiliza para crear una nueva credencial de red.

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

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a la clave del registro utilizada para almacenar la contraseña puede leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se almacena sin cifrar en los archivos de configuración de una aplicación u otro almacén de datos.
Ejemplo: el código siguiente lee una contraseña en el registro y la utiliza para conectarse a una base de datos.

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

Este código se ejecutará correctamente, pero cualquier usuario con acceso a la llave de registro usada para almacenar la contraseña podrá leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo: el siguiente código lee una contraseña de un archivo de propiedades y utiliza la contraseña para conectarse a una base de datos.

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

EXEC SQL
  CONNECT :UID
  IDENTIFICADO POR :CONTRASEÑA
  AT :MYCONN
  USING :MYSERVER
END-EXEC.
...

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a CFG puede leer el valor de la contraseña. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando un usuario ha aceptado una contraseña o se ha almacenado como texto sin formato en los archivos de configuración o en la base de datos de una aplicación.
Ejemplo: el siguiente código lee una contraseña de un formulario web y utiliza la contraseña para conectarse a una base de datos.

<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>
...

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a la tabla master puede leer el valor de Username y Password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo 1: El siguiente código lee una contraseña de un archivo de JSON y la utiliza para establecer el encabezado de autorización de la solicitud:

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

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

Este código se ejecutará correctamente, pero cualquier usuario con acceso a config.json podrá leer el valor de values.Password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo 1: el siguiente código lee una contraseña de un archivo de propiedades y utiliza la contraseña para conectarse a una base de datos.

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

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

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a config.properties puede leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

En el entorno móvil, la administración de contraseñas es especialmente importante, puesto que hay altas posibilidades de perder un dispositivo.
Ejemplo 2: El siguiente código lee el nombre de usuario y la contraseña de un almacén WebView de Android y los usa para configurar la autenticación para ver páginas protegidas.

...
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);
  }
});
...

De manera predeterminada, las credenciales de WebView se almacenan en texto sin formato y no tienen hash. De modo que si un usuario tiene un dispositivo con acceso Root (o usa un emulador), podrá leer las contraseñas almacenadas de sitios determinados.

Los problemas de administración de contraseñas surgen cuando una contraseña se almacena con texto sin formato en una aplicación.
Ejemplo: el siguiente código utiliza una contraseña integrada en el código que conecta con una aplicación y recupera entradas de una libreta de direcciones:

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

Este código se ejecutará correctamente, pero cualquier persona que acceda a la página web que lo contiene puede ver la contraseña.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo: El código siguiente lee una contraseña de un archivo plist y la utiliza para descomprimir un archivo protegido con contraseña.

...
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];
...

En el entorno móvil, la administración de contraseñas es especialmente importante, puesto que hay altas posibilidades de perder un dispositivo.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo: el siguiente código lee una contraseña de un archivo de propiedades y utiliza la contraseña para conectarse a una base de datos.

...
$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());
}
...

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a config.properties puede leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha codificado o almacenado como texto sin formato en los archivos de configuración de una aplicación o en otro almacén de datos. Nunca es una buena idea codificar una contraseña. Codificar una contraseña no solo permite a todos los desarrolladores del proyecto ver la contraseña, sino que también hace que sea extremadamente difícil solucionar el problema. Una vez que el código está en producción, la contraseña no se puede cambiar sin aplicar revisiones al software. Si se pone en peligro la cuenta protegida por la contraseña, los propietarios del sistema deberán elegir entre la seguridad y la disponibilidad.
Ejemplo: el siguiente código autentica al usuario mediante la lectura de la contraseña que ha utilizado el usuario para iniciar sesión en el servidor de base de datos y la comparación con un valor esperado.

...
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;
...

Este código se ejecutará correctamente, pero cualquiera que tenga acceso a este tendrá acceso a la contraseña. Una vez que se haya distribuido el programa, no se podrá cambiar el usuario de base de datos "scott" con la contraseña "tiger", a menos que el programa tenga instaladas las revisiones. Un empleado con acceso a esta información podría utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo: el siguiente código lee una contraseña de un archivo de propiedades y utiliza la contraseña para conectarse a una base de datos.

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

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

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a config.properties puede leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se almacena sin cifrar en los archivos de configuración de una aplicación u otro almacén de datos.
Ejemplo: El código siguiente lee una contraseña en una variable de entorno y la utiliza para conectarse a una base de datos.

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

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a la variable de entorno utilizada para almacenar la contraseña puede leer el valor de PASSWD. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo 1: El código siguiente lee una contraseña de un archivo plist y la utiliza para descomprimir un archivo protegido con contraseña.

...
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"])
}
...

En el entorno móvil, la administración de contraseñas es especialmente importante, puesto que hay altas posibilidades de perder un dispositivo.

Los problemas de administración de contraseñas se producen cuando una contraseña se ha almacenado como texto sin formato en las propiedades o en el archivo de configuración de una aplicación.
Ejemplo: el siguiente código lee una contraseña de un archivo de propiedades y utiliza la contraseña para conectarse a una base de datos.

...
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 &";"
...

Este código se ejecutará correctamente, pero cualquier usuario que tenga acceso a config.properties puede leer el valor de password. Un empleado malintencionado con acceso a esta información puede utilizarla para irrumpir en el sistema.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo: Este código inicia una variable de contraseña vacía.

...
contraseña = ''.
...

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta establecer las credenciales de autenticación predeterminadas para las solicitudes de URL; para ello, proporciona una cadena vacía para una contraseña.

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

El código del Example 1 indica que la cuenta de usuario "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Ejemplo 2: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario.

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

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

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, entonces un usuario malintencionado podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para userPassword.

Nunca es una buena idea tener una contraseña vacía. Si la cuenta protegida por la contraseña vacía se ve comprometida, los propietarios del sistema deben elegir entre seguridad y disponibilidad, porque puede ser extremadamente difícil aplicar una revisión al sistema después de que el código esté en producción.

Ejemplo 1: El siguiente código utiliza una contraseña vacía para autenticar un certificado de cliente:

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

Si el código se ejecuta correctamente, indica que el certificado se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1:

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

Si el código del Example 1 es correcto, indica que el inicio de sesión de las credenciales de red "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Ejemplo 2: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario.

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

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

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, entonces un usuario malintencionado podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para userPassword.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Ejemplo 2: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario.

    ...
    char *stored_password = "";

    readPassword(stored_password);

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, entonces un usuario malintencionado podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para user_password.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticarse correctamente en otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña vacía. Si la contraseña vacía es simplemente un marcador de posición (hasta que se pueda asignar un valor legítimo a la variable), esto podría confundir a cualquiera poco familiarizado con el código y causar posibles problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario.

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, un atacante podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para userPassword.

En el entorno móvil, la administración de contraseñas es especialmente importante, puesto que hay altas posibilidades de perder un dispositivo.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticarse correctamente en otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña vacía. Si la contraseña vacía es simplemente un marcador de posición (hasta que se pueda asignar un valor legítimo a la variable), esto podría confundir a cualquiera poco familiarizado con el código y causar posibles problemas en rutas de flujo de control inesperadas.

Ejemplo: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del ejemplo es correcto, indica que la cuenta de usuario de la base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Ejemplo 2: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario.

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

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

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, entonces un usuario malintencionado podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para userPassword.

En el entorno móvil, la administración de contraseñas es especialmente importante, puesto que hay altas posibilidades de perder un dispositivo.
Ejemplo 3: El siguiente código inicializa las variables de nombre de usuario y contraseña como cadenas vacías, lee credenciales de un almacén WebView de Android si el servidor no las rechazó previamente para la solicitud actual y las usa para configurar la autenticación para ver páginas protegidas.

...
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);
  }
});
...

Al igual que con el Example 2, si useHttpAuthUsernamePassword() devuelve false, un usuario malintencionado podrá ver páginas protegidas si proporciona una contraseña vacía.

No es buena idea en ninguna circunstancia tener una contraseña vacía. Además, esto hace que arreglar el problema resulte extremadamente difícil una vez que el código está en fase de producción. La contraseña no se puede modificar sin aplicar revisiones al software. Si la cuenta protegida por la contraseña vacía está comprometida, los propietarios del sistema deberán elegir entre la seguridad y la disponibilidad.
Ejemplo: el código siguiente tiene una contraseña vacía para conectar con una aplicación y recuperar entradas de una libreta de direcciones:

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

Este código se ejecutará correctamente, pero cualquiera puede acceder si se conoce el nombre de usuario.

Nunca asigne una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticarse correctamente en un sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña vacía.

Ejemplo: El JSON siguiente inicia una contraseña vacía.

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

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. El uso de contraseñas vacías supone un punto débil importante en un sistema que, de otro modo, sería seguro. Incluso si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y podría causar problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía:

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

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Ejemplo 2: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario:

...
NSString *stored_password = "";

readPassword(stored_password);

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, entonces un usuario malintencionado podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para user_password.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del ejemplo es correcto, indica que la cuenta de usuario de la base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo: El código siguiente inicia una variable de contraseña vacía.

DECLARE
    contraseña VARCHAR(20);
BEGIN
    contraseña := "";
END;

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del ejemplo es correcto, indica que la cuenta de usuario de la base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

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

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Debido a la naturaleza dinámica de Ruby, muchas funciones también toman un número opcional de argumentos, de modo que puede establecerse "" como valor predeterminado de la contraseña cuando no se especifica ninguno. En este caso, también debe asegurarse de que se especifica el número correcto de argumentos para garantizar que la contraseña se pasa a la función.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. El uso de contraseñas vacías supone un punto débil importante en un sistema que, de otro modo, sería seguro. Incluso si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y podría causar problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía:

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

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.

Ejemplo 2: El siguiente código inicializa una variable de contraseña en una cadena vacía, intenta leer un valor almacenado para la contraseña y la compara con un valor proporcionado por el usuario:

...
var stored_password = ""

readPassword(stored_password)

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

Si readPassword() no puede recuperar la contraseña almacenada debido a un error de base de datos o a algún otro problema, entonces un usuario malintencionado podría eludir trivialmente la comprobación de contraseña si proporciona una cadena vacía para user_password.

Nunca es una buena idea asignar una cadena vacía a una variable de contraseña. Si la contraseña vacía se utiliza para autenticar correctamente frente a otro sistema, la seguridad de la cuenta correspondiente se verá probablemente comprometida ya que acepta una contraseña en vacía. Si la contraseña vacía es simplemente un marcador de posición hasta que se pueda asignar un valor legítimo a la variable, cualquiera poco familiarizado con el código podría confundirse y esto puede causar potencialmente problemas en rutas de flujo de control inesperadas.

Ejemplo 1: El siguiente código intenta conectarse a una base de datos con una contraseña vacía.

    ...
    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=;"
    ...

Si el código del Example 1 es correcto, indica que la cuenta de usuario de base de datos "scott" se ha configurado con una contraseña vacía, que un usuario malintencionado puede adivinar fácilmente. Una vez que se haya distribuido el programa, actualizar la cuenta para que utilice una contraseña que no esté vacía requerirá un cambio de código.