1

Let's say we have a desktop application and a web application. The desktop application uploads files to the server using POST requests to the web application.

What are the possibilities (except using certificates and username/password) to find out that the POST request came from our desktop application and not from an attacker? In other words - how to make sure no one is using the upload script to flood the server with malicious files?

bretik
  • 1,870
  • 1
  • 13
  • 22
  • 1
    what's preventing you from using a e.g. username/password basic authentication? – Yoav Aner Apr 17 '12 at 15:35
  • 1
    There is nothing that can stop me except authentication. Well, authentication also doesn't stop me, but at least it reduces attack surface (you have to know the password to send file) and it allows for accountability (you know who misused the application). – pgolen Apr 17 '12 at 17:37
  • @YoavAner Nothing, I just want to know if there are other approaches giving me some protection. – bretik Apr 18 '12 at 10:47

1 Answers1

3

HTTPS should be the default for everything. You can use a self-signed certificate for FREE, and hard-code the certificate with your desktop client. Anything else would be a serious mistake.

But let me be clear, this doesn't prevent a hacker from gaining access to this interface. Nothing will ever be able do this because the attacker is running your client on his machine and there for has complete control. SSL only protects the data in transit, and makes sure your delivering it to the right person.

rook
  • 47,238
  • 10
  • 96
  • 182
  • 2
    "Anything else would be a serious mistake" sounds a little harsh. especially without knowing the threat profile. There are literally thousands of websites allowing people to upload files. I don't know how many of them use client or even server-side certificates. Sure, they are exposed to some risks, but I doubt all of them make a serious mistake... – Yoav Aner Apr 17 '12 at 16:47
  • @Yoav Aner well you can have an insecure file upload, if the files don't matter, i guess its important to note the OP's didn't mention what threats he cared about. – rook Apr 17 '12 at 16:48
  • 2
    Exactly. And that's why I think your comment might be a little too harsh without more info. I agree that in some situations it would be a serious mistake not to use SSL + other means of protection, but I would personally think more info is necessary before jumping into any conclusions. – Yoav Aner Apr 17 '12 at 16:51
  • @Yoav Aner yeah, I disagree and should not spread these toxic ideas. SSL needs to be the default for everything. It consumes basically zero resources and stops a lot of nonsense. – rook Apr 17 '12 at 16:53
  • 2
    SSL is a great solution to many problems, but not all. Just saying 'add SSL otherwise it's a serious mistake' is like a doctor giving paracetamol for everything. Sure, it's a great painkiller and helps a lot of people and might even be the right medicine in many cases, but it doesn't mean it will cure the problem. Any good doctor first needs to diagnose the problem, then come up with a solution. Not the other way around. – Yoav Aner Apr 17 '12 at 17:07
  • In case the web application run only on HTTPS, what is the difference between hard-coding the certificate with the desktop application and having some shared secret which will be used to sign the data being uploaded? Both can be found out by reverse engineering, so I don't see any added value for the extra effort of implementing certificate support on desktop/server. – bretik Apr 19 '12 at 07:25
  • @bretik In my post I said specifically that trying to prevent an attacker from access the web application was impossible. – rook Apr 20 '12 at 00:35