What security risks are posed by using a local server to provide a browser-based gui for a program?

Question

I am building a relatively simple program to gather and sort data input by the user. I would like to use a local server running through a web browser for two reasons:

1. HTML forms are a simple and effective means for gathering the input I'll need.
2. I want to be able to run the program off-line and without having to manage the security risks involved with accessing a remote server.

Edit: To clarify, I mean that the application should be accessible only from the local network and not from the Internet.

As I've been seeking out information on the issue, I've encountered one or two remarks suggesting that local servers have their own security risks, but I'm not clear on the nature or severity of those risks.

(In case it is relevant, I will be using SWI-Prolog for handling the data manipulation. I also plan on using the SWI-Prolog HTTP package for the server, but I am willing to reconsider this choice if it turns out to be a bad idea.)

I have two questions:

1. What security risks does one need to be aware of when using a local server for this purpose? (Note: In my case, the program will likely deal with some very sensitive information, so I don't have room for any laxity on this issue).
2. How does one go about mitigating these risks? (Or, where I should look to learn how to address this issue?)

I'm very grateful for any and all help!

Answer 1

There are security risks with any solution. You can use tools proven by years and one day be hacked (from my own experience). And you can pay a lot for security solution and never be hacked. So, you need always compare efforts with impact.

Basically, you need protect 4 "doors" in your case: 1. Authorization (password interception or, for example improper, usage of cookies) 2. http protocol 3. Application input 4. Other ways to access your database (not using http, for example, by ssh port with weak password, taking your computer or hard disk etc. In some cases you need properly encrypt the volume)

1 and 4 are not specific for Prolog but 4 is only one which has some specific in a case of local servers.

Protect http protocol level means do not allow requests which can take control over your swi-prolog server. For this purpose I recommend install some reverse-proxy like nginx which can prevent attacks on this level including some type of DoS. So, browser will contact nginx and nginx will redirect request to your server if it is a correct http request. You can use any other server instead of nginx if it has similar features.

You need install proper ssl key and allow ssl (https) in your reverse proxy server. It should be not in your swi-prolog server. Https will encrypt all information and will communicate with swi-prolog by http.

Think about authorization. There are methods which can be broken very easily. You need study this topic, there are lot of information. I think it is most important part.

Application input problem - the famose example is "sql injection". Study examples. All good web frameworks have "entry" procedures to clean all possible injections. Take an existing code and rewrite it with prolog. Also, test all input fields with very long string, different charsets etc.

You can see, the security is not so easy, but you can select appropriate efforts considering with the impact of hacking.

Also, think about possible attacker. If somebody is very interested particulary to get your information all mentioned methods are good. But it can be a rare case. Most often hackers just scan internet and try apply known hacks to all found servers. In this case your best friend should be Honey-Pots and prolog itself, because the probability of hacker interest to swi-prolog internals is extremely low. (Hacker need to study well the server code to find a door).

So I think you will found adequate methods to protect all sensitive data. But please, never use passwords with combinations of dictionary words and the same password more then for one purpose, it is the most important rule of security. For the same reason you shouldn't give access for your users to all information, but protection should be on the app level design.

The cases specific to a local server are a good firewall, proper network setup and encription of hard drive partition if your local server can be stolen by "hacker".

But if you mean the application should be accessible only from your local network and not from Internet you need much less efforts, mainly you need check your router/firewall setup and the 4th door in my list.

In a case you have a very limited number of known users you can just propose them to use VPN and not protect your server as in the case of "global" access.