Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código C# usa JSON.NET para serializar informações de autenticação de conta de usuário para usuários não privilegiados (com a função "default", em oposição a usuários privilegiados com a função "admin") a partir das variáveis de entrada controladas pelo usuário username e password para o arquivo JSON localizado em 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());

Ainda assim, como serialização JSON é realizada com o uso de JsonWriter.WriteRawValue(), os dados não confiáveis em username e password não serão validados para o escape de caracteres especiais relacionados ao JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Neste exemplo, se o usuário não privilegiado mallory com a senha Evil123! fosse acrescentar ","role":"admin ao seu nome de usuário ao inseri-lo no prompt que define o valor da variável username, o JSON salvo em C:\user_info.json seria:

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

Se esse arquivo JSON serializado fosse então desserializado em um objeto Dictionary com JsonConvert.DeserializeObject(), da seguinte maneira:

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

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

Os valores resultantes para as chaves username, password e role no objeto Dictionary seriam mallory, Evil123! e admin, respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário mallory.

Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando destinado a enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode transmitir informações confidenciais, como credenciais de autenticação.

Invasores podem alterar a semântica de documentos e mensagens JSON se um aplicativo JSON for construído a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em casos mais graves, como aqueles que envolvem uma injeção de JSON, um invasor pode inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Às vezes, a injeção de JSON pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1: O seguinte código serializa as informações de autenticação da conta de usuário para usuários não privilegiados (aqueles com uma função de "default", em oposição aos usuários privilegiados com uma função de "admin") de variáveis de entrada controladas por usuário username e password para o arquivo JSON localizado em ~/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)
    }
    

Como o código executa a serialização JSON usando concatenação, os dados não confiáveis em username e password não serão validados para realizar escape de caracteres especiais relacionados a JSON. Isso permite que um usuário insira chaves JSON arbitrárias, podendo modificar a estrutura serializada JSON. Neste exemplo, se o usuário não privilegiado mallory com a senha Evil123! anexou ","role":"admin quando ela inseriu seu nome de usuário, o JSON resultante salvo para ~/user_info.json seria:

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

Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá involuntariamente os privilégios "admin" ao usuário mallory.

Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código Java usa Jackson para serializar informações de autenticação de conta de usuário para usuários não privilegiados (com a função "default", em oposição a usuários privilegiados com a função "admin") a partir das variáveis de entrada controladas pelo usuário username e password para o arquivo JSON localizado em ~/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();

Ainda assim, como serialização JSON é realizada com o uso de JsonGenerator.writeRawValue(), os dados não confiáveis em username e password não serão validados para o escape de caracteres especiais relacionados ao JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Neste exemplo, se o usuário não privilegiado mallory com a senha Evil123! fosse acrescentar ","role":"admin ao seu nome de usuário ao inseri-lo no prompt que define o valor da variável username, o JSON salvo em ~/user_info.json seria:

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

Se esse arquivo JSON serializado fosse então desserializado em um objeto HashMap com JsonParser do Jackson, da seguinte maneira:

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

Os valores resultantes para as chaves username, password e role no objeto HashMap seriam mallory, Evil123! e admin, respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário mallory.

Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: Este código JavaScript usa jQuery para analisar o JSON no qual um valor vem de uma 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 + '"}');
    ...
  }
  ...
});

Aqui os dados não confiáveis em name não serão validados para escapar dos caracteres especiais relacionadas com o JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Neste exemplo, se o usuário não privilegiado mallory acrescentasse ","role":"admin ao parâmetro nome na URL, o JSON se tornaria:

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

Ele é analisado pelo jQuery.parseJSON() e definido como um objeto simples, o que significa que obj.role retornaria agora "admin" em vez de "user"

Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: Este código Objective-C serializa as informações de autenticação de conta para usuários não privilegiados (aqueles com uma função "padrão" em vez dos usuários privilegiados, com uma função de "admin") em JSON a partir dos campos controlados pelo usuário _usernameField e _passwordField:

...

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

Ainda assim, como serialização JSON é realizada com o uso de NSString.stringWithFormat:, os dados não confiáveis em _usernameField e _passwordField não serão validados para o escape de caracteres especiais relacionados ao JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Nesse exemplo, se o usuário não privilegiado mallory com a senha Evil123! anexasse ","role":"admin ao nome de usuário dele ao digitá-lo no campo _usernameField, o JSON resultante seria:

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

Se essa cadeia JSON serializada fosse então desserializada para um objetoNSDictionary com NSJSONSerialization.JSONObjectWithData: desta maneira:

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

Os valores resultantes de username, password, e role no objeto NSDictionary seriam mallory, Evil123!, e admin respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário mallory.

Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode potencialmente conter informações confidenciais. Quando destinado a enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço RESTful e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON poderá ser alterada se um aplicativo construir JSON com base em uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou solicitação JSON. Em um caso mais graves, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em um documento ou solicitação JSON. Em alguns casos, a injeção de JSON pode até mesmo provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo: O seguinte código python atualiza um arquivo json com um valor não confiável originário de uma 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)

...

Aqui, os dados não confiáveis em name não serão validados para aplicar o escape de caracteres especiais relacionados a JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente alterando a estrutura do JSON serializado. Nesse exemplo, se o usuário não privilegiado mallory anexasse ","role":"admin ao parâmetro name na URL, o JSON se tornaria:

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

O arquivo JSON agora é adulterado com dados mal-intencionados e o usuário tem acesso privilegiado de "admin" em vez de "user"

Uma injeção de JSON ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um fluxo JSON.

Em geral, os aplicativos usam o JSON para armazenar dados ou enviar mensagens. Quando usado para armazenar dados, o JSON é frequentemente tratado como dados em cache e pode conter informações confidenciais. Quando usado para enviar mensagens, o JSON é frequentemente usado em conjunto com um serviço com reconhecimento de REST e pode ser usado para transmitir informações confidenciais, como credenciais de autenticação.

A semântica de documentos e mensagens JSON pode ser alterada quando um aplicativo constrói o JSON a partir de uma entrada não validada. Em um caso relativamente favorável, um invasor pode ser capaz de inserir elementos estranhos que fazem com que um aplicativo lance uma exceção durante a análise de um documento ou de uma solicitação JSON. Em um caso mais grave, como aqueles que envolvem uma injeção de JSON, um invasor pode ser capaz de inserir elementos estranhos que permitem a manipulação previsível de valores críticos para os negócios em uma solicitação ou um documento JSON. Em alguns casos, a injeção de JSON pode provocar cross-site scripting ou avaliação de código dinâmico.

Exemplo 1: O seguinte código Swift serializa as informações de autenticação de conta dos usuários não privilegiados (aqueles com uma função “padrão”, em vez dos usuários privilegiados com uma função “admin”) para o JSON a partir dos campos controlados pelo usuário usernameField e passwordField:

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

Ainda assim, como a serialização JSON é realizada usando interpolação, os dados não confiáveis em usernameField e passwordField não serão validados para realizar escape dos caracteres especiais relacionados a JSON. Isso permite que um usuário insira chaves JSON arbitrariamente, possivelmente mudando a estrutura do JSON serializado. Nesse exemplo, se o usuário não privilegiado mallory com a senha Evil123! anexasse ","role":"admin ao nome de usuário dele ao digitá-lo no campo usernameField, o JSON resultante seria:

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

Se essa cadeia JSON serializada fosse então desserializada para um objetoNSDictionary com NSJSONSerialization.JSONObjectWithData: desta maneira:

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

Os valores resultantes de username, password, e role no objeto NSDictionary seriam mallory, Evil123!, e admin respectivamente. Sem a verificação adicional de que os valores JSON desserializados são válidos, o aplicativo atribuirá incorretamente os privilégios "admin" ao usuário mallory.

O aplicativo falha ao validar o tipo de dados recebidos de um formulário da web. É uma boa prática validar se os dados recebidos satisfazem as exigências definidas para os dados esperados.

Exemplo 1: O código a seguir define um Spring WebFlow FormAction que não consegue validar os dados em relação às exigências esperadas:

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

Exemplo 2: O código a seguir define o estado de uma ação do Spring WebFlow que não consegue validar os dados em relação às exigências esperadas:

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

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte código ABAP instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro de solicitação dest quando esse usuário clica no link.

...
DATA: str_dest TYPE c.

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

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte código ActionScript instrui o navegador do usuário a abrir uma URL lida a partir do parâmetro de solicitação dest quando esse usuário clica no link.

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

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.

Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing. Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos usam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que um invasor possa controlar.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O método de ação a seguir do Visualforce retorna um objeto PageReference que consiste em uma URL do parâmetro de solicitação dest.

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

Se a vítima receber um email instruindo o usuário a seguir um link para "http://trusted.vf.force.com/apex/vfpage?dest=www.wilyhacker.com", esse usuário poderá clicar no link acreditando que acessará um site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails e garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.

Por padrão, a página de login do ASP.NET não permitirá o redirecionamento do URL para fora do domínio hospedado durante o processo de autenticação do usuário. No entanto, essa funcionalidade pode ser modificada usando a configuração aspnet:AllowRelaxedRelativeUrl para permitir o redirecionamento irrestrito do URL. Um invasor que explorar com êxito esta vulnerabilidade poderá redirecionar um usuário a um site da escolha do invasor sem o consentimento do usuário. O invasor pode então realizar um ataque de phishing para obter informações do usuário que ele não pretendia divulgar.

Exemplo 1: No exemplo a seguir, aspnet:AllowRelaxedRelativeUrl está definido como true.

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

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que pode ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O código JSP a seguir instrui o navegador do usuário a abrir uma URL analisada com base no parâmetro de solicitação dest quando esse usuário clica no 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();
      }
    ...

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que um invasor possa controlar.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo: O código a seguir instrui o navegador do usuário a abrir uma URL analisada com base no parâmetro de solicitação dest quando esse usuário clica no link.

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

Se uma vítima receber um email instruindo-a a seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", o usuário provavelmente clicará no link, acreditando que será transferido para o site confiável. No entanto, quando ele clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que pode ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: A seguinte definição de estado de fluxo Spring WebFlow instrui o navegador do usuário a abrir um URL analisado com base no parâmetro de solicitação dest quando esse usuário clica no link.

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

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Esse código JavaScript instrui o navegador do usuário a abrir uma URL lida a partir do parâmetro de solicitação dest quando um usuário clica no link.

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

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O código PHP a seguir instrui o navegador do usuário a abrir uma URL analisada do parâmetro de solicitação dest quando um usuário clica no link.

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

Se o usuário tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.php?dest=www.wilyhacker.com", ele provavelmente clicará nesse link acreditando que será transferido ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.php?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

e até mesmo um usuário experiente poderia ser enganado a clicar no link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Este procedimento instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest quando um usuário clica no 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');
      ...
  

Se o usuário tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/pls/hr/showemps?dest=www.wilyhacker.com", ele provavelmente clicará nesse link acreditando que será transferido ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/pls/hr/showemps?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Este código Python instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest quando um usuário clica no link.

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

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Este código Ruby instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest:

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

Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.

Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte código VB instrui o navegador do usuário para abrir uma URL analisada do parâmetro de solicitação dest quando um usuário clica no link.

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

Se o usuário tiver recebido um email com instruções para seguir um link para ""http://www.trustedsite.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ele provavelmente clicará nesse link acreditando que será transferido ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://www.trustedsite.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente pode ser levado a clicar no link.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo: O código a seguir lê uma senha de um arquivo de propriedades e a utiliza para definir credenciais de autenticação padrão para solicitações 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);
...

Esse código será executado com êxito, mas qualquer pessoa com acesso a config.properties poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação nos arquivos de configuração ou em outro repositório de dados de um aplicativo.
Exemplo: O código a seguir lê uma senha do registro e a utiliza para criar uma nova credencial de senha.

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

Esse código será executado com êxito, mas qualquer usuário que tenha acesso à chave do registro usada para armazenar a senha poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação nos arquivos de configuração ou em outro repositório de dados de um aplicativo.
Exemplo: O código a seguir lê uma senha do registro e a utiliza para se conectar a um banco de dados.

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

Este código será executado com êxito, mas qualquer pessoa que tenha acesso à chave do Registro usada para armazenar a senha poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações pode usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo: O código a seguir lê uma senha de um arquivo de propriedades e a usa para se conectar a um banco de dados.

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

Esse código será executado com êxito, mas qualquer pessoa com acesso a CFG pode ler o valor da senha. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é aceita de um usuário ou é armazenada em texto sem formatação nos arquivos de configuração ou no banco de dados de um aplicativo.
Exemplo: O código a seguir lê uma senha de um formulário da Web e a utiliza para se conectar a um banco de dados.

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

Esse código será executado com êxito, mas qualquer usuário que tiver acesso à tabela master poderá ler o valor de Username e Password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo 1: O seguinte código lê uma senha de um arquivo JSON e a usa para definir o cabeçalho de autorização da solicitação:

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

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

Esse código será executado com êxito, mas qualquer pessoa com acesso a config.json poderá ler o valor de values.Password. Qualquer funcionário desonesto com acesso a essas informações pode usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo 1: O código a seguir lê uma senha de um arquivo de propriedades e a usa para se conectar a um banco de dados.

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

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

Esse código será executado com êxito, mas qualquer pessoa com acesso a config.properties poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

No ambiente móvel, o gerenciamento de senhas é especialmente importante, pois há uma grande chance de perda do dispositivo.
Exemplo 2: O código a seguir lê o nome do usuário e a senha de um repositório WebView do Android e os utiliza de forma a configurar a autenticação para a visualização de 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);
  }
});
...

Por padrão, credenciais WebView são armazenadas em texto sem formatação e não estão em hash. Portanto, se um usuário tiver um dispositivo root (ou usar um emulador), ele será capaz de ler as senhas armazenadas para determinados sites.

Os problemas de gerenciamento ocorrem quando uma senha é armazenada em texto simples em um aplicativo.
Exemplo: Este código usa uma senha codificada para se conectar a um aplicativo e recuperar as entradas do catálogo de endereços:

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

Este código será executado com sucesso, mas qualquer pessoa que acessar a página da Web que o contém poderá visualizar a senha.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo: O código a seguir lê uma senha de um arquivo plist e a usa para descompactar um arquivo protegido por senha.

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

No ambiente móvel, o gerenciamento de senhas é especialmente importante, pois há uma grande chance de perda do dispositivo.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo: O código a seguir lê uma senha de um arquivo de propriedades e a usa para se conectar a um banco de dados.

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

Esse código será executado com êxito, mas qualquer pessoa com acesso a config.properties poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Os problemas de gerenciamento de senhas ocorrem quando uma senha é codificada ou armazenada em texto simples nos arquivos de configuração ou em outros repositórios de dados de um aplicativo. Nunca é uma boa ideia inserir uma senha em código fixo. Isso não só permite que todos os desenvolvedores do projeto visualizem a senha, como também dificulta extremamente a correção do problema. Depois que o código estiver em produção, a senha não poderá ser alterada sem uma aplicação de patch no software. Se a conta protegida pela senha estiver comprometida, os proprietários do sistema deverão escolher entre a segurança e a disponibilidade
Exemplo: Este código autentica o usuário ao ler a senha que o usuário digitou para fazer login no servidor de banco de dados e compará-la a um 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;
...

Esse código será executado com êxito, mas qualquer usuário que tiver acesso a ele também terá acesso à senha. Depois que o programa é distribuído, provavelmente não há como alterar o usuário de banco de dados “scott” com a senha “tigre”, a não ser que um patch seja aplicado ao programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo: O código a seguir lê uma senha de um arquivo de propriedades e a usa para se conectar a um banco de dados.

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

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

Esse código será executado com êxito, mas qualquer pessoa com acesso a config.properties poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação nos arquivos de configuração ou em outro repositório de dados de um aplicativo.
Exemplo: Este código lê uma senha a partir de uma variável de ambiente e a utiliza para se conectar a um banco de dados.

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

Esse código será executado com êxito, mas qualquer usuário que tenha acesso à variável do ambiente usada para armazenar a senha poderá ler o valor de PASSWD. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo 1: O código a seguir lê uma senha de um arquivo plist e a usa para descompactar um arquivo protegido por senha.

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

No ambiente móvel, o gerenciamento de senhas é especialmente importante, pois há uma grande chance de perda do dispositivo.

Problemas de gerenciamento de senha ocorrem quando uma senha é armazenada em texto sem formatação no arquivo de configuração ou nas propriedades de um aplicativo.
Exemplo: O código a seguir lê uma senha de um arquivo de propriedades e a usa para se conectar a um banco de dados.

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

Esse código será executado com êxito, mas qualquer pessoa com acesso a config.properties poderá ler o valor de password. Qualquer funcionário desonesto com acesso a essas informações poderá usá-las para invadir o sistema.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo: Este código inicializa uma variável de senha vazia.

...
password = ''.
...

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir tenta definir credenciais de autenticação padrão para solicitações de URL, fornecendo uma string vazia para uma senha.

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

O código no Example 1 indica que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Exemplo 2: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário.

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

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

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para userPassword.

Nunca é uma boa ideia ter uma senha vazia. Se a conta protegida pela senha vazia for comprometida, os proprietários do sistema deverão escolher entre segurança e disponibilidade porque poderá ser extremamente difícil corrigir o sistema depois que o código estiver em produção.

Exemplo 1: O seguinte código usa uma senha vazia para autenticar um certificado de cliente:

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

Se o código for executado com êxito, ele indicará que o certificado está configurado com uma senha vazia, que um invasor pode adivinhar facilmente.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1:

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

Se o código no Example 1 for bem-sucedido, ele indica que o login de credencial da rede "scott" está configurado com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Exemplo 2: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário.

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

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

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para userPassword.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Exemplo 2: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário.

    ...
    char *stored_password = "";

    readPassword(stored_password);

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para user_password.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário.

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para userPassword.

No ambiente móvel, o gerenciamento de senhas é especialmente importante, pois há uma grande chance de perda do dispositivo.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Exemplo for bem-sucedido, ele indica que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Exemplo 2: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário.

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

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

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para userPassword.

No ambiente móvel, o gerenciamento de senhas é especialmente importante, pois há uma grande chance de perda do dispositivo.
Exemplo 3: O código a seguir inicializa as variáveis de nome de usuário e senha para strings vazias, lê as credenciais de um repositório WebView do Android caso elas não tenham sido rejeitadas anteriormente pelo servidor para a requisição atual e as utiliza de forma a configurar a autenticação para a visualização de 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);
  }
});
...

Semelhante ao Example 2, se useHttpAuthUsernamePassword() retornar false, o invasor será capaz de visualizar páginas protegidas fornecendo uma senha vazia.

Nunca é uma boa ideia ter uma senha nula. Isso também faz com que corrigir o problema seja extremamente difícil, uma vez que o código está em produção. A senha não pode ser alterada sem fazer um patch do software. Se a conta protegida pela senha vazia estiver comprometida, os proprietários do sistema deverão escolher entre a segurança e a disponibilidade
Exemplo: Este código usa uma senha vazia para se conectar a um aplicativo e recuperar as entradas do catálogo de endereços:

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

Este código será executado com êxito, mas qualquer pessoa que saiba o nome de usuário poderá acessá-lo.

Nunca atribua uma string vazia a uma variável de senha. Se a senha vazia for usada para fins de autenticação em um sistema, isso significa que a segurança da conta correspondente provavelmente está comprometida, uma vez que ela aceita uma senha vazia.

Exemplo: O JSON a seguir inicializa uma de senha vazia.

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

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. O uso de senhas vazias pode introduzir um ponto de fraqueza significativo em um sistema que, de outra forma, seria seguro. Mesmo que a senha vazia seja apenas um espaço reservado até que um valor legítimo possa ser atribuído à variável, pode confundir alguém familiarizado com o código e pode causar problemas em caminhos de fluxo de controle inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia:

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Exemplo 2: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário:

...
NSString *stored_password = "";

readPassword(stored_password);

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para user_password.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Exemplo for bem-sucedido, ele indica que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo: O código a seguir inicializa uma variável de senha vazia.

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

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Exemplo for bem-sucedido, ele indica que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Devido à natureza dinâmica do Ruby, muitas funções também têm uma quantidade opcional de argumentos, portanto, a senha pode ser definida como "" e como um valor padrão quando não houver um especificado. Nesse caso você também precisa certificar-se de que a quantidade certa de argumentos seja especificada para ter certeza de que uma senha seja passada para a função.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. O uso de senhas vazias pode introduzir um ponto de fraqueza significativo em um sistema que, de outra forma, seria seguro. Mesmo que a senha vazia seja apenas um espaço reservado até que um valor legítimo possa ser atribuído à variável, pode confundir alguém familiarizado com o código e pode causar problemas em caminhos de fluxo de controle inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia:

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.

Exemplo 2: O código a seguir inicializa uma variável de senha para uma cadeia vazia, tenta ler um valor armazenado para a senha, e a compara com um valor fornecido pelo usuário:

...
var stored_password = ""

readPassword(stored_password)

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

Se readPassword() não conseguir recuperar a senha armazenada devido a um erro de banco de dados ou outro problema, um invasor poderá se esquivar trivialmente da verificação de senha fornecendo uma cadeia vazia para user_password.

Nunca é uma boa ideia atribuir uma string vazia a uma variável de senha. Se a senha vazia for usada com sucesso para autenticação em outro sistema, significa que a segurança da conta correspondente provavelmente está comprometida, pois ela aceita uma senha vazia. Se a senha vazia for um mero espaço reservado até que um valor legítimo possa ser atribuído à variável, isso poderá confundir qualquer usuário que não esteja familiarizado com o código, além de possivelmente causar problemas em caminhos de controle de fluxo inesperados.

Exemplo 1: O código a seguir tenta se conectar a um banco de dados com uma senha vazia.

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

Se o código no Example 1 for bem-sucedido, ele indicará que a conta de usuário de banco de dados "scott" está configurada com uma senha vazia, que um invasor pode adivinhar facilmente. Depois que o programa for distribuído, a atualização da conta para usar uma senha não vazia exigirá uma mudança de código.