Um cookie de sessão persistente permanece válido mesmo depois que o usuário fecha o navegador e é muitas vezes usado como parte de um recurso de memorização de informações. Consequentemente, um cookie de sessão persistente permite que os usuários permaneçam autenticados em um aplicativo mesmo depois de fecharem seus navegadores, supondo que eles não tenham feito logout explicitamente. Isso significa que a próxima pessoa que abrir o navegador será automaticamente conectada como o último usuário. A menos que o seu aplicativo esteja implantado em um ambiente controlado, no qual os usuários não podem fazer login usando máquinas compartilhadas, é possível que os invasores comprometam as contas dos usuários mesmo depois que estes fecharem seus navegadores.
Exemplo 1: O código a seguir define o cookie de sessão para expirar em 10 anos.

session_set_cookie_params(time()+60*60*24*365*10, "/", "www.example.com", false, true);

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: Uma configuração que resulta na adição do cookie de sessão à resposta sem definir o sinalizador Secure.

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

Se o seu aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.
Exemplo 1: O seguinte código adiciona um cookie à resposta sem definir o sinalizador Secure.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Os navegadores da Web modernos oferecem suporte a um sinalizador Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados privados, identificadores de sessão, ou carrega um token CSRF.
Exemplo 1: Esta entrada de configuração não define explicitamente o bit Secure para os cookies de sessão.

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

Se um aplicativo usar HTTP e HTTPS, mas não definir o sinalizador Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.

Nunca codifique credenciais, incluindo nomes de usuário, senhas, chaves de API, segredos de API e tokens de API. As credenciais codificadas não apenas são visíveis para todos os desenvolvedores do projeto, mas também são extremamente difíceis de atualizar. Quando o código estiver em produção, as credenciais não poderão ser alteradas sem a aplicação de correção no software. Se as credenciais forem comprometidas, a organização deve escolher entre segurança e disponibilidade do sistema.

Nunca codifique credenciais, incluindo nomes de usuário, senhas, chaves de API, segredos de API e tokens de API. As credenciais codificadas não apenas são visíveis para todos os desenvolvedores do projeto, mas também são extremamente difíceis de atualizar. Quando o código estiver em produção, as credenciais não poderão ser alteradas sem a aplicação de correção no software. Se as credenciais forem comprometidas, a organização deve escolher entre segurança e disponibilidade do sistema.

Nunca é uma boa ideia inserir um nome de usuário em código fixo. Isso não só permite que todos os desenvolvedores do projeto visualizem o nome de usuário, como também dificulta extremamente a correção do problema. A partir do momento em que o código estiver em produção, o nome de usuário não poderá ser alterada sem uma aplicação de patch no software. Se a conta protegida pelo nome de usuário for comprometida, os proprietários do sistema serão forçados a escolher entre a segurança e a disponibilidade.
Exemplo 1: O seguinte código usa um nome de usuário inserido em código fixo para se conectar a um banco de dados:

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

Esse código será executado com êxito, mas qualquer usuário que tiver acesso a ele também terá acesso ao nome do usuário. 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.

Erros de File Permission Manipulation ocorrem quando qualquer uma das seguintes condições é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica as permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir usa entrada de variáveis de ambiente do sistema para definir permissões de arquivo. Se os invasores puderem alterar as variáveis de ambiente do sistema, poderão usar o programa para obter acesso a arquivos manipulados pelo programa. Se o programa também for vulnerável a Path Manipulation, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrariamente no sistema.

    permissions := strconv.Atoi(os.Getenv("filePermissions"));
    fMode := os.FileMode(permissions)
    os.chmod(filePath, fMode);
    ...

Erros de manipulação de permissões de arquivo ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir é projetado para definir as permissões de arquivo adequadas para os usuários fazerem upload de páginas da Web via FTP. Ele usa a entrada de uma solicitação HTTP para marcar um arquivo como visualizável para usuários externos.

	$rName = $_GET['publicReport'];
	chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...

No entanto, se um invasor fornecer um valor mal-intencionado para publicReport, como "../../localuser/public_html/.htpasswd", o aplicativo tornará o arquivo especificado como legível para o invasor.

Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para definir a máscara de permissão padrão. Se os invasores puderem alterar o arquivo de configuração, eles poderão usar o programa para obter acesso aos arquivos manipulados pelo programa. Se o programa também for vulnerável à manipulação de caminho, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.

...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...

Erros de File Permission Manipulation ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir usa entrada de variáveis de ambiente do sistema para definir permissões de arquivo. Se os invasores puderem alterar as variáveis de ambiente do sistema, eles poderão usar o programa para obter acesso a arquivos manipulados pelo programa. Se o programa também for vulnerável à Path Manipulation, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.

    permissions = os.getenv("filePermissions");
    os.chmod(filePath, permissions);
    ...

Erros de manipulação de permissões de arquivo ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir é projetado para definir as permissões de arquivo adequadas para os usuários fazerem upload de páginas da Web via FTP. Ele usa a entrada de uma solicitação HTTP para marcar um arquivo como visualizável para usuários externos.

...
  rName = req['publicReport']
  File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...

No entanto, se um invasor fornecer um valor mal-intencionado para publicReport, como "../../localuser/public_html/.htpasswd", o aplicativo tornará o arquivo especificado como legível para o invasor.

Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para definir a máscara de permissão padrão. Se os invasores puderem alterar o arquivo de configuração, eles poderão usar o programa para obter acesso aos arquivos manipulados pelo programa. Se o programa também for vulnerável à manipulação de caminho, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.

...
mask = config_params['perms']
File.chmod(filename, mask)
...

Os mecanismos de autenticação e autorização de um aplicativo podem ser contornados com adulteração dos verbos HTTP quando:
1) Ele usa um controle de segurança que lista os verbos HTTP.
2) O controle de segurança falha em bloquear verbos que não estão listados.
3) O aplicativo atualiza seu estado com base em solicitações GET ou outros verbos HTTP arbitrários.



A configuração a seguir é vulnerável a adulteração de verbo HTTP:

    <authorization>
        <allow verbs="GET,POST" users="admin"/>
        <deny verbs="GET,POST"users="*" />
    </authorization>

Por padrão, o .NET Framework permite todos os verbos HTTP e, portanto, mesmo que essa configuração negue GETs e POSTs para todos os usuários, que não impede solicitações HEAD. Talvez seja possível para um invasor usufruir de funcionalidades administrativas substituindo solicitações GET ou POST por solicitações HEAD. Em outras palavras, esse código satisfaz as condições 1 e 2 mencionadas anteriormente. Para que solicitações HEAD usufruam de funcionalidades administrativas, basta que o aplicativo realize comandos com base em solicitações que utilizam verbos diferentes de POST.

Basicamente, essa vulnerabilidade é o resultado de uma tentativa de criar uma lista de negação - uma política que especifica o que os usuários não têm permissão para fazer. Listas de negação raramente alcançam o efeito pretendido.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
    DATA: r TYPE REF TO cl_abap_random,
		  var1 TYPE i,
		  var2 TYPE i,
		  var3 TYPE n.


	GET TIME.
	var1 = sy-uzeit.
	r = cl_abap_random=>create( seed = var1 ).
	r->int31( RECEIVING value = var2 ).
	var3 = var2.
    CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.

Esse código usa a função CL_ABAP_RANDOM->INT31 para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como CL_ABAP_RANDOM é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

string GenerateReceiptURL(string baseUrl) {
    Random Gen = new Random();
    return (baseUrl + Gen.Next().toString() + ".html");
}

Esse código usa a função Random.Next() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.Next() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

char* CreateReceiptURL() {
    int num;
    time_t t1;
    char *URL = (char*) malloc(MAX_URL);
    if (URL) {
        (void) time(&t1);
        srand48((long) t1);     /* use time to set seed */
        sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
    }
    return URL;
}

Esse código usa a função lrand48() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como lrand48() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.


Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>

Esse código usa a função Rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis. No entanto, têm uma saída altamente previsível e formam um fluxo numérico fácil de reproduzir, o que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O seguinte código usa um PRNG estatístico para criar uma chave RSA.

import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)

Esse código usa a função rand.New() para gerar aleatoriedade para uma chave RSA. Como rand.New() é um PRNG estatístico, é fácil para um invasor adivinhar o valor que ele gera.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

function genReceiptURL (baseURL){
  var randNum = Math.random();
  var receiptURL = baseURL + randNum + ".html";
  return receiptURL;
}

Esse código usa a função Math.random() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Math.random() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

fun GenerateReceiptURL(baseUrl: String): String {
    val ranGen = Random(Date().getTime())
    return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}

Esse código usa a função Random.nextInt() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.nextInt() é um PRNG estatístico, é fácil para um invasor adivinhar as cadeias de caracteres que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

  function genReceiptURL($baseURL) {
    $randNum = rand();
    $receiptURL = $baseURL . $randNum . ".html";
    return $receiptURL;
  }

Esse código usa a função rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
  RETURN VARCHAR2
AS
  rnum VARCHAR2(48);
  time TIMESTAMP;
  url VARCHAR2(MAX_URL)
BEGIN
  time := SYSTIMESTAMP;
  DBMS_RANDOM.SEED(time);
  rnum := DBMS_RANDOM.STRING('x', 48);
  url := 'http://test.com/' || rnum || '.html';
  RETURN url;
END

Esse código usa a função DBMS_RANDOM.SEED() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como DBMS_RANDOM.SEED() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

    def genReceiptURL(self,baseURL):
        randNum = random.random()
        receiptURL = baseURL + randNum + ".html"
        return receiptURL

Esse código usa a função rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

def generateReceiptURL(baseUrl) {
  randNum = rand(400000000)
  return ("#{baseUrl}#{randNum}.html");
}

Esse código usa a função Kernel.rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Kernel.rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

def GenerateReceiptURL(baseUrl : String) : String {
    val ranGen = new scala.util.Random()
    ranGen.setSeed((new Date()).getTime())
    return (baseUrl + ranGen.nextInt(400000000) + ".html")
}

Esse código usa a função Random.nextInt() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.nextInt() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar um valor aleatório que é usado como um token de senha redefinido.

    sqlite3_randomness(10, &reset_token)

Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.

...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...

Esse código usa a função Rnd() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Rnd() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.

Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como a classe CL_ABAP_RANDOM ou suas variantes) for propagado com um valor constante específico, os valores retornados por GET_NEXT, INT e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas PRNG.

Exemplo 1: No trecho a seguir, os valores produzidos pelo objeto random_gen2 são previsíveis por meio do objeto random_gen1.

		DATA: random_gen1 TYPE REF TO cl_abap_random,
			  random_gen2 TYPE REF TO cl_abap_random,
			  var1 TYPE i,
			  var2 TYPE i.

		random_gen1 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen1->int
				RECEIVING
			value  = var1.

			WRITE:/ var1.
		ENDDO.

		random_gen2 = cl_abap_random=>create( seed = '1234' ).

		DO 10 TIMES.
			CALL METHOD random_gen2->int
				RECEIVING
			value  = var2.

			WRITE:/ var2.
		ENDDO.

Neste exemplo, os geradores de números pseudoaleatórios: random_gen1 e random_gen2 foram semeados de forma idêntica, então var1 = var2

Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como rand()) for propagado com um valor específico (usando uma função como srand(unsigned int)), os valores retornados por rand() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo gerador de números pseudoaleatórios são previsíveis nos dois primeiros blocos, pois ambos começam com o mesmo propagador.

        srand(2223333);
        float randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);
        randomNum = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum);

        srand(2223333);
        float randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);
        randomNum2 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum2);

        srand(1231234);
        float randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);
        randomNum3 = (rand() % 100);
        syslog(LOG_INFO, "Random: %1.2f", randomNum3);

Nesse exemplo, os resultados para randomNum1 e randomNum2 foram identicamente propagados e, portanto, cada chamada para rand() após a chamada que propaga o gerador de números pseudoaleatórios srand(2223333) resultará nas mesmas saídas, na mesma ordem de chamada. Por exemplo, a saída pode ser semelhante à seguinte:

Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00

Esses resultados estão longe de serem aleatórios.

Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (PRNG) for propagado com um valor específico (usando uma função como math.Rand.New(Source)), os valores retornados por math.Rand.Int() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas do PRNG.

Exemplo 1: Os valores produzidos pelo gerador de números pseudoaleatórios são previsíveis nos dois primeiros blocos, pois ambos começam com o mesmo propagador.

  randomGen := rand.New(rand.NewSource(12345))
  randomInt1 := randomGen.nextInt()
  
  randomGen.Seed(12345)
  randomInt2 := randomGen.nextInt()

Neste exemplo, os PRNGs foram propagados com o mesmo valor. Assim, cada chamada denextInt() após a chamada que iniciou a propagação do gerador de números pseudoaleatórios (randomGen.Seed(12345)) resultará nas mesmas saídas, na mesma ordem.

Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como Random) for propagado com um valor específico (usando uma função como Random(Int)), os valores retornados por Random.nextInt() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo objeto RandomrandomGen2 são previsíveis com base no objeto RandomrandomGen1.

        val randomGen1 = Random(12345)
        val randomInt1 = randomGen1.nextInt()
        val byteArray1 = ByteArray(4)
        randomGen1.nextBytes(byteArray1)

        val randomGen2 = Random(12345)
        val randomInt2 = randomGen2.nextInt()
        val byteArray2 = ByteArray(4)
        randomGen2.nextBytes(byteArray2)

Neste exemplo, os geradores de números pseudoaleatórios: randomGen1 e randomGen2 foram propagados de forma idêntica e, portanto, randomInt1 == randomInt2 e os valores correspondentes dos arrays byteArray1 e byteArray2 são iguais.

As funções que geram valores pseudoaleatórios, que são passados a uma semente, não devem ser chamadas com um argumento inteiro constante. Se um gerador de números pseudoaleatórios for semeado com um valor específico, os valores devolvidos serão previsíveis.

Exemplo 1: Os valores produzidos pelo gerador de números pseudoaleatórios são previsíveis nos dois primeiros blocos, pois ambos começam com o mesmo propagador.

...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...

Nesse exemplo, os PRNGs foram semeados de maneira idêntica, para que cada chamada de randint() feita depois da chamada que semeou o gerador de números pseudoaleatórios (random.seed(123456)), resulte nas mesmas saídas na mesma ordem. Por exemplo, a saída pode ser semelhante à seguinte:

Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3

Esses resultados estão longe de serem aleatórios.

Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como Random) for propagado com um valor específico (usando uma função como Random.setSeed()), os valores retornados por Random.nextInt() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo objeto RandomrandomGen2 são previsíveis com base no objeto RandomrandomGen1.

        val randomGen1 = new Random()
        randomGen1.setSeed(12345)
        val randomInt1 = randomGen1.nextInt()
        val bytes1 = new byte[4]
        randomGen1.nextBytes(bytes1)

        val randomGen2 = new Random()
        randomGen2.setSeed(12345)
        val randomInt2 = randomGen2.nextInt()
        val bytes2 = new byte[4]
        randomGen2.nextBytes(bytes2)

Neste exemplo, os geradores de números pseudoaleatórios: randomGen1 e randomGen2 foram propagados de forma idêntica e, portanto, randomInt1 == randomInt2 e os valores correspondentes dos arrays bytes1[] e bytes2[] são iguais.

A classe CL_ABAP_RANDOM (ou suas variantes) não deve ser inicializada com um argumento corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores produzidos por chamadas para métodos, incluindo, sem limitações: GET_NEXT, INT, FLOAT, PACKED.

Funções que geram valores aleatórios ou pseudoaleatórios (como rand()), que são transmitidos para um propagador (como srand()), não devem ser chamadas com um argumento corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para esse gerador.

Funções que geram valores pseudoaleatórios, como ed25519.NewKeyFromSeed(), não devem ser chamadas com um argumento impróprio. Caso contrário, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e prever a sequência de valores produzidos por esse gerador.

Random.setSeed() não devem ser chamadas com um argumento de número inteiro corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para Random.nextInt(), Random.nextLong(), Random.nextDouble(), retornadas por Random.nextBoolean() ou definidas em Random.nextBytes(ByteArray).

Funções que geram valores de pseudoaleatórios (tais como random.randint()); não deve ser chamado com um argumento contaminado. Isso permite a um invasor controlar o valor usado para semear o gerador de números pseudoaleatórios, e, portanto, ser capaz de prever a sequência de valores (geralmente inteiros) produzida pelas chamadas do gerador de números pseudoaleatórios.

Random.setSeed() não devem ser chamadas com um argumento de número inteiro corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para Random.nextInt(), Random.nextShort(), Random.nextLong(), retornadas por Random.nextBoolean() ou definidas em Random.nextBytes(byte[]).

A falta de uma fonte apropriada de entropia para uso pelo gerador de números aleatórios ou pseudoaleatórios pode resultar em uma negação de serviço ou na geração de sequências de números previsíveis. Se o gerador de números aleatórios ou pseudoaleatórios usar uma fonte de entropia que venha a se esgotar, o programa poderá pausar ou até mesmo travar, resultando em uma negação de serviço. Como alternativa, o gerador de números aleatórios ou pseudoaleatórios pode gerar números previsíveis. Uma fonte fraca de números aleatórios pode levar a vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves de criptográficas previsíveis, sequestro de sessão, e falsificação de DNS.

Exemplo 1: O seguinte código usa o relógio do sistema como fonte de entropia:

...
import time
import random

random.seed(time.time())
...

Como o relógio do sistema gera valores previsíveis, ele não é uma boa fonte de entropia. O mesmo vale para outras fontes de aleatoriedade não baseadas em hardware, incluindo buffers de sistema/entrada/saída, números de série ou endereços de usuário/sistema/hardware/rede e também entradas de usuários.