Jump to content
Sign in to follow this  
Sir Pereira

Confidencialidade de dados

Recommended Posts

Sir Pereira

Boas pessoal,

imaginem que tenho um programa que tem uma acção que interage com um FTP.

E, alguém, abrir com um hex editor (ou outro software qualquer que permita o mesmo), tem acesso aos dados FTP lá escritos.

Como posso ocultar esses dados, ou fazer a ligação de outra forma, de forma a que os dados não fiquem visíveis?

Abraço :)

Share this post


Link to post
Share on other sites
jpaulino

Não entendi o que queres dizer com "tem acesso aos dados FTP lá escritos"

Que dados são ?

Share this post


Link to post
Share on other sites
Sir Pereira

Não entendi o que queres dizer com "tem acesso aos dados FTP lá escritos"

Que dados são ?

Imagina o exemplo

        My.Computer.Network.UploadFile(My.Computer.FileSystem.SpecialDirectories.Temp & "\arquivo.txt", "ftp://www.host.com/arquivo.txt", "username_de_acesso", "password_de_acesso")

Os dados username_de_acesso e password_de_acesso, mesmo que escritos no código, podem ser visualizados por um editor Hex.

Share this post


Link to post
Share on other sites
Weasel

Podes sempre colocar numa variável encriptado, e usar um código qualquer para desencriptar.


Knowledge to the masses


Share this post


Link to post
Share on other sites
IceBrain

Tudo isso é inútil, visto que basta correr um sniffer para apanhar os dados (FTP não é encriptado). Além disso, a solução do Weasel é quebrada usando um debugger e pondo um breakpoint mesmo antes da chamada à função de ligação FTP.

Na minha opinião, devias criar uma conta no FTP para cada utilizador, e definir permissões apropriadas.


❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
Gooden

Tudo isso é inútil, visto que basta correr um sniffer para apanhar os dados (FTP não é encriptado). Além disso, a solução do Weasel é quebrada usando um debugger e pondo um breakpoint mesmo antes da chamada à função de ligação FTP.

Na minha opinião, devias criar uma conta no FTP para cada utilizador, e definir permissões apropriadas.

ora nem mais. é exactamente isso que devias fazer. até podias passar um encriptador pelo ficheiro exe. mas um sniffer resolve sempre =) e eu que o diga =D

Share this post


Link to post
Share on other sites
softklin

Também podes ponderar usar género de um Webservice (se tiveres um website, basicamente é enviar dados por POST para uma dada página web, usas PHP ou outra tecnologia web para processar esses dados)

Para resolver o problema do sniffing, podes optar por utilizar um sistema de encriptação próprio, ou, solução mais cara, fazer usos de certificados digitais.


Nick antigo: softclean | Tens um projeto? | Wiki P@P

Ajuda a comunidade! Se encontrares algo de errado, usa a opção "Denunciar" por baixo de cada post.

Share this post


Link to post
Share on other sites
Sir Pereira

Hmm.

Isso das permissões por utilizador não me parece má ideia. Mas imaginem, por exemplo, se o utilizador conseguir esses dados de acesso, e entrar pelo FTP, não conseguem de alguma maneira colocar um shell no servidor, de modo a conseguir o acesso total ao servidor?

Corrijam-me se estiver errado.

Abraço

Share this post


Link to post
Share on other sites
IceBrain

Só se houver um bug grave no servidor FTP, ou se as permissões estiverem completamente erradas (por exemplo, se o servidor FTP também for servidor Web, má configuração poderia permitir o utilizador uploadar um ficheiro PHP com o código que quisesse).

O melhor é criar uma conta nova com tudo bloqueado, e depois permitir o mínimo possível para que o programa funcione. Ah, e usar FTP encriptado (SFTP ou FTPS) é sempre melhor, claro.

Também podes ponderar usar género de um Webservice (se tiveres um website, basicamente é enviar dados por POST para uma dada página web, usas PHP ou outra tecnologia web para processar esses dados)

Não concordo, um Webservice é mais generalista e portanto tem mais use-cases pouco testados, o que significa que é menos seguro. Um servidor FTP com boa reputação é mais recomendável, imho.

Para resolver o problema do sniffing, podes optar por utilizar um sistema de encriptação próprio, ou, solução mais cara, fazer usos de certificados digitais.

Podem-se usar certificados criados manualmente; a vantagem dos "oficiais" é autenticarem-te, mas neste caso (proteger do cliente) não é necessário.

❝The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.❞- John Carmack on software patents

A list  of command line apps

Share this post


Link to post
Share on other sites
softklin

São opiniões, não tenho conhecimentos de segurança em Webservices, mas penso que depende sempre da implementação de cada um. Embora o Sir Pereira não tenha dito para que seria exactamente, pareceu-me ser para fins de troca e armazenamento de dados, e na minha ideia, uma implementação de um webservice faria mais sentido, e deixava problemas de acesso e afins do lado do servidor.

Claro que uma implementação com um FTP é mais simples, mas expõe um bocado mais a implementação ao cliente, é o que eu penso (em termos de segurança).


Nick antigo: softclean | Tens um projeto? | Wiki P@P

Ajuda a comunidade! Se encontrares algo de errado, usa a opção "Denunciar" por baixo de cada post.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.