November 17th, 2013, 01:34 PM
Securing a remote script that uploads to server
I am an IT engineer primarily, not a developer, and although I have written loads of PHP for websites I have a problem I don't know how to tackle.
I want to be able to run a script on a local computer - well actually many computers (language not important, it may turn out to be PHP, or for my windows clients C#) that uploads a few values, probably in an XML file to a public webserver.
This needs to happen automatically and I don't know how to secure this. I have full access to the server I will be uploading too so anything is possible, but I am expecting to run apache/php for this. Some of my clients are behind proxy servers so I expect to use POST requests for the upload as direct db access or SSH or SFTP etc may not work.
I need to know how to secure this process, I can easily add a password or access token to the upload script which would stop general access but the script may be on many computers and if someone started playing with it could find and use the token to submit crap. (even if every install has its own token)
How can I produce a system whereby I can authorize my script/program to upload data in a way that can't be easily impersonated.
For reference this will be a system monitoring script, that uploads some stats - disk space, uptime, installed software etc... to a server which records the stats so I can search and report on the data. It will be on all of our servers and eventually possibly desktop computers.
I don't need code examples, I can write that, i'm just not familiar with any techniques for securing such a system.
Any ideas welcome.
November 17th, 2013, 09:01 PM
if you don't trust the clients to keep their data secure, you can forget about authentication. If you even expect your users to actively abuse their upload privilege, the whole "security" is pointless.
You cannot give somebody a privilege and at the same time protect it from them. This is a contradiction in terms. People may tell you that you can somehow "hide" the authentication token (or key or whatever) so that it's only usable by the application itself. But this is nonsense. The user doesn't even have to extract the token. They can simply fetch it when it gets sent to the server.
So I think there's a general misconception. Before you worry about authentication methods and implementation details, you should first get clear about the overall situation:
Are you dealing with a limited set of trusted clients? Then you can indeed use different authentication methods to protect against external(!) attackers. On the low end, there are authentication tokens (don't forget to use a strong hash algorithm like bcrypt on the server!). On the high end, there are TLS client certificates.
Or are you dealing with untrusted users? Then you have a public application accessible to anyone. You now have to take care of filtering the input to reduce the amount of garbage data.
Of course, the application itself must be secure in any case. The worst thing a user may do is put garbage into your database.
November 19th, 2013, 11:36 AM
You can encrypt the php source code but that might cost you money with ioncube.
Figure out a remote connect.php file that you can include that has all the connections from there.
November 19th, 2013, 02:02 PM
First of all, "code encryption" (I guess you mean obfuscation) cannot protect data, especially not if the data has to be sent to a remote server. This is a common misunderstanding. The only thing that ionCube etc. can do is protect your literal source code by compiling it to byte code. This doesn't help here.
The second suggestion doesn't make sense to me. Where does the authentication happen in this model? And of course including remote code is an awful idea, because if that code gets compromised, it's game over for the client. Definitely not an option!
Sorry, but the underlying problem remains. You can't beat reality, no matter how sophisticated your technique may be.
Comments on this post
November 19th, 2013, 03:38 PM
Thanks for the advice. I think I was hoping I was missing something and that wouldn't be the answer!