Security in NI Web Technology

National Instruments is committed to serving the needs of our customers, including the need to protect applications and data in the web. This article describes practical ways to achieve this, especially when using the NI Web Server. 

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.

TLS Encryption

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 [1]. 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).

Authentication  

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

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.  

Hosting your web application on SystemLink Cloud allows you to take advantage of all the aforementioned security features without having to set them up yourself. Access to SystemLink Cloud requires a license for either G Web Development Software or SystemLink and an active software subscription license or service agreement. 

To host a web application in SystemLink Cloud, you must build the web application into a package following these guidelines. Then you must upload the package to the web app hosting page. From there, you can set the web application to private or public, or directly share the web application with another person.  

Another difference to note in hosting with SystemLink Cloud versus through your own NI Web Server is the use of API keys. You can think of an API key as the username and password for a service trying to access SystemLink Cloud, namely the SystemLink Data Services that transfer data from a test and measurement application to your web application. For example, this is what the authentication step should look like on the block diagram of your application when using SystemLink Cloud:

Figure 2: Authentication with SystemLink Cloud 

While the API key authenticates access to the web application, a policy authorizes what a user can do once inside the application. The policy can authorize read, write, modify, create, and delete permissions for SystemLink tags and publish and subscribe permissions for SystemLink messages.

Though the concept of API keys and policies is different from what you find when using the NI Web Server, the data encryption benefits are the same. Data is stored today in an object database, and interaction with the database is encrypted and authenticated with unique credentials within SystemLink Cloud.  

SystemLink Cloud is constantly monitored by NI for any malicious attacks and has proven to resist attacks in many cases. SystemLink Cloud has built-in prevention of Denial of Service attacks, Cross Site Scripting attacks, and any request that hits the site that is not validated with the proper API key and formatting is automatically dropped.   

When communicating with on-premises data services such as the SystemLink API from G Web Development Software, you must provide a server URL (i.e. https://localhost), a username, and a password.  

When the web application is built and hosted on the NI Web Server or SystemLink Cloud, the server URL, username, and password are not needed and should not be used. This deliberately minimizes security vulnerabilities.

Figure 3: Note the input differentiation between using on-premises data services versus hosting within the NI Web Server or SystemLink Cloud

For the sake of approachability and learnability in NI’s examples, they may include username and password fields on the WebVI’s block diagram. NI discourages this practice for all applications used in production. Authentication credentials should not be stored in constants on the block diagram of a WebVI. This is true for usernames, passwords, and API keys. Doing this could lead to credentials stored being in version control or allow a malicious attacker to retrieve your credentials by accessing the code running the browser. For example, modern browsers allow a user to view the source of the page and network activity that the page performs, including authentication headers.  

One secure option is to require that the user inputs their credentials into controls on the panel of the WebVI when accessing it through a browser. That way, credentials are not stored anywhere to be accessed by attackers. Another option is to require that the user first navigates to the IP address of the NI Web Server, logs in, and then accesses the built web application. Logging into this UI stores an authentication cookie in your browser that is automatically sent with calls to SystemLink data services. This eliminates the need to enter a username or password directly to the WebVI, either on its panel or its diagram. Please note a user can access the URL of the web application without logging in, but in order to read/write SystemLink data, they will have to login to the SystemLink Web UI at http://<IP Address of the web server machine>:<port>. These options are worth considering when hosting a web application yourself through the NI Web Server, but do not apply when hosting the web application through SystemLink Cloud.  

You may choose to host your web application on SystemLink Cloud, so that NI takes care of security, hosting, and access management for you. To access your web application, you log into systemlinkcloud.com with your ni.com credentials. Doing so allows an authentication cookie in your browser to be automatically sent with calls to SystemLink Cloud. This eliminates the need to enter an API key or server URL in the web application.

There is a fundamental risk to hosting a web server on an embedded device. Web servers are always listening for connections and will always accept requests to connect; that is their purpose. This means that web servers are a prime target for malicious bots. Even if the web server does not allow a bot to fully connect, bots can still flood the web server with requests to connect, which chews up resources on the web server. Losing resources like this can be detrimental to some applications, and this is often unacceptable especially for embedded or real-time applications which naturally have finite, critical resources. Even though real-time controllers are designed to give CPU to prioritized sections of the application, bots can still take up memory resources.  

Regardless of which web server or embedded device you use, this is a risk simply due to the nature of web servers and embedded applications. If you consider the uptime of your application to be critical, it is strongly discouraged that you run a web server with access to the same resources as your critical application. It is for this reason that NI discourages hosting web applications on any real-time controllers such as CompactRIOs, Industrial Controllers, or PXIs. The recommended approach when connecting real-time devices such as these to the web is to host the web server and application on an arbitrated machine and set up data communications between the devices and the arbitrated web server. These data communications can be accomplished with LabVIEW Web Services or the SystemLink API. If dedicating additional hardware to act as the web server is not an option, utilizing SystemLink Cloud for hosting the web application could be a desirable alternative. This means that the embedded device is making one known, secure connection with a trusted server and will not be exposed to superfluous connections from bots or extraneous clients.  

If hosting on a real-time device is an absolute requirement, there are steps that can be taken to mitigate some risk. Generally, you should avoid having the device accept incoming requests and instead only allow it to reach out to specific connections. You should also take advantage of SSL, limit the number of client connections to the embedded web server, and use Secure Remote Password (SRP). SRP is an authentication protocol that NI built in to the embedded web server that drops invalid connections very quickly without using many resources. This is used when you log in with the LabVIEW HTTP VIs or when you log into the Silverlight-based web interface (WIF). Additionally, you should use permissions wherever possible and ensure all data is encrypted when it travels over a network. Information on securing LabVIEW Web Services in this way can be found in the White Paper titled "LabVIEW Web Services Security".  

NI is committed to providing built-in protection for web applications and their data, and is constantly watching for security vulnerabilities that need addressing. Below are just a few ways NI protects against common web security threats.

• Cross Site Scripting (XSS) - This is the most common type of attack. XSS occurs when an attacker injects malicious code or scripts into a website that does not modify or sanitize the attacker’s input. For example, if a forum website does not sanitize the posts that users submit, an attacker can submit malicious code that then runs on all the users’ browsers when the post is loaded. NI’s web technology sanitizes all inputs and displayed values using escape strings, which is a standard best practice.  
• SQL Injection – This type of attack can happen if one of the inputs in a website feeds directly into a database without first sanitizing the input. For example, an attacker could enter code into the input fields that could delete a database, modify it, or access the data without any user permission. NI’s web technology uses MongoDB instead of SQL, so it is not necessarily vulnerable to SQL injection. However, NI still sanitizes inputs to MongoDB.  
• Cross Site Request Forgery (CSRF) - This type of attack, mentioned earlier, happens when an attacker accesses or modifies data from one web application by making requests from another unauthorized web application. To protect against this, NI web technology gives users the ability to control which requests to their web application are allowed via the NI Web Server Configuration Utility. Requests are vetted at arrival to the web application, before they can get to the underlying web services.   

By following the best practices explained in this White Paper, developers can be confident that their web application and data are as secure as possible with the tools available today, barring any misconfiguration. Additionally, NI is committed to continually providing security-conscious development tools well into the future. We base our technology off industry standard components such as Apache and OpenSSL, and we keep up to date with the latest security patches so any risks are mitigated quickly.

To learn more about using NI’s newest web technology, check out the following links:

• Learn more about G Web Development Software
• The Future of Web Application Development
• Learn more about SystemLink Cloud