Data breaches are one of the most prevalent issues in the technology space in today’s technology-driven world with easy access to information. It not only poses an information risk but often results in financial losses such as loss of trust or government penalties. For instance, in 2018, a Singapore government health tech agency was fined $750k due to a cyberattack on its patients’ records. Marriott International was also fined GBP 18.4M by the UK’s Information Commissioner’s Office due to an unauthorized copying of data by malicious actors.
Despite being regarded as a leader in security, SAP’s product is still prone to gaps and flaws, particularly in custom code development. As such, Security Audits must be carried out in any project. Security Audits typically include a Security Risk Assessment, IT General Controls, Technical Design Review, IT Policy Review, Host Configuration review, Network Vulnerability assessment, Source Code review, and Application Penetration Testing.
As this blog post is intended for SAP development, the focus would be on the SAP custom code development aspect of security risk. Specifically, Source Code Review and Application Penetration testing are both attributed to custom code development where custom-built applications are reviewed and tested for vulnerabilities. Source code review is usually automated through products like Microfocus Fortify or Checkmarx SAST. At the same time, Application Penetration testing involves a mixture of automation with tools such as Burpsuite, Metasploit, Nmap, and manual penetration testing.
The OWASP (Open Worldwide Application Security Project) Foundation, a non-profit community of security experts, publishes OWASP Top 10, which is recognized as the top application security risk and serves as the first step towards more secure coding. This is usually the baseline for both source code review and application penetration testing.
The 2021 OWASP Top 10 items are:
◉ A01 Broken Access Control
◉ A02 Cryptographic Failures
◉ A03 Injection
◉ A04 Insecure Design
◉ A05 Security Misconfiguration
◉ A06 Vulnerable and Outdated Components
◉ A07 Identification and Authentication Failures
◉ A08 Software and Data Integrity Failures
◉ A09 Security Logging and Monitoring Failures
◉ A10 Server-Side Request Forgery
I would not go through all OWASP Top Ten items but will try to add more blog posts on the rest. Here are some tips and guidelines to avoid auditable findings and, more importantly, prevent breaches.
Note: The examples below are oversimplifications of the scenarios. The key takeaway is the security risk and not the business process functionality. These examples are obviously non-productive.
A01 Broken Access Control
This security risk refers to instances where users exceed their intended access permissions. These failures often result in the unauthorized disclosure, alteration, or destruction of information or the execution of business functions beyond the user’s designated scope. This can happen when there is a breach of the principle of least privilege access or circumvention of authority checks within ABAP programming. This risk is also comparable to Business Logic Bypass.
Zero Trust Model – Never Trust, Always Verify
Example
The sales manager for Sales Org 2501 should only be able to see records under his Sales Org. The organization has a custom Sales Order Report that calls custom Odata services created in SAP.
Broken access can occur when an unverified URL call allows access to any information.
The report calls the SALESORDERSET_GET_ENTITYSET and is filtered by Sales Org.
Any experienced user would know that calls can be viewed via Developer tools in modern Web browser such as Chrome Inspector in Google Chrome
In our example, any user can go to Chrome Inspect and run the unsecured service mentioned in the Network tab. In this case, use from Sales Org 2502 have entered Vkorg eq 2501 in filter and was able to access records from Sales Org 2501
In essence, anyone can “override” the network calls without special tools.
How to prevent
◉ Ensure authorization checks in all REST Methods (GET, POST) in the DPC Extension. Don’t assume that navigation or UI filters will protect your application from unauthorized data extraction. The most common mistake is that they would rely on the authorization check from the Parent EntitySet while navigating to the Item Entity. As a best practice, assume that your user would know how to override filters in the browser.
◉ Ensure implementation of authorization controls in CDS Views.
◉ Ensure authorization check on SAP ABAP on specific authorization objects, particularly on data selection.
In the example above, the quick fix is to incorporate an authority check on GET_ENTITYSET before the extraction of data.
After the authorization check is done, if the end user tries to “override” the call, it would get an error message from the call.
Example 2
A custom Fiori Application has been created to create quick Sales Orders
The Odata POST method was created to post the sales order information (Note: this is an oversimplification of the sales order creation. Sales Order creation would require more information than the ones below. This is just to demonstrate the risk)
Similarly, any user can run Chrome Inspect and sniff out the webservice calls. These service calls are posted via normal network calls in the browser without any special tools.
Below is an example POST call from SAP standard S4HANA Migration Cockpit creation of project
The sample Sales Order POST can also be executed using third-party tools such as Postman. Similarly, this information can easily be captured via tools such as Postman Interceptor or Burpsuite. These are open-source applications or have free versions on the internet. More importantly, these are not specialized tools. Any experienced user can do run these programs
From here, a malicious actor can change the values directly and post a different request
Due to UI5’s design, there’s limited way of obfuscating this information nor control the network call.
How to prevent
◉ Ensure that authorization is always checked in all methods. Similar to the first example, an authorization check is crucial in every step and every call.
◉ Ensure data is validated in Odata. This practice might be overhead as these validations are already handled in the front end but security takes precedence over anything else.
In the sample below, values are validated again even if these are auto-populated in the front end or validated in the front end.
Moreover, there are attacks such as defacement attacks that need to be validated through special infrastructure such as Web Application Firewall, Anti-defacement appliances that capture restricted words but it also has to be validated in the Application Layer
These seems to be common sense approach but these are also real-life issues. Developers would likely put validation in one method but forget to put on other methods. Similarly, developers would think attacks would not happen. It takes one attack to damage your application’s reputation.
Key Takeaway: Never Trust, Always Verify which means, always do authorization checks on all Odata methods
A06 Vulnerable and Outdated Components
This risk used to be #2 in OWASP Top 10 but was moved down a big and is still in the Top 10. This pertains to the usage of vulnerable and outdated components in both the front end and back end. In the context of SAP custom development, this is more attributed to frontend development rather than backend development.
Nevertheless, this is often an overlooked risk as most developers would not be wary of the risk of using vulnerable components contains especially for SAP developers.
Here’s a real-life example of a security finding in one of the publicly available web pages that use Fiori.
JQuery itself is delivered with the SAP UI5 libraries and is crucial in any Fiori web application. However, versions do change especially when there are vulnerabilities found. Among the risk of these vulnerabilities is Denial of Service, Prototype Pollution, or Cross Site Scripting. They can locally deface your website or make it seems that the malicious website is legitimate.
How to fix
◉ Subscribe to SAP Communications on security risk. SAP will regularly send and while this is usually irrelevant for SAP development, some of these might be important.
◉ In addition, there are open source vulnerabilities DB that documents the recently found vulnerabilities. These are more relevant to the custom-built Fiori applications. More importantly, if you have old Fiori developments built on old libraries, these have to be regularly reviewed. Below is a sample vulnerability that might still be in old Fiori developments.
Formerly supported or secured modules can be found vulnerable in the future so check has to be done periodically. Attacks can happen inside your organization. In fact, most cyberattacks were done within “secured” protocols
Key Takeaway: Modules that might be secured today, might not be secured tomorrow. Always remember the mantra, Never Trust, Always Verify
No comments:
Post a Comment