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

3

7

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!

Adrienneadrift answered 1/10, 2013 at 20:18 Comment(1)
You can ignore the biggest part of my answer if you have a limited number of known users. Just propose hime use VPN. Your server will not be accessible to world but user with password will be able connect to your local network and use your server.Soledadsolely
S
3

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.

Soledadsolely answered 1/10, 2013 at 23:16 Comment(2)
Thank you very much for the generous, detailed answer! It is a great help in my attempt to identify the many lacunae in my understanding of the basic concepts involved with these security concerns. I believe that, with this orientation, I can now begin exploring the various domains you listed. I have also learned that I know even less than I thought; for I did indeed mean that the application would only be accessible within a local network--on a single machine--(maybe distributing the Prolog application for others to use likewise), but I didn't even know enough to articulate that clearly!Adrienneadrift
Your later additions are a great relief; for when I was first reading through your answer I thought that I was completely out of my league and I was about to abandon the whole approach and, perhaps, try to build a native gui after all. Many thanks!Adrienneadrift
A
2

I'd point out that my post was about a security issue with using port forwarding in apache to access a prolog server.

And I do know of a successful prolog injection DOS attack on a SWI-Prolog http framework based website. I don't believe the website's author wants the details made public, but the possibility is certainly real. Obviously this attack vector is only possible if the site evaluates Turing complete code (or code which it can't prove will terminate).

A simple security precaution is to check the Request object and reject requests from anything but localhost.

I'd point out that the pldoc server only responds by default on localhost. - Anne Ogborn

Ablebodied answered 6/1, 2014 at 8:1 Comment(0)
C
1

I think SWI_Prolog http package is an excellent choice. Jan Wielemaker put much effort in making it secure and scalable.

I don't think you need to worry about SQL injection, indeed would be strange to rely on SQL when you have Prolog power at your fingers...

Of course, you need to properly manage the http access in your server... Just this morning there has been an interesting post in SWI-Prolog mailing list, about this topic: Anne Ogborn shares her experience...

Cliffhanger answered 2/10, 2013 at 8:53 Comment(4)
I'm glad to hear the endorsement of the SWI-Prolog package. I've enjoyed playing with it, but I'm quite ignorant in these matters and it's good to know I'm not on a fools errand. I've spent a good bit of time working through Anne Ogborn's tutorial and am grateful for her work. Thanks for the link to the mailing list! Aside from the cautionary tale, it's fun to see her taking advantage of the situation.Adrienneadrift
But we need worry about "Prolog injections". By the way, which alternative to SQL DB you propose to use for persistent storage?Soledadsolely
@SergeiLodyagin: Prolog is a relational language. And SWI-Prolog has plenty of storage alternative. For instance, I experimented with QLF - Wordnet (~300K records IIRC) can be loaded in seconds on a toy pc. But the focus of SWI-Prolog is on RDF storage.Cliffhanger
@SergeiLodyagin You're not vulnerable to Prolog injection unless you directly insert unescaped user input into a goal and then call it. I doubt seriously anybody would try it though. We're niche enough as it is. Also, you can continue to use SQL with the ODBC package. I have had success querying Postgres from SWI this way.Mouflon

© 2022 - 2024 — McMap. All rights reserved.