Ocultar paramentros na url

[Thiago Gonçalves Fonseca 0]

PARÂMETROS

 

Fiz um sistema para alterar a senha do usuário, agora quero ocultar os parâmetros que aparecem na url:

 

http://site.com.br/site/pg/usuario/editar.php?id_login=15

 

gostaria de ocultar o código ou criptografar ele, os dados são passados via GetPost $nome = getPost('nome');

 

 

$senha = getPost('senha');


<input name="hddCodigo" type="hidden" value="<?php echo htmlspecialchars($id) ?>" />

 

Algum poderia me ajudar?

[Alaerte Gabriel 662]

getpost ? desconheço, a menos que você esteja utilizando uma função.

 

Se é para trocar a senha do próprio usuário, passe os dados via POST, ou então trabalhe com requisições assíncronas (AJAX)

[mangakah 217]

O correto é armazenar dados sensíveis em variáveis de sessão.

[Alaerte Gabriel 662]

O correto é armazenar dados sensíveis em variáveis de sessão.

 

O correto é que fique de modo seguro e não visível. Sessões são o mesmo que cookies temporários que são removidos no ato do fechamento do broswer, poderia facilmente ter os dados interceptados, e em ambas as situações.

[mangakah 217]

E neste caso requer persistência?

 

É possível definir uma persistência para o cookie de sessão:

ini_set('session.cookie_lifetime', 60 * 60 * 48); // 48 horas

[Wanderson Valerio 102]

base64_encode(); para encriptar, e base64_decode(); para desencriptar.

 

base64_encode("Minha string");
// TWluaGEgc3RyaW5n
base64_decode("TWluaGEgc3RyaW5n");
// Minha string

[Alaerte Gabriel 662]

É justamente ao contrário... já que se trata de dados seguros, não deveria ter perssistência na sessão.

 

base64_encode(); e decode, iriam criptografar mais não iria esconder a URL.

 

Ou seja, ou POST com requisição Assíncrona ou então pode ser get, criptografado e assíncrona... de modo quê o retorno seria imediato para uma div expecífica, mais o interessante é travar o endereço.

[mangakah 217]

É justamente ao contrário... já que se trata de dados seguros, não deveria ter perssistência na sessão.

 

Sim, concordo. Mas foi você quem falou que armazenar dados em variáveis de sessão não seria adequando a este caso pois eles não seriam persistentes... e falou também que dados de sessões poderiam ser interceptados, se entendi bem. Eu sei que sessões podem ser sequestradas em um ataque chamado Session Hijacking (na verdade o ataque é feito ao cookie que armazena o id da sessão, que é roubado e usado para capturar a sessão), mas nunca ouvi falar que dados de sessão poderiam ser interceptados... como seria isso?

 

base64_encode(); e decode, iriam criptografar mais não iria esconder a URL.

 

Na verdade base64 é uma codificação (encoding) de dados, não uma criptografia (encryption).

 

Ou seja, ou POST com requisição Assíncrona ou então pode ser get, criptografado e assíncrona... de modo quê o retorno seria imediato para uma div expecífica, mais o interessante é travar o endereço.

 

Enviar dados via POST não significa que esses dados não poderão ser vistos ou que estarão seguros. Embora eles não apareçam na URL, como em GET, esses dados pode ser facilmente inspecionados usando ferramentas de desenvolvimento (Firebug e cia). O mesmo vale para requisições via XHR, seja GET ou POST.

 

Criptografia pode ser, mas eu acho mais prático armazenar o dado em questão, o ID do usuário na tabela, se não me engano, em uma variável de sessão ou refazer a consulta ao banco de dados.

[Alaerte Gabriel 662]

Sim, concordo. Mas foi você quem falou que armazenar dados em variáveis de sessão não seria adequando a este caso pois eles não seriam persistentes... e falou também que dados de sessões poderiam ser interceptados, se entendi bem. Eu sei que sessões podem ser sequestradas em um ataque chamado Session Hijacking (na verdade o ataque é feito ao cookie que armazena o id da sessão, que é roubado e usado para capturar a sessão), mas nunca ouvi falar que dados de sessão poderiam ser interceptados... como seria isso?

 

 

 

Na verdade base64 é uma codificação (encoding) de dados, não uma criptografia (encryption).

 

 

 

Enviar dados via POST não significa que esses dados não poderão ser vistos ou que estarão seguros. Embora eles não apareçam na URL, como em GET, esses dados pode ser facilmente inspecionados usando ferramentas de desenvolvimento (Firebug e cia). O mesmo vale para requisições via XHR, seja GET ou POST.

 

Criptografia pode ser, mas eu acho mais prático armazenar o dado em questão, o ID do usuário na tabela, se não me engano, em uma variável de sessão ou refazer a consulta ao banco de dados.

 

Entendeu errado a primeira parte, não disse nada sobre perssistência nas sessões. Em momento algum eu disse que pelo método POST os dados seriam ocultos, é uma questão de o usuário não "visualizar" o endereço pela URL, e não ocultação de dados.

 

Você mesmo drescreveu uma forma de interceptar dados de uma sessão, isso é uma interceptação, de certo modo. :thumbsup:

 

Tecnicamente falando, os nomes corretos para cada tipo de ação das funções base64, realmente é encoding, mais pra um bom entendedor meia palavra basta, as diferenças de criptografia e codificação são muitas, porém, assim por dizer e por força de expressão as chamo de criptografia.

 

Outra questão seria ficar "ocupando" a memória do servidor com sessões, quando um simples método post resolveria, não ?

 

Bom, que o dono do tópico avalie e veja o que cobre a sua necessidade.

[mangakah 217]

Entendeu errado a primeira parte, não disse nada sobre perssistência nas sessões. Em momento algum eu disse que pelo método POST os dados seriam ocultos, é uma questão de o usuário não "visualizar" o endereço pela URL, e não ocultação de dados.

 

Então eu devo ter entendido errado mesmo...

 

 

Você mesmo drescreveu uma forma de interceptar dados de uma sessão, isso é uma interceptação, de certo modo. :thumbsup:

 

Pelo que sei, não. Mesmo que eu consiga roubar o "cookie mágico" de uma sessão e sequestrar a seção do usuário, eu não poderia ter acesso ao conteúdo das variáveis de sessão, pois nem mesmo o usuário pode isso, apenas quem tem acesso ao local no servidor onde os dados de sessão são armazenados (o desenvolvedor, o webmaster, etc).

 

Tecnicamente falando, os nomes corretos para cada tipo de ação das funções base64, realmente é encoding, mais pra um bom entendedor meia palavra basta, as diferenças de criptografia e codificação são muitas, porém, assim por dizer e por força de expressão as chamo de criptografia.

 

Mas em programação isso não deve ser aplicado. Para que cada problema, solução ou enunciado fique claro, é preciso que a pessoa que o esteja fazendo use os termos corretos para definir cada coisa para não dar margem a confusões e enganos.

 

Outra questão seria ficar "ocupando" a memória do servidor com sessões, quando um simples método post resolveria, não ?

 

Não... segurança vem em primeiro lugar. Não me parece uma boa prática passar informações sensíveis para o cliente através via HTTP, mesmo que criptografadas, quando é possível proseguir sem fazer isso.

[Alaerte Gabriel 662]

Então eu devo ter entendido errado mesmo...

 

 

 

 

Pelo que sei, não. Mesmo que eu consiga roubar o "cookie mágico" de uma sessão e sequestrar a seção do usuário, eu não poderia ter acesso ao conteúdo das variáveis de sessão, pois nem mesmo o usuário pode isso, apenas quem tem acesso ao local no servidor onde os dados de sessão são armazenados (o desenvolvedor, o webmaster, etc).

 

 

 

Mas em programação isso não deve ser aplicado. Para que cada problema, solução ou enunciado fique claro, é preciso que a pessoa que o esteja fazendo use os termos corretos para definir cada coisa para não dar margem a confusões e enganos.

 

 

 

Não... segurança vem em primeiro lugar. Não me parece uma boa prática passar informações sensíveis para o cliente através via HTTP, mesmo que criptografadas, quando é possível proseguir sem fazer isso.

 

O bom é o alvo final absorver o que se explica, e não ficar batendo cabeça sobre o nome correto para cada situação. Quando vamos ao banheiro não dizemos: vou fazer uma "necessidade", somos acostumados a dizer vou "mijar" embora "fazer uma necessidade" ou "vou mijar" são totalmente diferentes. Cada cabeça cada um, você com suas opiniões e eu com as minhas, para que não entremos em contradição.