Securing Information

[Hate]

Hello,

 

I'm writing an application that will have to interact with my webserver and it will be using php to input data into the database and retrieve from as well. However, I'm not sure what is the best approach on securing my database from people sniffing while using my application. The only thing that I can do that is coming to mind is try to use a unique key as a password and have one of my GET vars be that password, but that is easily sniff-able.

 

What can I do to secure my database and prevent people from filling up my databases if they sniff out my password key? Is there any kind of encryption I can use that will defeat this?

[Psycho]

Why on earth would your DB password even be exposed between the client and server? If you are talking about a username/password for logging into your application you would only submit that information once and then store a token in session data to persist that user as logged in. However, you will need to pass the password in plain text when the user submits their log in credentials. The only way to effectively protect that would be to use https which requires you to set up certificates and probably coordinate with your host.

[Hate]

I probably should of elaborated more. Within my application I want to be able to access remote php files on my web server and add content that way. To the normal user this would be secure and safe to do with simple web requests, but if an advanced user did any kind of sniffing they would be able to figure out my secret key since I'm doing basic GET requests. Here's an example url of what I mean:

 

http://mysite.com/put.php?key=NSDF83NDSF35MDF&title=Hello

 

If I were to use that inside of my win32 application it would be fine to the normal user since they don't know the key to access the script, but if an advanced user sniffed that url they could get the key and spam the link and flood my databases. Is there any way to prevent this?

[Psycho]

You are not making sense. You first talk about accessing remote files then you end with talking about the database. One is not related to the other.

 

In any case, you should have some way to "authenticate" the user which does not have to be a traditional username/password login. You should never rely upon obfuscation for security. If this is a desktop application that is integrating with your web back end you could do something where each user/firm has an account number. Then only allow the user to work with files/data associated with their firm. If there is no control of who can use the application then you would want to implement some type of limiter to prevent the same user from processing "too much" data either downstream or upstream.

[Hate]

I want to access my php files within my windows application using web requests and I want the php files to store information inside of my database. The script should add anything I want to the database without a limit. There isn't any usernames or passwords or anything like that. It is simply a means to add content into the database. I planned on making it so the php script only access from a special user-agent and needs to have the correct key(password), but all of that could easily be sniffed and spoofed to make it seem like it was coming from my application.

[xyph]

You can't hide a client's request from himself.

 

Pyscho has provided you with the best solution.

 

Please explain specifically which parts of his solution you don't understand, or which parts you can't implement and the reasons you can't

[Psycho]

I want to access my php files within my windows application using web requests and I want the php files to store information inside of my database. The script should add anything I want to the database without a limit. There isn't any usernames or passwords or anything like that. It is simply a means to add content into the database. I planned on making it so the php script only access from a special user-agent and needs to have the correct key(password), but all of that could easily be sniffed and spoofed to make it seem like it was coming from my application.

 

OK, let's recap. You do not want any user to be able to use any feature as often as they wish. There will be no manner of authenticating/identifying the user. You desktop app is using a "key", but from what it sounds like, you are only using that key to identify that the request is coming from the desktop app so you can prevent requests from being submitted in an alternative method. And your "problem" is that you don't want someone to identify that key and make submissions outside your windows app.

 

So, my question to you is - what do you care how someone makes a request? You should already have the necessary validations/sanitizations in place to prevent problems. Many web-based apps are built such that anyone can build a custom front-end interface. You do say that you are worried about people "filling up your database". Couldn't they do that using the desktop app anyway? It is just as easy to create an automated script for the desktop app (if not easier) than it would be to create custom scripts for generating the requests independent of the desktop app.

 

So, if your real concern is about someone sending too many requests you should still consider some way to limit the rate/number of requests per user within a given time frame - e.g. no more than 20 requests per minute or whatever you determine would be.

[Hate]

I want to access my php files within my windows application using web requests and I want the php files to store information inside of my database. The script should add anything I want to the database without a limit. There isn't any usernames or passwords or anything like that. It is simply a means to add content into the database. I planned on making it so the php script only access from a special user-agent and needs to have the correct key(password), but all of that could easily be sniffed and spoofed to make it seem like it was coming from my application.

 

OK, let's recap. You do not want any user to be able to use any feature as often as they wish. There will be no manner of authenticating/identifying the user. You desktop app is using a "key", but from what it sounds like, you are only using that key to identify that the request is coming from the desktop app so you can prevent requests from being submitted in an alternative method. And your "problem" is that you don't want someone to identify that key and make submissions outside your windows app.

 

So, my question to you is - what do you care how someone makes a request? You should already have the necessary validations/sanitizations in place to prevent problems. Many web-based apps are built such that anyone can build a custom front-end interface. You do say that you are worried about people "filling up your database". Couldn't they do that using the desktop app anyway? It is just as easy to create an automated script for the desktop app (if not easier) than it would be to create custom scripts for generating the requests independent of the desktop app.

 

So, if your real concern is about someone sending too many requests you should still consider some way to limit the rate/number of requests per user within a given time frame - e.g. no more than 20 requests per minute or whatever you determine would be.

 

You're following along correct. Basically, the user doesn't control the information stored in the database. It's statistics logging to better my application (which they completely agree to during the install), but I'm worried that someone will sniff the key and flood my database. There really can't be a limit enforced as there are requests coming every 1 to 50 seconds. Is it possible to encrypt my get requests from the application and have a special way to decrypt them from the php script? I know that's a confusing concept, but I hope you understand what I mean.

[MMDE]

You want them not to see what they send, and not be able to send them by themselves by just sniffing? Perhaps you need to encrypt it somehow and maybe add a timestamp into the encrypted message. Even with all this in place, advanced users could probably still reverse engineer your program and find out how you encrypt the messages.

 

You could limit the amount of allowed requests from a certain ip within a certain time period, but people would still be able to fake the ip address, or use proxy servers etc. What you could do is to actually limit all allowed requests as suggested from other people in earlier posts here, do you need that many requests per minute?

 

People could always hammer your server with bad requests as well, even if you just deny them.

[Psycho]

Is it possible to encrypt my get requests from the application and have a special way to decrypt them from the php script? I know that's a confusing concept, but I hope you understand what I mean.

 

How is that going to help? The user can ascertain the encrypted key the same way they can get the unencrypted key and you have no way to determine on the server-side if that encrypted key was sent by the application or not. So, it doesn't matter if the user knows what the actual key is as long as they are sending the same information that the the desktop app would send.

 

I can think of some alternative approaches that would make it somewhat more difficult, but none of them are foolproof and would only add more complexity (i.e. bugs) that really adds no value. Again, I really don't understand what you are trying to prevent. The statistics should be logged on the server based upon the requests from the client. And, as I stated previously, the services shouldn't care what or how the requests are sent only if the requests are valid or not.

 

There are some $_SERVER vars that would identify the client-side app, but those can be easily be spoofed by someone who has gone to the trouble to find the key anyway.

[Hate]

Is it possible to encrypt my get requests from the application and have a special way to decrypt them from the php script? I know that's a confusing concept, but I hope you understand what I mean.

 

How is that going to help? The user can ascertain the encrypted key the same way they can get the unencrypted key and you have no way to determine on the server-side if that encrypted key was sent by the application or not. So, it doesn't matter if the user knows what the actual key is as long as they are sending the same information that the the desktop app would send.

 

I can think of some alternative approaches that would make it somewhat more difficult, but none of them are foolproof and would only add more complexity (i.e. bugs) that really adds no value. Again, I really don't understand what you are trying to prevent. The statistics should be logged on the server based upon the requests from the client. And, as I stated previously, the services shouldn't care what or how the requests are sent only if the requests are valid or not.

 

There are some $_SERVER vars that would identify the client-side app, but those can be easily be spoofed by someone who has gone to the trouble to find the key anyway.

 

Could you share some of these alternative approaches that would make it a bit more difficult?

[Psycho]

Not any that are fully thought out. But, I really think they would be a big waste of time. But, here goes.

 

In your desktop app create some function/process that generates a hash using a salt. This would need to be built into the application files such that it could not be reverse engineered (at least not without a lot of work). Then for every request from the client grab a timestamp and run it through the hash and send the timestamp and hash along with the request. The server could then take that timestamp and run it through the same hashing process on the server and check if it matches the hash that was sent.

 

But, this also raises problems. A malicious user could just grab a single timestamp and hash and send the same values on every request. You can't reject requests because the timestamp is X minutes old or something similar because people could be in different timezones. But, you could possibly track requests from the same user via session data. if the requests aren't changing the timestamp reject them. No matter what way you slice it thre really is no good solution. There will always be a hole in the system that requires some other "patch" which really doesn't eliminate the problem entirely. You are trying to fix something that doesn't need to be fixed and will only cause more problems than you think you are addressing (IMO). You shouldn't care where the request is coming from as long as the data is valid.