REQUISIçõES COM IDATAPROTECTIONPROVIDER

 Tópico anterior Próximo tópico Novo tópico

REQUISIçõES COM IDATAPROTECTIONPROVIDER

VB.NET

 Compartilhe  Compartilhe  Compartilhe
#497086 - 28/05/2021 14:33:03

NOWLIGHTS
SUMARE
Cadast. em:Abril/2011


Boa tarde,

Pessoal, ainda na luta de estudo sobre o asp.net core, entrei em um loop de duvidas rsrs....

No asp.net core, para chamar uma action com um botão utilizando a tag <a>, é passado a route (asp-route-IdCliente) e com isso acaba abrindo uma brecha gigante de invulnerabilidade onde o usuário pode facilmente alterar essa Id e acabar apagando (se for uma action de delete) um outro registro aleatório, para contornar isso, vi o uso do IDataProtectionProvider onde criptografa o dado com uma key, porém, achei q isso resolvia 100% do problema, e comecei a passar a Id Criptografada na URL do sistema, o que eu não sabia é que, cada requisição de criptografia no IDataProtectionProvider, ele gera uma nova criptografia, ou seja, se o Id 1 criptografado é X, se eu requisitar uma criptografia de novo no Id 1 ele passa a ser Y, isso acaba criando uma inconsistência de URL, sendo uma URL diferente para cada usuário ou requisição, existe uma forma de contornar isso?

Espero ter sido claro kkkk

__________________________________
- Everyone has a chance


Resposta escolhida #497087 - 28/05/2021 14:49:00

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Essa é uma das muitas razões que eu uso GUID como identificadores, não resolve esse problema, mas dificulta bastante para o usuário. Mas entendi seu problema e é um pouco difícil de contornar. Uma alternativa é não fazer a deleção 'física' do registro, mas sim lógica. Um campo tipo 'deletado' contendo um booleano definindo se está deletado ou não. Isso facilita para recuperar caso um engraçadinho tente fazer. Além disso, você precisa de log de TUDO, para saber quem foi. Pode até não ter sido a pessoa do log, mas ou menos ela fica responsabilizada, se está dando problema com sua conta, alguém tem sua senha e está sacaneando.

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#497088 - 28/05/2021 15:06:01

NOWLIGHTS
SUMARE
Cadast. em:Abril/2011


E se eu criar uma classe de criptografia Sha256 (de ida e volta) e tudo que for na view de id, por exemplo, eu passar por ela, não o torna mais seguro?? E a string criptografada sempre será a mesma, correto!?

__________________________________
- Everyone has a chance


#497089 - 28/05/2021 15:07:20

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Não necessariamente. Depende do modo como usar a criptografia, também pode mudar os valores.

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#497090 - 28/05/2021 15:13:11

NOWLIGHTS
SUMARE
Cadast. em:Abril/2011


Uma criptgrafia com uma chave como esse artivo não sempre será a mesma?

__________________________________
- Everyone has a chance


#497091 - 28/05/2021 15:16:39

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Se você usar uma chave simétrica sim. Mas daí cai no mesmo problema. Você encripta o número '2' e digamos que encriptado fique 'ABC'. Então tudo mais que for código '2' vai ser sempre 'ABC'.

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#497093 - 28/05/2021 15:27:07

NOWLIGHTS
SUMARE
Cadast. em:Abril/2011


Última edição em 28/05/2021 15:28:02 por NOWLIGHTS

Citação:
:
Se você usar uma chave simétrica sim. Mas daí cai no mesmo problema. Você encripta o número '2' e digamos que encriptado fique 'ABC'. Então tudo mais que for código '2' vai ser sempre 'ABC'.

Entendi, se o usuário entender esse padrão ai não vai resolver muito...

Mas então eu pelo menos uso essa sha256 nas querystring de URL para dificultar um pouco, e nas tags/view eu uso IDataProtectionProvider já que não preciso manter a mesma criptografia, porque o que preciso manter mesmo é o da URL, cria um pouco mais de segurança


__________________________________
- Everyone has a chance


#497094 - 28/05/2021 16:51:08

NOWLIGHTS
SUMARE
Cadast. em:Abril/2011


ou vai virar um POG?? rsrs

__________________________________
- Everyone has a chance


#497102 - 29/05/2021 00:37:30

DS2T
BARRA MANSA
Cadast. em:Novembro/2010


Da mesma forma que entendi o seu problema, não pude deixar de pensar que talvez esteja abordando o problema de um ângulo que ao meu ver não parece ter muito sentido.

Em casos onde você não tem uma forma de autenticação, isso realmente torna-se um problema. Vamos imaginar aqueles e-mails de ativação de conta. Imagina se fosse umas urls do tipo:

https://ativesuaconta.com?idconta=999

Seria bem estranho. Porque imagina que eu ativo uma conta MINHA com id=999. No segundo seguinte eu já aproveito e crio uma conta usando SEU e-mail. Possivelmente o id seria 1000 (se usarem algo incremental). Aí eu conseguiria ativar uma conta vinculada ao seu e-mail.
Nesses casos, onde você estará fora do domínio da sua aplicação (como no Outlook) eu vejo o GUID como uma alternativa, assim como gerar números aleatórios baseado numa semente GUID também. Ou usar um hash de baixa colisão, etc.

Porém, quando você está no domínio da sua aplicação a coisa muda de figura. Você tem a possibilidade de confrontar as informações com os dados do usuário logado.


Vamos considerar, por exemplo, um método Delete :  https://localhost:43555/produtos/789

Nesse caso, estou apagando o produto 789.
A questão é:  Eu tenho permissão para apagar o produto 789?

Então, antes de realizar a operação, você vai confrontar os dados do usuário logado e verificar se ele tem permissão de apagar esse produto.

Repare que você não precisa criptografar nada. Mesma coisa se ele tentar acessar algum id de alguma outra entidade. Antes de carregar, você precisa validar para ver se o usuário logado tem permissão para isso.


E lembre-se sempre quando estiver usando GUID, criação de valores randômicos, etc...  A entropia da aleatoriedade de um computador é algo simulado. As vezes pode ser difícil encontrar um padrão, mas com dinheiro e tempo, se consegue tudo.
Da mesma forma que esses métodos de criptografia e hash consomem uma quantidade considerável de CPU. Já reparou que costumam fazer o SUM dos arquivos, para validar que não foi corrompido pelo MD5? Simplesmente por ele ser mais rápido e gastar menos recurso. Cuidado para não aplicar uma complexidade e uso de recursos desnecessários na sua aplicação.





Não nasci pra programar, mas preciso me alimentar...


 Tópico anterior Próximo tópico Novo tópico


Tópico encerrado, respostas não sao permitidas
Encerrado por NOWLIGHTS em 30/05/2021 22:19:17