Secure data transmission and storage

Question

We currently have an application that we deploy via the web, users access it by connecting to a link which opens an executable file. This file was compiled with visual foxpro.

My question is - is this setup secure? Are my transactions, data transmission to and from the server secured? Or is it better to develop a web application in PHP for this?

I'm using mysql database on ubuntu server.

Hopefully this is clear enough for you.

EDIT

Man-in-the-middle attacks - The site uses HTTP only and is not using SSL/TLS encryption.

Access control - Only our in-house programmers are authorized to upload new versions of the application. The new version will be evaluated first on a pre-production system before replacing the current version.

Server Security - We are using SSH for remote administrative access. The server is also hosting samba for internal network file server, and there are also those who access the same server for secure file transfer.

Software security - Although we have very competent developers, I am not sure if they are trained in secure software development or use static analysis tools.

I may have to suggest a change on our current system due to some security lapses. I would leave this thread open for a few more days to seek for more advice from professionals like you. Systems (data, network, server) security is new to me and I am really interested in learning more, I'd appreciate it if you can give me a few sources to start learning from.

Answer 1

The best way to answer your question is probably going to be to hire a security consultant to perform a security assessment of your approach. It sounds like you don't have a lot of security knowledge yourself, so you're probably not going to be in an ideal position to answer the question on your own.

You probably haven't provided us enough information for us to perform a thorough security assessment for you. The security risks of your approach are going to depend heavily on all the details of how your system works and how it is configured and deployed. There are a lot of details you don't mention, but which are relevant to security.

Here are some examples of security risks that might be relevant to you, depending upon your specific situation:

• Social engineering. Asking users to download and run an executable program is a dubious idea, from a security perspective. It trains users to run executables from untrusted web sites, i.e., it trains them to behave in an insecure way. You may not intend to ever serve them a malicious program from your site, but what if the users go to some other site and download and run a program? If you are asking users to routinely do this every time they want to use your application, you are teaching them that this practice is OK.

• Man-in-the-middle attacks. You don't say whether your site uses HTTP or HTTPS (i.e., whether it uses SSL/TLS encryption). If it is accessed over HTTP, then it is vulnerable to man-in-the-middle attacks, such as those that are possible over open Wifi.

  The best defense is to ensure that your site uses SSL sitewide (it should be accessible only via HTTPS; any attempt to visit via HTTP should immediately redirect to the HTTPS site, or else your server should never respond via HTTP). You should also enable HTTP Strict Transport Security on your server, so clients know they should only connect via HTTPS.

• Access control. You haven't told us how you limit who is able to upload new versions of the application to your site. Obviously, the security of the site is only as good as the protection for that functionality.

• Server security. If someone can hack into your server, they can breach the security of your site and your clients. Therefore, you should lock down the server, so it is not running any other services beyond what is needed for this one application. You should enable a firewall to ensure that no one from the public Internet can reach any service other than the web service, and possibly a well-secured SSH server for administrative access. (For SSH, I recommend allowing public-key access only, and disabling authentication via password.)

• Software security. You will need to ensure that there are no vulnerabilities in your custom software. This means that it is important that the developers be trained in secure software development. They might also want to use static analysis tools or other support to help catch any remaining security bugs that might slip through.

• Updates. You should make sure to keep your software updated with all the latest security updates and patches. One way to do this is to configure Ubuntu to auto-update its software, e.g., checking for and automatically installing updates once a day or once a week.

Generally speaking, it is not likely that you are going to get a definitive answer that "you are secure", just as there is no guarantee the next time you cross the street that you won't get hit by a car. Instead, security professionals identify possible risks/threats, assess the mitigations/defenses you have put in place, evaluate whether your system reduces the risk to an acceptable level, and identify for you some possible steps you could take to reduce the risk if you so choose.

Answer 2

Secure against who ?

If the envisioned attacker is a third-party who can spy on the network and possibly alter data in transit, then your setup is secure if (and only if) the connections between your server and the machine of the user are protected with an appropriate protocol, which is SSL/TLS (known as "HTTPS" in a Web context). This applies not only to the channels between the application on the user machine and your servers, but also to the distribution of the application itself; otherwise, the villain could alter the application code in transit, e.g. to add some malicious payload which, when executed, records everything that happens on the user machine. If there is plain HTTP anywhere in your setup, you have lost. With HTTPS, would you seek is doable (you still need to do it right, and that is not easy, see @D.W.'s answer).

If the envisioned attacker is the user himself, then you are doomed. There cannot be trustworthy code which runs on the attacker's own system. Video game editors have tried to do that for years and repeatedly failed; (limited) success has been achieved only when the user's system is closed (i.e. is not a PC, but a game console which adamantly refuses, at an intimately hardware level, to execute any piece of code which has not been duly authorized through digital signatures).

Answer 3

In addition to @DW's answer, you should be aware that an attacker may reverse-engineer your executable to look at how it handles communication with your server. If you trust the executable to send valid instructions an attacker could use this maliciously by crafting instructions.