Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Olá, estou com mais uma dúvida sobre segurança. Estou iniciando um projeto de desenvolvimento e ando preocupado com a segurança das minhas requisições.
Exemplo: Tenho uma tela para editar um pedido já criado. Obviamente, esse pedido tem um ID como chave primaria no bando de dados. O que eu faço atualmente:
Na tela de edição de pedido, tenho um <input type="hidden" name="pedidoID" value="13"> por exemplo.
Aí quando mando o "submit" ele vai pra outra tela, e com base nesse pedido "13" o sistema fazer as alterações necessárias no banco de dados e etc. Em outras telas, faço algo parecido mas através de Ajax. Legal, funciona, mas ao usar esses inputs dessa forma é uma brecha de segurança certo? Pois alguém mal intencionado pode facilmente localizar e alterar o numero do pedido, causando uma alteração errada no banco de dados.
Fiz uma breve pesquisa sobre segurança em PHP, e pensei em duas coisas:
Fazer uma HASH de mão dupla para o valor do ID, que acredito que dificultaria um pouco a possibilidade de alguém alterar.
Ou utilizar $_SESSION["pedidoID"] que penso ser mais seguro para ocultar o valor do ID de um pedido. Porem, utilizando $_SESSION["pedidoID"] ficaria dificil, ou impossível de fazer algumas requisições via Ajax.
Foi o que eu consegui pensar.
Alguém com experiência em PHP pode me dar uma orientação sobre como trabalhar melhor com segurança nesse caso?@Cesar Melo, beleza!
Segue uma dica que pode ser útil:
Os dados que você enviar para o seu formulário, que você quer se certificar que o usuário não alterou antes de submeter, salve eles em uma sessão:
$_SESSION['esperado'] = [
'pedidoId' => 5,
'preco' => '1000',
'desconto' => '10'
];
E então quando receber a submissão, verifique se nada de importante foi alterado:$dadosRecebidos = [
'pedidoId' => $_POST['pedidoId'],
'preco' => $_POST['preco'],
'desconto' => $_POST['desconto']
];
$diferenca = array_diff($_SESSION['esperado'], $dadosRecebidos);
if ($diferenca) {
throw new Exception("As informações enviadas não são consistentes!");
}@EdCesar obrigado pela dica cara.
Quando eu for mexer com essa parte de segurança, vou começar dessa forma, utilizando sessions para dados importantes.
Depois vou pesquisando sobre como ter mais segurança por requisições via ajax, pois há telas em que eu listo uma série de pedidos, ou produtos... então acho q não ficaria muito viável utilizar sessions nessas telas.. mas enfim... Uma coisa de cada vez..
Muito obrigado meu caro!
Segurança é "relativa" de acordo com a sua aplicação.
Aplicação de HASH "duas vias" é tipo "esconder doce de criança" ou seja, não adianta muita coisa porque quaqlquer um que queira burlar o seu sistema vai identificar facilmente o hash utilizado - que geralmente é um base64 - e então vai conseguir a info que você tentou encobrir...
Em atualização de registros eu geralmente aplico a seguinte condição
Atualizo informações do ID x se o usuario X é igual ao usuario do ID x
Ou seja, somente atualizo o registro se o usuario for o mesmo que registrou.
Claro que isso não se aplica a tudo porque há momentos que você não tem um usuario especifico e neste sentido, para preservar o registro da minha base eu opto por sempre ter um campo que sempre chamo de chaveEspecial e num momento de atualização de dados eu verifico sempre se o ID requisitado a ser atualizado possui a mesma chaveEspecial antes de sua atualização
Exemplo
Registro 01
ID - 567
chaveEspecial - awhxoeirjdakoao@312dk#$5dksotw346
Registro 02
ID - 789
chaveEspecial - siufoerfoifemorr09ik0946k085k9654m039d8m
Usuario mal-intencionado acessa registro 01 para edita-lo mas ao enviar dados ao servidor ele manda para o registro 02
Neste momento eu verifico a chaveEspecial. Essa chaveEspecial deixo salvo numa session e condiciono a execução sob a verificação da chaveEspecial no registro.
Em resumo, se a chaveEspecial não coincidir com a que existe no registro eu retorno FALSE o script.
Desta forma a chaveEspecial nao fica exposta em nenhum campo de formulario e dificultaria o usuario mal-intencionado a entender qual é o fluxo e que informações você utiliza para validar o update.
Tudo depende também de como as informações são expostas porque já vi fulanos fazerem o seguinte:
Ao imprimir os registros na tela eles expoem o ID (Por exemplo - lista de relação de pedidos) e no script aplicam um hash sobre esse id e esse id impresso na tela é a chave primaria do registro, ou seja, nada adianta porque o usuario nem precisou se esforçar para saber qual é a identificação do registro no banco já que ele está ali impresso na tela.
Boa sorte
Geralmente pedidos tem uma FK de identificação do usuário.
Este filtro tem que ser feito no back-end.