The NI Web Server plays the biggest role in web security when it comes to NI's newest web technology. It includes built-in best practices such as encryption, authentication, CORS control, and certification. In this next section, we will explore how exactly the NI Web Server keeps your data secure.
The NI Web Server is NI’s new web server powered by Apache. It is used for hosting the SystemLink web interface, DataFinder and Analytics Server web interface, and any web applications built with G Web Development Software. It provides a built-in guided setup utility through the NI Web Server Configuration window that allows you to configure the web server for your specific needs. By default, the NI Web Server is disabled. To configure the server to work with your development environment, choose “Simple Local Access” from the guided utility. If you want to configure the web server to allow secure or insecure remote access, you can do so, but you should educate yourself first on the security ramifications of those settings before proceeding.
NI Web Server Settings
Let’s talk about the different settings you can choose. As shown in Figure 1, the NI Web Server that ships with G Web Development Software includes a configuration utility that guides a user through setting up the web server with the proper security and sharing settings. You can find this guided setup by opening the NI Web Server Configuration application and clicking on the “Summary” tab. Once the guided setup is running, it will give you a few options:
Figure 1. NI Web Server Configuration Utility Guided Setup
- Help Me Choose a Preset – this option will guide you through a set of questions that helps you choose between three presets: Secure Remote Access, Simple Local Access, and Insecure Remote Access.
- Secure Remote Access – this option allows remote clients to securely access the web application over HTTPS and requires some kind of certificate. See below section on certificates for more information.
- Simple Local Access – this option is used when you only need to access the web application from your local host. It is also used during development; this setting is recommended for use when developing with SystemLink (formerly, "Skyline") Data Services or else the communication will be blocked and the data will not appear to be working correctly. This is due to CORS settings needing to allow connection from G Web Development Software.
- Insecure Remote Access – this option allows remote clients to access the web application over HTTP and does not provide any protection of data or credentials. This method does not require any certificates.
- Custom – this option allows you to exit the guided setup utility and choose your settings on a granular level.
To begin describing the security features of the NI Web Server, we will start by talking about how the NI Web Server communicates via RabbitMQ. RabbitMQ is the message broker behind NI’s SystemLink Data Services, and is responsible for all communication that happens underneath the NI Web Server. All communication between the NI Web Server and RabbitMQ is encrypted through the Transport Layer Security (TLS) standard, which is a cryptographic protocol that provides communications security over a computer network . In other words, it encodes the data, making it unintelligible to an unauthorized viewer. This encryption protects your data from being read or modified by just anyone, and ensures the data is sent to the correct location, thereby ensuring data integrity and confidentiality. This level of encryption requires authentication between the web server and the message broker, which is set up automatically at install time.
You can also turn on TLS encryption when hosting your web application for remote access by choosing the “Secure Remote Access” setting in the NI Web Server Configuration Utility. With this encryption enabled, the data going between the NI Web Server and any client will be encrypted. This setting also encrypts the user authentication credentials for the NI Web Server, which we talk about next. If you ever attempt to enable the NI Web Server for remote access without enabling encryption, you will be warned (see Figure 1).
To use the NI Web Server for the first time, you must set up a password. You can create a custom password for a default “admin” user, or you can use your network’s Windows or LDAP users for log in rights. You can also manage the specific rights of each user. For example, you can specify that all users can read data published on the web server, but only a few users can create, modify, or delete data.
Cross-Origin Resource Sharing (CORS) Control
Before describing the ways in which the NI Web Server gives you control over CORS, we first need to discuss Same Origin Policy. This is a security feature that every modern browser has, and it protects your web pages from other 3rd party web pages that want to access your web server. Same Origin Policy prevents another web page from reading or modifying your data. For example, if you have a web page open that includes sensitive information such as bank account data, Same Origin Policy prevents a malicious web page that is open in a different tab of your browser from accessing or modifying the bank account data. This kind of malicious attack is called Cross Site Reference Forgery (CSRF). CORS allows these kinds of cross origin requests and loosens the security of your web server. It is for this reason that CORS is disabled by default in the NI Web Server, but there are a few cases when you might want to enable CORS.
You will want to turn CORS on when you are developing a WebVI so that G Web Development Software can communicate with the Web Server. To do this, you will have to set up the Web Server with “Simple Local Access” settings. When these settings are configured, CORS is turned on for WebVI development only. When you are ready to deploy your built web application for others to access, you should choose “Secure Remote Access” settings, and the utility will turn off CORS for you. If you choose “Insecure Remote Access”, the NI Web Server Configuration utility will still keep CORS off by default. You can manually turn on CORS if your application requires it, though NI rarely recommends that. You may want to turn on CORS if you want to embed a WebVI inside a third-party website that is hosted on a different web server from your WebVI. You can specify a list of certain origins, or trusted web servers, that can access the NI Web Server through CORS. We would only recommend opening CORS to all or using “Insecure Remote Access” if you absolutely trust everyone on the network you’re on; for example, you could be connected to an isolated intranet. A good rule of thumb in this case is to always log out of the NI Web Server before visiting any external websites.
Note that at any time, you can turn off Remote Access to your web server and thereby disable access to your web application or data. “Simple Local Access” settings provide the most security.
Certificates in the context of the web are often called Public Key Certificates or Digital Certificates. These electronic documents prove that the website has been encrypted and the ownership of the website has been verified by a Certificate Authority. When a website has a verified certificate, the client-side browser will trust the site and allow connection. This also allows the HTTPS designation.
There are three different ways to obtain a certificate, each unique to their certain situations. If your goal is to setup a public-facing server for anyone to connect to, you need to go through a commercial certificate authority. This method involves some monetary fee and you do have to provide proof that your server is, in fact, owned by you or your organization. You can start this process by going to the HTTPS tab in the NI Web Server Configuration utility, choosing “Use a certificate from a certification authority”, and then selecting “Create a certificate signing request”. This will gather the information that the certificate authority needs to identify your server. Once the certification authority has given you the digital certificate, you can import that signed certificate into your web server in the HTTPS tab. Clients will now be able to access your web application without having any warnings from their browsers about a potential security threat.
If your goal is to host your web application on an internal server, you may have the option to go through an internal certification authority in your IT department. The process is similar to the above, but in this case, IT needs to push the certificate or otherwise manually install the certificate on any potential client devices or else a user will receive a warning page. After properly installing the certificate on the client browsers, the result will be that these clients that connect to your server over your internal network will recognize and trust the certificate without getting a warning in the browser.
If you do not have access to those options, you can generate a self-signed certificate. To do this, navigate to the HTTPS tab in the NI Web Server Configuration Utility, click “View Certificate”, then select “Export Root Certificate” from the drop down. Once you create and install the self-signed certificate, your own server machine will trust it, but clients will get a warning when navigating to your URL. To avoid these warnings, similarly to the internal certification case mentioned above, you can take the self-signed certificate and install it on client machines by going through the browser-specific process for trusting the certificate.
You can also choose to ignore the warnings in the browser and connect to the web server anyways, but that can leave you vulnerable to a “man in the middle” attack. These certification processes ensure that the client is talking to the correct server. Without any kind of certificate, the data that you are trying to send to the web server can be read or modified by an active attacker.