0

I have a website with architecture (HTML + JSON + webservice (C#)) installed on a server which is open to internet. Now, my webservices are opened to the whole world so anyone can access it and may try to malfunction.

What I would like to do is to make my webservice to work limitedly to my application only instead of other applications. Like when a website is on open internet but its web services are private to the website only and not to the whole internet.

Right now there's a big data security concern.

halfer
  • 19,824
  • 17
  • 99
  • 186
omieCode
  • 1
  • 1
  • 1
    You need to have some shared secret between the webservice and the application. The application should send that shared secret whenever making call to webservice. WebService should check the value of shared secret in every incoming request and check if it's a valid. if it not valid then it should reject the request. – Chetan Jan 08 '18 at 10:17
  • What is your application? Is it on a web server where other folks cannot discover a single shared secret? Or is it a mobile/distributable application where each person will need their own login? (cc @ChetanRanpariya: don't forget the dangers of a single shared secret). – halfer Jan 08 '18 at 10:41
  • Certificates? Claims-based security? Take your pick. Both equally too broad –  Jan 08 '18 at 10:44
  • Please read [Under what circumstances may I add “urgent” or other similar phrases to my question, in order to obtain faster answers?](//meta.stackoverflow.com/q/326569) - the summary is that this is not an ideal way to address volunteers, and is probably counterproductive to obtaining answers. Please refrain from adding this to your questions. – halfer Jan 08 '18 at 10:45

3 Answers3

1

The primary way would be to add some sort off login/account system. That then of course needs to be managed and all that.

The other posters' approaches of just putting some key or certificate into it will only work if it is not that important. Anything you store in the application is invariably reverse-engineerable. So if someone is decently determined, that level of protection is easy enough to overcome.

If the number of possible consumers is small enough, another approach might work: Make it only reachable from the local network (IP adress ranges associated with Local Networks). Then use a approach like VPN so clients can connect to you local Network. Basically you move the account part to another System. But such a approach can have security issues, especially if that VPN connection goes straight into your DMZ.

In the end it really depends how critical that is. Security exists in flavors from "anybody reading his computers network traffic with Wireshark can break it" to "reasonably secure for high grade private data". We have no idea what level of security you need and what level of skill you have, so we can not give a useful answer just yet.

halfer
  • 19,824
  • 17
  • 99
  • 186
Christopher
  • 9,634
  • 2
  • 17
  • 31
  • OP is talking about **web services** where typically there is no state let alone a _"login"_ mechanism. Your thoughts on certificates reads a bit naive. Certificate-based security is superior to mere passwords. The best security is when no password is involved which is what certificates allow. Your points on local networks; VPNs and DMZ are not useful as OP as indicated it is open to the Internet –  Jan 09 '18 at 00:07
  • Webservices can be given a login. Any forum Login is literally just a cookie being send along with every request. Certificates are better then passwords. But that does not change the fact that you really just need to extract the certificate and it all goes down. And it is only open to the internet because there is a lack of alternatives to have reachability + security. – Christopher Jan 09 '18 at 02:21
  • Most web services today, particularly ones designed for scale, are stateless therefore no login. You are confusing user-interactive sites like _"forums"_ with web services. You really just need to extract the password or packet sniff and it all goes down. Your last statement is bizarre when it comes to WAN –  Jan 09 '18 at 02:38
  • I would also only need to packet sniff or extract the Certificate for it to all go down. All you did was give all clients the same somehwat long password. – Christopher Jan 09 '18 at 15:35
0

I would suggest you look into using Certificates to encrypt your webservice, then your application will call it using that same loaded certificate. Only an entity with your server certificate key will be able to decrypt your calls.

Accessing a web service and a HTTP interface using certificate authentication

Calling a rest api with username and password - how to

Edit: If you cannot use the certificate method because you are calling from say the browser directly, you might want to look at an authorization cookie of some sort, So that lets say on your login pages the request might be open to public but on all subsequent request you require authentication and once the user has logged in you rely on the authorization cookie or token to validate whether they have access.

Another method: IdentityServer for instance has provider token stores, so you can request a token from the store, then only with the issued token you can access the API. And your API would also then query the store to check the token is valid.

Hano Johannes Rossouw
  • 750
  • 5
  • 14
  • OR you can try and use a normal secret key in your api calls however as parameter being present in your calls the person might be able to inspect the GET or POST requests to see your secret key hence why the certificate is better. – Hano Johannes Rossouw Jan 08 '18 at 10:20
  • A certificate is OK, but the OP has not said if they are using a distributable app e.g. Android/iOS. In that case, the cert would have to be different for each user in order to allow users to be revoked. With that in mind, a username/password may be easier to implement. – halfer Jan 08 '18 at 10:49
  • @halfer Certificates are not the sole domain of just _"app"_ s. Also certificates can be per app or machine and not always as fine grained as users. OP did not mention a revoking use case. Taking _"easier"_ approaches to security may not be a good idea –  Jan 09 '18 at 00:00
0

I found a very easy solution to it.. by getting ip address of the remote client's in web service i can validate whether the request is coming from my webserver or not

so anytime if any spamming client try to request my web service i will retrieve its ip on every request inside webservice and reject the request for ex :

if (HttpContext.Current.Request.UserHostAddress.ToString() == "127.0.0.1")
{
   return "my server";
}
else
{
  return "invalid client or spammer"
}
omieCode
  • 1
  • 1
  • But if your client or user uses the website the request host address will not be your server's ip, it will be the user's public ip? Are you trying to secure a connection between 2 servers or a connection from a website to a server? – Hano Johannes Rossouw Jan 10 '18 at 11:55