Securing SAP Fiori with AWS WAF (Web Application Firewall)

Introduction

When SAP customers embark on a journey to implement SAP S/4HANA, many have questions on how to secure SAP Fiori, the User Interface component of SAP applications based on HTML5. As the starting point, we will refer to The OWASP Top 10 (Open Web Application Security Project), which represents a broad consensus about the most critical security risks to web applications. By adopting this, you start the mitigation process of ensuring that the security risks to SAP Fiori are minimized.

Even though SAP provides secure programming guide to mitigate the security risks, it is preferred that the mitigation is in place before web requests are reaching the SAP Fiori system to ensure that resources are always available to serve end users to execute their business processes. We will introduce AWS WAF which is a web application firewall to filter the web requests before reaching SAP Fiori.

With WAF, you can allow or block web requests to SAP Fiori by defining customizable web security rules and leverage AWS Managed Rules. AWS Managed Rules for AWS WAF is a managed service that provides protection against common application vulnerabilities or other unwanted traffic, without having to write your own rules. When your security requirement goes beyond AWS managed rules, you can review the Managed Rules being offered in AWS Marketplace, which are created by security experts with extensive and up-to-date knowledge of threats and vulnerabilities. You can find out more here.

In this blog, we will provide a how-to guide for SAP customers on AWS to implement AWS WAF and AWS Managed Rules with SAP Fiori. This is the extension of the related blog series on Improving SAP Fiori performance with Amazon CloudFront and Securing SAP Fiori with Multi Factor Authentication. You can also find out more details of WAF in Use AWS WAF to Mitigate OWASP’s Top 10 Web Application Vulnerabilities and AWS Best Practices for DDoS Resiliency.

Solution Overview

The diagram above describes the traffic flow between end-user with web browser and SAP Fiori. This simplified architecture will be used to describe the deployment process of AWS WAF and SAP Fiori. For productive deployment, further enhancement to this architecture will be required depending on your requirements, such as High Availability setup across two AWS Availability Zones, and connectivity to your own on-premises data centre, etc.

The Application Load Balancer (ALB) will route the traffic through AWS WAF so it can be inspected for security risk mitigation based on web security rules defined. When the traffic is allowed, it will then be returned to ALB and continued to back-end SAP Web Dispatcher and/or SAP Fiori.

When you want to deploy SAP Fiori globally, you can integrate AWS WAF with Amazon CloudFront as described here, as it allows you to reduce impact to SAP Fiori system availability for end users by delegating the protection of AWS WAF at CloudFront edge locations. AWS WAF comes with pre-configured rules and tutorials that allows you to automate security using AWS Lambda.

Prerequisites

Since we will integrate WAF with ALB, the ALB must be configured to point to either SAP Web Dispatcher or SAP Fiori, through its target group. You can follow the step-by-step documentation.

Solution Implementation

1. Deploy AWS WAF and AWS Managed Rules by following AWS Security Automation Guide using AWS CloudFormation
2. In Specify stack details screen, provide the parameter values as below, and then select Next
3. In Configure stack options screen, then select Next, and then review all the parameter values, then select Create Stack
4. After the CloudFormation finished successfully, you can navigate to https://console.aws.amazon.com/wafv2/homev2/web-acls to verify that the Web ACLs are successfully deployed
5. After verification, you associate the AWS WAF to the AWS Application Load Balancer (ALB). This effectively routes all the traffic through WAF prior to being processed by SAP Fiori.

Solution Testing

In this section, we will try a few sample attack scenarios and demonstrate AWS WAF in action to protect SAP Fiori. The purpose of this manual testing approach is to assert that WAF is active for the associated AWS resource. The approach we have shown below is not a recommended penetration testing approach. It is used only as a quick and handy way within the limited scope of this blog to try out a few scenarios without the need to set up of elaborate testing tools

Before you begin

1. We will use several tools to help with this testing such as curl, Apache ab tool and Chrome browser
2. Go to AWS console, and navigate to AWS WAF, then Web ACLs, and select the AWSWAFSecurityAutomations. You can then navigate to the custom response bodies tab and select “Create custom response body”.
3. Enter an appropriate custom response in the provided textbox as shown below. Then save as WAF_Response.
4. Select the AWSWAFSecurityAutomationsIPReputationListsRule from the rules tab of the same Web ACL. On this screen, please note down one of the IPv4 IP addresses for testing later, and select edit.
5. In the edit screen, change the configuration of this rule as shown below, i.e., use X-Forwarded-For header for identifying request originating address.
6. In the Action section on the same page, select the custom response of WAF_Response. Then save the rule.
7. In the same way (by repeating step 4-6 above), change the actions section of the following rules as well :
   • AWSWAFSecurityAutomationsHttpFloodRateBasedRule
   • AWSWAFSecurityAutomationsSqlInjectionRule
   • AWSWAFSecurityAutomationsXssRule
8. After saving the rules you can verify that the changes are reflected, as shown below.

Execute Testing

Scenario 1: IP Allow / Deny List

A number of organizations maintain reputation lists of IP addresses operated by known attackers, such as spammers, malware distributors, and botnets. This rule leverages these reputation lists to help you block requests from malicious IP addresses. To test this scenario, you use a curl command to make a request to the SAP Fiori server via the AWS ALB. The URL used below is for the SAP Fiori login page, you can change this to any URL of the SAP Fiori application. As part of this request, you specify the X-Forwarded-For header value with one of the IP addresses noted in AWSWAFSecurityAutomationsIPReputationListsRule.

Example request to execute from command line:

curl-v https://<ALB-Host-of-SAP-Fiori>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html \ -H X-Forwarded-For:124.157.0.1

Example response:

You should be able to note the custom response coming from WAF that indicates that the request is blocked.

Scenario 2: SQL Injection

SQL Injection is used by attacker to obtained sensitive information, such as user id and password which allows them to gain access to website. AWSWAFSecurityAutomationsSqlInjectionRule will block web requests that contains potentially malicious SQL Code. To test this scenario, you open a Chrome browser window and point to the SAP Fiori page with a form submission. For example: SAP Fiori login page. Then open the Chrome Developer Tool (Network).

Once you submit the form, then in the Developer tool, you can right-click to copy the request and response in curl format.

Example request to execute from command line:

curl-v https:///sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html \ -H 'authority: <ALB-Host-of-SAP-Fiori>' \
-H 'cache-control: max-age=0' \
-H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"' \
-H 'sec-ch-ua-mobile: ?0' \
-H 'origin: https://<ALB-Host-of-SAP-Fiori> (https://<ALB-Host-of-SAP-Fiori>/)' \
-H 'upgrade-insecure-requests: 1' \
-H 'dnt: 1' \
-H 'content-type: application/x-www-form-urlencoded' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36' \
-H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
-H 'sec-fetch-site: same-origin' \
-H 'sec-fetch-mode: navigate' \
-H 'sec-fetch-user: ?1' \
-H 'sec-fetch-dest: document' \
-H 'referer: https://<ALB-Host-of-SAP-Fiori>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html' \
-H 'accept-language: en-US,en;q=0.9,bn;q=0.8,hi;q=0.7' \
-H 'cookie: sap-usercontext=sap-client=100; sap-login-<………>' \
--data-raw 'sap-system-login-oninputprocessing=onLogin&sap-urlscheme=&sap-system-login=onLogin&sap-system-login-basic_auth=&sap-client=100&sap-accessibility=&sap-login-XSRF=<………>&sap-system-login-cookie_disabled=&sap-hash=&sap-user=SELECT * FROM USERS --&sap-password=<………>r&sap-language=EN'

This request was blocked by the AWSWAFSecurityAutomationsSqlInjectionRule managed rule in the WAF Web ACL. The custom WAF_response as the previous scenario was observed

Scenario 3: XSS Attack

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise trusted website. The malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that website. AWSWAFSecurityAutomationsXssRule will inspect commonly explored elements of incoming requests to identify and block XSS attacks. To test this scenario, we will use a parameter in the web request filled with a JavaScript snippet, as you can see below.

Example request to execute from command line:

curl-v https://<ALB-Host-of-SAP-Fiori>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?query=<script>alert("Bad script")</script>' 

This request was blocked by the AWSWAFSecurityAutomationsXssRule managed rule in the WAF Web ACL. The custom WAF_response as the previous scenario was observed.

Scenario 4: HTTP Flooding

HTTP Flooding is another attack scenario which can cause significant slowdown to a website due to the large number of requests being sent in a very short timeframe. In the worst situation, this attack can render a website to stop serving requests from legitimate end users. AWSWAFSecurityAutomationsHttpFloodRateBasedRule is a rate-based rule that will trigger when web requests from a client exceed a configurable threshold. To test this scenario, you will use Apache HTTP server benchmarking tool (ab command), which can generate web requests in short period of time. Using ab command, you send 100 valid requests from the same client to the server, and you will attempt to repeat another set of 100 requests again every 3 minutes. In the first few requests, you will see HTTP responses with a status code of 200 (which indicates allowed requests).However in the subsequent requests, you will notice HTTP responses outside of the 2xx class of status codes, such as 403, which represents “Forbidden”, a blocked request.

This is because AWSWAFSecurityAutomationsHttpFloodRateBasedRule managed rule contains 100 maximum requests (rate limit) which is evaluated every 5 minutes.

Below are the ab command line outputs from both allowed and blocked request batches

Sampled Requests

All of the blocked and allowed observations are captured in the Sampled Requests section of the AWS WAF Console under Web ACLs.Here you can view the sampled web requests in order to do further monitoring and deep dive into each of the traffic and rules observed.

Estimating Cost for WAF

To help with the cost estimation of WAF deployment for SAP Fiori, you can consider the below scenario.

• For a typical SAP Fiori application, a user will generate of about 50-150 web requests in 1 transaction depending on the complexity of the Fiori app
• We shall deploy AWS Managed Rules (8 Web ACLs with 1 rule each), and no other Managed Rule Group
• Assuming 100 users creating about 20 documents per day, we will have maximum of 6,000,000 web requests per month (= 100 * 20 * 150 * 20). This number can be more accurate if you have information from your SAP system through SAP EarlyWatch Alerts and audit reports.
• For Singapore Region as per the AWS Calculator, the estimated cost will be
  • 8 Web ACLs per month x 5.00 USD = 40.00 USD (WAF Web ACLs cost)
  • 0 Rule Groups per Web ACL x 0 Rules per Rule Group = 0.00 Total Rules in Rule Groups
  • 1.00 Billable Rules per month x 1.00 USD = 1.00 USD (WAF Rules cost)
  • 6 requests per month x 1000000 multiplier for million x 0.0000006 USD = 3.60 USD (WAF Requests cost))
  • 40.00 USD + 1.00 USD + 1.80 USD = 42.80 USD
  • AWS WAF cost (monthly): 44.60 USD

When you are using subset or all of functionalities of WAF Security Automations solution, you will also need to consider the cost of other services, such as Amazon Kinesis Data Firehose, Amazon S3, Amazon Lambda and Amazon API Gateway. You can refer here for more detailed pricing information.

Conclusion

We have discussed detailed steps on how to implement AWS WAF for SAP Fiori. We recommend the use of AWS WAF to minimize the security risks related to SAP Fiori Applications. AWS WAF can prevent excessive use of SAP Fiori resources against cyber attacks, thus improve system availability and performance. You can leverage AWS Managed Rules for AWS WAF, so you do not have to write your own ruleset, this will speed up your security mitigation actions as it reduces your manual effort on writing and maintaining rules. If your security need goes beyond AWS Managed Rules for AWS WAF, you can subscribe to alternative solutions provided by AWS partners in AWS Marketplace.

Besides protecting SAP Fiori, AWS WAF can be extended to protect other SAP services, such as SAP Process Orchestration, SAP Enterprise Portal, SAP API Management, SAP Business Technology Platform.

You can find out more about SAP on AWS and AWS WAF from the AWS product documentation.