views:

31

answers:

2

My customers can ask questions directly in my (windows forms) app. The app talks to a web service which stores the messages in a db on my server. Problem: A competitor decides to spam my Web Service. What can I do to prevent this and is there a cryptographically save way of doing this?

The things I came up with until now are:

  1. Hide the WSDL information so an attacker does not know the Web Service interface. Analysing my code or sniffing the traffic will reveal this information quickly however.

  2. Create a token which I sign with a public key stored in my app. The Web Service can test this way if the message has been sent by my app. Well in theory at least. Again an attacker could rip the public key out of my app and create valid messages himself.

So I'm pretty stuck here. Is there any way to do this right and prevent dos attacks on my web service or is a web service the wrong way to do this in general?

Thank y'all.

A: 

You're right- putting a private key in your app won't slow anyone down much, no matter how hard you obfuscate it. Nor is obscurity on your WS metadata.

Probably the best way (if you can't do authentication) would be to throttle by IP (one comment per X interval). Just keep an in-memory dictionary of client IPs and the last time you saw a comment from there, and reject requests quickly if they happen too soon. That'd at least require a big DDOS to cause major problems. Reap the dictionary for old entries every hour or so to keep it from growing without bound.

nitzmahone
A: 

@nitzmahone is right. Just to add to this: This is no different from someone spamming a web-based form. If you're really worried about this, you can do what web forms do (e.g. server sends token and CAPTCHA image, user decodes the CAPTCHA, client app sends token, decoded CAPTCHA and the actual request).

Just like in web apps, you can turn this functionality on only if traffic from some IP exceeds a certain threshold.

Eugene Osovetsky