2021 Call for Code Awards: Live from New York, with SNL’s Colin Jost! Learn more

Protect your web application by using advanced runtime container security

Summary

In this code pattern, you set up a cloud-native container firewall for either a Kubernetes or Red Hat OpenShift cluster and configure security policies to detect and prevent several types of malicious attacks. Then, you test a vulnerable web application sample to monitor and analyze the generated alerts.

Description

Web application security is a mandatory requirement for any web application accessible on the internet. There are many types of attacks on web applications that can result in loss of sensitive and confidential information, fraud, and denial of service. The Open Web Application Security Project (OWASP), which is a nonprofit foundation, published the top ten attacks on web applications. Web application security must be implemented to prevent such attacks.

In the cloud-native era, applications are deployed in container environments based on Kubernetes. Container security is equally critical to web application security. Container runtime security can monitor all activities within a container to detect threats and can block unauthorized network connections, processes, or file activities.

NeuVector is a cloud-native container firewall for monitoring and protecting Kubernetes container deployments in production. With it, you can inspect container network traffic, learn how an application communicates with other applications, and protect and monitor your container against network and application attacks. NeuVector provides enterprise-grade security for in-depth defense.

In this code pattern, you see how to use NeuVector to prevent web application and container runtime threats. By completing the code pattern, you learn how to:

  • Deploy NeuVector on Kubernetes and Red Hat OpenShift clusters.
  • Configure security policies in NeuVector to detect and prevent the following types of attacks: cross-site request forgery (CSRF), malicious file upload, cross-site scripting (XSS), sensitive data exposure, command injection, SQL injection, API service protection, and container shell access.
  • Test the application for attacks and analyze NeuVector alerts.

Note: This code pattern uses the Damn Vulnerable Web App (DVWA) deployed inside of a container for exploring the capabilities of NeuVector. All of the different types of attacks are simulated by using this application.

Flow

Architecture flow diagram

  1. User (developer) configures security policies in NeuVector.
  2. User (developer or hacker) accesses the web application and triggers some security attacks.
  3. User (admin or developer) receives notification of the security attacks and details on the NeuVector dashboard.

Pre-requisites

Steps

  1. Deploy NeuVector on your cluster
  2. Deploy the sample application
  3. Explore NeuVector
  4. Create policies to detect attacks
  5. Apply the policies to DVWA application
  6. Trigger security events and analyze the alerts

1. Deploy NeuVector on your cluster

Create an instance of the NeuVector Container Security Platform.

  • If you are using an IBM Cloud Kubernetes Service (IKS) cluster, follow the instructions that are provided within the Deploy the NeuVector service on Kubernetes from the IBM Cloud catalog tutorial. Make a note of the public IP of your IKS cluster by using the kubectl get nodes -o wide command. You need this information to access the application deployed on the cluster.

  • If you plan to use an OpenShift cluster, then you choose one of the NeuVector Operators that are located within the OperatorHub web console interface and follow the installation instructions

    Screen capture of the OperatorHub interface with the NeuVector Operator highlighted

Note: The following steps of this code pattern use an IKS cluster to deploy the sample application and NeuVector by using the NeuVector service within the IBM Cloud catalog. However, NeuVector works exactly the same as explained in the following steps on both platforms, Kubernetes and OpenShift.

2. Deploy the sample application

For this code pattern, we chose the popular, open source DVWA (Damn Vulnerable Web Application) sample application as the target for the attacks. The application’s source code is available at https://github.com/digininja/DVWA.

The configuration to deploy that application into a Kubernetes cluster is provided within the GitHub repo for this code pattern as a deployment.yaml file. The deployment configuration uses the container image that is available on DockerHub, which uses port 80 as follows:

image: vulnerables/web-dvwa
ports:
  - containerPort: 80

The NodePort service type is used to expose the application as a service, as follows:

type: NodePort
  ports:
    - port: 80
      nodePort: 32425

Note: The provided deployment configuration uses port 32425 for service. If this port is not available or you want to use a different port, modify it in the deployment.yaml file.

Run the following command to deploy the application:

kubectl apply -f deployment.yaml

Access the application at http://[public-ip-of-cluster]:32425/, replacing public-ip-of-cluster with the public IP of your IKS cluster that you noted in Step 1.

To access the application, log in to the application with the default credentials of admin/password. After you log in to the application the first time, you will see the Database Setup page.

Screen capture of the Database Setup page

Click Create/Reset Database to configure the required database with its tables for the application. When you log in again, you see the page that is titled “Welcome to Damn Vulnerable Web Application”.

Screen capture of the page that appears after the database is set up

Now that the application is up and running, let’s explore NeuVector and set some security policies.

3. Explore NeuVector

Access NeuVector by using its webui link.

Note: Ensure that you activated NeuVector by providing the proper license code before you proceed further. The process is explained for IKS within Step 3.2 of the Deploy the NeuVector service on Kubernetes from the IBM Cloud catalog tutorial.

Use admin/admin for the first time that you log in or use your new password if you already changed it. You are directed to the NeuVector dashboard, as shown in the following screen capture. The dashboard shows different types of charts based on security events, risk, vulnerable pods, and so on. But most of the charts might not have any data if you are accessing the service for the first time.

Screen capture of the NeuVector Dashboard

Select Network Activity and you see that the pods are running in your cluster, similar to the following diagram. Notice that you can see the dvwa-app-** pod, which is the pod of your sample application that was deployed in the previous step.

Diagram of the network activity of pods running in a cluster

You can explore more of the other NeuVector functions that are used in this code pattern:

  • Assets > Containers shows more details, such as its vulnerabilities, stats, state (discover/monitor/protect), and scan status. It is recommended that you turn the ‘Auto Scan’ on to start runtime vulnerability scanning of all containers and hosts, then come back in a few minutes to see results.
  • Assets > System Components shows system components such as controller pods, scanner pods, and enforcers.
  • Policy > Groups provides you with the ability to filter by deployment (application) groups. For example, if you filter for your sample application by using dvwa, when you select this group, you can add more rules (process profile/file access/network), data loss prevention (DLP), switch mode (such as Monitor to Protect), export group policy, and so on.
  • Policy > DLP Sensors allows you to add more DLP sensors, as explained in the next step. After you define the DLP sensors, you can apply it to any group.
  • Notification > Security Events is the place where you get all types of security alerts based on the applied rules and DLP sensors. Security events can also be filtered based on groups and types of rules.

Watch the NeuVector 101 webinar for a comprehensive guide to NeuVector. After you explore the functions, you are all set to use NeuVector with your application. Follow the next steps to set your own security policies and test.

4. Create policies to detect attacks

Let us now set up some policies to detect the various types of attack.

Note: These DLP rules are created for demo purposes. They should be fine-tuned to reduce false positives and false negatives when used in a real environment. Often these patterns are application-dependent and should be tested with specific applications.

a. Cross-site request forgery (CSRF)

CSRF exploits APIs that perform sensitive operations, such as a password change or account deletion. The deployed DVWA application exposes an API for the password change:http://[public-ip-of-cluster]:32425/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change

Note: public-ip-of-cluster is the public IP of the cluster that you noted earlier.

In a valid authenticated session, this API can be invoked to change the password of the user. It can be exploited by attackers.

Let us set up a policy that detects an invocation to this API.

  • Click Policy -> DLP Sensors on the NeuVector Dashboard.

    Screen capture of where the  DLP Sensors option is located in the Dashboard menu, under Policy

  • Click Add.

    Screen capture of where the Add button is located

  • Enter a name for the sensor, such as sensor.cross.site.request.forgery.

  • Enter a name for the regex pattern for detection, such as CSRF.password.change.requested.
  • Enter a regex pattern that can detect the attack, such as password_new=.*&password_conf=.*.

    Note: The name of the sensor and the pattern can be any name of your choice.

    Screen capture of the Add Sensor page where you can add details

  • Click + and then click Add.

Similarly, we add other sensors.

b. Malicious file upload

The DVWA application provides a function to upload the file. If it is a PHP file with shell commands that can be run on the container shell to get some confidential information, it can be invoked by an attacker to get such information. To avoid that, you can set a security policy that scans the file to be uploaded and alerts or denies the event. For example, if a user tries to upload a PHP file that contains instructions to run shell commands, then the following policy detects shell_exec commands inside the PHP file.

Add a sensor for detecting malicious file uploads:

  • Sensor name: sensor.malicious.phpfile.upload
  • Pattern name: malicious.file.shell.exec.command
  • Regex pattern: php.*shell_exec

c. Cross-site scripting (XSS)

The DVWA application has vulnerable APIs that malicious scripts use to be sent to the application. The scripts can be embedded in query parameters of a GET request or inside form data of a POST request. The following policies detect scripts that are sent to the application from inside a GET or POST request.

Add a sensor for detecting scripts in a GET request:

  • Sensor name: sensor.xss.get
  • Pattern name: XSS.script.in.request
  • Regex pattern: GET.*%3Cscript%3E.*HTTP/1

Add a sensor for detecting scripts in a POST request:

  • Sensor name: sensor.xss.post
  • Pattern name: XSS.post.request
  • Regex pattern: POST.\*%3Cscript%3E.\*

d. Sensitive data exposure

Sensitive data, such as credit card or social security numbers, can be sent to the application. Such information is compromised if it is not encrypted. By default, NeuVector has a DLP sensor called sensor.creditcard that is used to detect credit card information within requests. You can specify sensors to detect other kinds of sensitive information that is transmitted to the application.

e. Command injection

The DVWA application exposes an API with which you can ping an IP address or URL. It is possible to inject other commands with the IP address or URL and receive results. Here, you set up a policy to detect the ls command that is injected.

Add a sensor for detecting command injections:

  • Sensor name: sensor.command.injection
  • Pattern name: command.injection.ls.command
  • Regex pattern: POST.\*%3Bls.\*

f. SQL injection

NeuVector has a built-in SQL injection detection so you don’t need to create pattern signatures in the DLP sensor. The built-in detection covers different forms of SQL injection that cannot be detected with simple regex patterns. Using DVWA’s SQL injection test, an attacker can get the full list of username and password without proper authorization.

Note: To test the SQL injection with the DVWA app, you must deploy the MySQL database as a separate container and configure DVWA to use it. This is detected by the database connection.

g. API service protection

The DVWA application exposes an API that gives access to the uploaded files. A user can try to download or execute the file to get some important information. This policy detects any invocation to the API.

Add a sensor for detecting forbidden API access:

  • Sensor name: sensor.forbidden.api
  • Pattern name: forbidden.uploads.folder.accessed
  • Regex pattern: GET.*/hackable/uploads.*HTTP

5. Apply the policies to DVWA application

By this point, you defined the required DLP sensors. To see them in action, you must apply these sensors to the DVWA application.

a. Add DLP sensors to the application group

To add the sensors to monitor the web application for attacks, select Policy from the menu and select Groups.

Filter for the DWVA application, as demonstrated by the following screen capture.

Screen capture of the Groups page with the DLP tab highlighted

The sensors that you created earlier are listed. Select all of the sensors and click Apply.

Screen capture of the Choose sensor page that displays all of the created DLP sensors

b. Container shell access or process profile rules

Go to the Process Profile Rules tab as shown in the following screen capture.

Screen capture of the Process profile rules tab and the `sh` process name is highlighted with the Action set as `Deny`

Initially, NeuVector learned, on its own, the required processes for the application to run. Therefore, you see that some of the process profile rules are already defined by default with the Action field set to Allow. You are allowed to change the action for those.

So if a user tries to access the container shell directly or somehow gets access, then the process profile rules detect them. But if you have a specific requirement, such as “do not allow access of /bin/sh“, then you can add new rules directly for the group by using Policy > Groups, as shown in the screen capture.

c. Change the policy mode for the application

At this moment, Policy Mode is set to Discover. Since all of the policies are now set, you can change the policy mode and test the system:

  • Select Policy from the menu.
  • Select Groups and choose the group for the DWVA application, as shown in the following screen capture.
  • Click Switch Mode and select Monitor. The Monitor mode generates warning alerts for all of the attacks, as illustrated in the following screen capture.

Screen capture of the Members tab, where the Switch mode list is expanded and `Monitor` is highlighted

If you change the mode to be Protect, any request that triggers the security event is blocked and the event is recorded with the Deny action.

6. Trigger security events and analyze the alerts

a. Cross site request forgery (CSRF)

Let us simulate this attack:

  • On the DWVA application dashboard, click CSRF on the menu bar.

    Screen capture of where the CSRF option is located on the menu bar

  • Enter a new password with confirmation and click Change. This sends a request to the server to change the password.

  • On the NeuVector Dashboard, select Notifications and click Security Events.

You see the violation that is illustrated in the following screen capture:

Screen capture of the CSRF violation alert message

b. Malicious file upload

Create a file called test.php with the following content:

<?php echo shell_exec("ls");?>

To simulate this attack, click File Upload on the menu bar of the DWVA application dashboard.

Click Browse, select the test.php file that you created earlier, and click Upload.

On the NeuVector Dashboard, select Notifications and click Security Events. You see the violation that is illustrated in the following screen capture.

Screen capture of the Malicious file violation alert message

c. Reflected cross-site scripting

The DVWA application exposes an API that enables an attacker’s script to run in a user’s browser:

http://[public-ip-of-cluster]:32425/vulnerabilities/xss_r/?name=[user entered data]

Note: public-ip-of-cluster is the public IP of the cluster that you noted earlier.

Let us simulate some XSS attacks on the DVWA application:

  • Go to the DVWA application dashboard and click XSS (Reflected) on the menu.
  • Enter the text with a script tag in the What’s your name? field as <script>alert(xss)</script>.
  • Click Submit. You see an xss JavaScript alert message.
  • On the NeuVector Dashboard, select Notifications and click Security Events.

You see the violation that is illustrated in the following screen capture.

Screen capture of the Reflected cross-site scripting violation alert message

d. Stored cross-site scripting

The DVWA application exposes a form at the URL: http://[public-ip-of-cluster]:32425/vulnerabilities/xss_s/.

Note: public-ip-of-cluster is the public IP of the cluster that you noted earlier. It is possible to embed JavaScript code in the form and submit it. This script is executed for all other users when the page is loaded.

  • Go to the DVWA application dashboard.
  • Click XSS (Stored) on the menu.
  • Enter a name in the Name field.
  • In the Message field, enter <script>alert('bad script')</script>.
  • Click Sign Guestbook. The message is added on the page, and the script runs, displaying a bad script JavaScript alert.
  • On the NeuVector Dashboard, select Notifications and click Security Events.

You see the violation that is illustrated in the following screen capture.

Screen capture of the Stored cross-site scripting violation alert message

e. Sensitive data exposure

In the DVWA application, the data is not encrypted. Any sensitive information such as credit card or social security numbers is vulnerable to theft.

Let us use the XSS (Stored) option in the application and embed a credit card number in the message.

  • Go to the DVWA application dashboard.
  • Click XSS (Stored) on the menu.
  • Enter a name in the Name field.
  • In the Message field, enter 4563876598762345.
  • Click Sign Guestbook.
  • On the NeuVector Dashboard, select Notifications and click Security Events.

You see the violation that is illustrated in the following screen capture.

Screen capture of the credit card violation alert message

f. Command injection

A sensitive command can be embedded as part of other data that is sent to the application. Let us simulate a command injection attack:

  • Go to the DVWA application dashboard.
  • Click Command Injection on the menu.
  • In the Enter an IP address field, enter example.com;ls.
  • Click Submit.

    You see a response from the application with a list of files in the application directory:

    PING example.com (93.xxx.xxx.34): 56 data bytes
    64 bytes from 93.xxx.xxx.34: icmp_seq=0 ttl=56 time=1.456 ms
    64 bytes from 93.xxx.xxx.34: icmp_seq=1 ttl=56 time=1.312 ms
    64 bytes from 93.xxx.xxx.34: icmp_seq=2 ttl=56 time=1.273 ms
    64 bytes from 93.xxx.xxx.34: icmp_seq=3 ttl=56 time=1.340 ms
    --- example.com ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 1.273/1.345/1.456/0.068 ms
    help
    index.php
    source
    
  • On the NeuVector Dashboard, select Notifications and click Security Events.

    You see a violation for the command injection policy. In addition, you see violations for running the ping and ls commands on the container shell, as illustrated in the following screen capture.

    Screen capture of the command injection violation alert message

g. API service protection

This feature detects invocation of prohibited APIs on the application. Let us invoke the test.php file that you uploaded earlier.

  • Invoke the URL on the browser: http://[public-ip-of-cluster]:32425/hackable/uploads/test.php

    Note: public-ip-of-cluster is the public IP of the cluster that you noted earlier.

    When the access is not prevented, you see the following response on the browser:

    dvwa_email.png test.php
    
  • On the NeuVector Dashboard, select Notifications and click Security Events.

    You see the violation that is illustrated in the following screen capture.

    Screen capture of the forbidden uploads violation alert message

h. Container shell access

The container shell was accessed when you tested command injections and also when you invoked the test.php file to test for API service protection attacks. NeuVector triggers alerts when any command is run on the container shell, as shown in the previous screen capture.

7. Change policy mode to Protect

Let us now change the policy mode to deny access and prevent the attack.

  • Select Policy from the menu and select Groups.
  • Select the group for the DWVA application.
  • Click Switch Mode and select Protect.

Now you can test any of the attacks. Let us test for an API service protection attack by invoking the URL on the browser again: http://[public-ip-of-cluster]:32425/hackable/uploads/test.php

Note: public-ip-of-cluster is the public IP of the cluster that you noted earlier.

This time, the API cannot be accessed and you see the following alert on the Security Events page:

Screen capture of a forbidden uploads violation deny message

Conclusion

In this code pattern, you saw how to set up security policies in NeuVector by using DLP sensors. The sensors might detect various types of web application attacks, such as CSRF, XSS, command injection, SQL injection, forbidden API access, sensitive data exposure, and container shell access. The security policies are confidential to your organization and depend on the web application that you are protecting. The exhaustive list of policies to protect your web application must be developed in collaboration with the security team within your organization. When vulnerabilities are detected, the application must be enhanced to be made secure against those type of attacks.

Going forward, NeuVector plans to create a separate section of its console to configure OWASP signature and pattern-based detection. Although the underlying detection engine is similar to DLP functions, there is a difference between looking for OWASP and other network attacks versus inspecting payloads for sensitive data. In addition, enabling the simple import of such patterns will make it easier for security teams to update and apply these rules.

License

This code pattern is licensed under the Apache License, Version 2. Separate third-party code objects invoked within this code pattern are licensed by their respective providers pursuant to their own separate licenses. Contributions are subject to the Developer Certificate of Origin, Version 1.1 and the Apache License, Version 2.

Apache License FAQ