The Importance of Security Reviews for Applications on Enterprise Platforms

As organizations increasingly rely on enterprise platforms like SharePoint, ServiceNow, Archer, Appian, Salesforce and SAP to develop critical applications, there is a common misconception that these platforms' built-in security features are sufficient to protect the applications from all potential threats. While these platforms indeed offer robust security mechanisms, relying solely on these features can leave applications vulnerable to various risks. Conducting a thorough security review is essential to ensure that applications remain secure, especially when customized configurations, third-party integrations, and the constant evolution of the threat landscape are considered.
 

Authorization Controls: The First Line of Defense
One of the primary security concerns in application development is ensuring proper authorization controls. Authorization determines what actions users are permitted to perform within an application and which data they can access. Enterprise platforms provide default authorization mechanisms, but organizations often need to customize these controls to meet specific business requirements. Customizations may involve defining unique user roles, permissions, and access levels that deviate from the platform's standard configurations. However, such customizations can introduce vulnerabilities if not implemented correctly.


For example, poorly configured authorization controls might enable unauthorized users to access sensitive data or carry out critical actions beyond their designated privileges, leading to data breaches, regulatory violations, and potential damage to the brand. A comprehensive security review is essential to detect and address any flaws in the authorization setup, ensuring that users are restricted to the information and functions relevant to their roles.
 

Logical Flaws: The Hidden Dangers in Business Logic
Business logic is the backbone of any application, dictating how data flows, how processes are executed, and how users interact with the system. However, logical flaws in business processes can lead to significant security vulnerabilities that are often overlooked. These flaws might allow attackers to bypass critical controls, manipulate workflows, or execute unintended actions, all of which could have serious consequences.


For example, in an application developed on a platform like Archer, a logical flaw might allow a user to bypass an approval process and gain access to confidential documents without the necessary authorization. Such vulnerabilities can be difficult to detect through traditional security measures, as they do not involve technical exploits but rather exploit weaknesses in the business process itself. A security review that includes thorough testing of business logic is essential to uncover and address these flaws, thereby safeguarding the integrity and functionality of the application.
 

Zero-Day Vulnerabilities: The Ever-Present Threat
No platform, regardless of its security features, is immune to zero-day vulnerabilities—previously unknown security flaws that can be exploited by attackers before the platform provider releases a patch. These vulnerabilities represent a significant threat because they are often exploited quickly after discovery, leaving applications exposed to attacks.


Even though enterprise platforms like SharePoint and SAP are routinely updated to address known vulnerabilities, zero-day threats can still present significant risks to applications. Organizations need to remain vigilant in detecting potential zero-day vulnerabilities and be ready to respond quickly to any new threats. Incorporating vulnerability assessments and regular security updates into the security review process is critical for minimizing the risks associated with zero-day vulnerabilities.
 

Customization and Configuration: The Double-Edged Sword
One of the primary reasons organizations choose enterprise platforms is the ability to customize applications to meet their unique business needs. However, customization and configuration changes can introduce significant security risks. Unlike out-of-the-box solutions, customized applications may deviate from the platform's standard security practices, potentially exposing vulnerabilities that would not exist in a standard configuration.


For example, a seemingly small change in a SharePoint configuration—like modifying default permission settings or enabling a feature for convenience—could unintentionally create a security gap that attackers might exploit. Furthermore, custom code added to the platform often lacks the rigorous security testing applied to the platform itself, heightening the risk of introducing new vulnerabilities. Conducting a thorough security review that evaluates all customizations and configurations is crucial to ensuring these changes don’t compromise the application’s security.
 

Integration with Third-Party Systems: Expanding the Attack Surface
Modern applications often require integration with third-party systems to enhance functionality, whether for user authentication, data analytics, or front-end services. While these integrations can provide significant benefits, they also expand the attack surface, introducing new security challenges that must be addressed.


For example, integrating a third-party single sign-on (SSO) service with a ServiceNow application can simplify user access management but also creates a potential entry point for attackers if the SSO service is compromised. Similarly, integrating external data analytics tools with an Appian application may expose sensitive data to third parties, increasing the risk of data breaches. A security review that includes thorough testing of all third-party integrations is vital to identify and mitigate these risks, ensuring that data is securely transmitted and that external services do not introduce vulnerabilities.
 

Unpatched or Outdated Versions: A Persistent Risk
Running outdated or unpatched versions of an enterprise platform or its integrated components is a common yet significant security risk. Older versions may contain known vulnerabilities that have already been exploited in the wild, making them prime targets for attackers. Even if the platform itself is kept up to date, third-party plugins, libraries, or custom components may lag behind, creating weak points in the application's security.


Regular security reviews should include a comprehensive audit of all components used in the application, ensuring that they are up to date with the latest security patches. Additionally, organizations should implement a proactive patch management process to address vulnerabilities as soon as patches are released, reducing the window of exposure to potential attacks.

Conclusion: The Necessity of Continuous Security Vigilance
In today’s complex and rapidly evolving threat landscape, relying solely on the built-in security features of enterprise platforms is insufficient to protect applications from the myriad risks they face. Whether due to customizations, third-party integrations, or emerging vulnerabilities, applications on platforms like SharePoint, ServiceNow, Salesforce, Archer, Appian, and SAP require continuous security vigilance.


This is where the expertise of a company like Blueinfy becomes invaluable. Having performed numerous security reviews across these platforms, Blueinfy possesses deep insights into where vulnerabilities are most likely to lie. Their extensive experience allows them to pinpoint potential risks quickly and accurately, ensuring that your application is thoroughly protected. By leveraging Blueinfy’s knowledge, organizations can significantly reduce the likelihood of security breaches, protect critical business applications, and maintain compliance with regulatory requirements. Blueinfy’s ability to identify and mitigate risks effectively adds substantial value, safeguarding not just data and processes, but also the organization’s reputation in an increasingly security-conscious world.

Article by Hemil Shah

Performing Security Code Review for Salesforce Commerce Cloud Application


Salesforce Commerce Cloud (SFCC), formerly known as Demandware, is a robust cloud platform tailored for building B2C e-commerce solutions. It offers a reference architecture, the Storefront Reference Architecture (SFRA), which serves as a foundational framework for website design. SFRA is carefully designed to act as a blueprint for developing custom storefronts. Given your familiarity with this platform, we will forego an extended introduction to Commerce Cloud. Instead, let's review some fundamental concepts before proceeding to the code review.

Access Levels
The platform offers -

  • Developer Access: For users involved in the development of storefront applications, this access level permits the creation of new sites or applications and the deployment of associated code.
  • Administrator Access: Primarily used for managing global settings across all storefront applications within the SFCC system. This level also enables "Merchant Level Access".
  • Merchant Level Access: Allowing users to manage site data (import/export), content libraries, customer lists, products, and marketing campaigns.

SFRA Architecture
SFRA typically includes an "app_storefront_base" cartridge and a server module. These components can be used with overlay plugin cartridges, LINK cartridges, and custom cartridges to create a cartridge stack for layering functionalities. A typical cartridge stack might look like this:

Source: https://developer.salesforce.com/

SFRA employs a variant of the Model-View-Controller (MVC) architecture. In this setup:

  1. Controllers handle user input, create ViewModels, and render pages.
  2. ViewModels request data from B2C Commerce, convert B2C Commerce Script API objects into pure JSON objects, and apply business logic.

The "app_storefront_base" cartridge includes various models that utilize the B2C Commerce Script API to retrieve data necessary for application functionality. These models then construct JSON objects, which are used to render templates.

In SFRA, defining an endpoint relies on the controller's filename and the routes specified within it. The server module registers these routes, mapping URLs to the corresponding code executed when B2C Commerce detects the URL. Additionally, the server module provides objects that contain data from HTTP requests and responses, including session objects.


Cartridge
In B2C Commerce, a "cartridge" serves as a modular package for organizing and deploying code, designed to encapsulate both generic and application-specific business functionalities. A cartridge may include controllers (server-side code where business logic is implemented), templates, scripts, form definitions, static content (such as images, CSS files, and client-side JavaScript files), and WSDL files. Typical base cartridge architecture:

Source: https://developer.salesforce.com/

SFCC Security
One of the key advantages of using platform-built applications is the inherent security provided by the platform. However, it is essential to ensure that configurations enhancing the security of the code are properly applied during implementation. To broadly review the security of a Salesforce Commerce Cloud application, consider the following pointers:


Encryption/Cryptography
In Salesforce, including B2C Commerce, the "dw.crypto" package is commonly used to enable developers to securely encrypt, sign, and generate cryptographically strong tokens and secure random identifiers. It is crucial to review the usage of classes within this package to ensure they meet security standards. For instance, the following classes in "dw.crypto" are considered secure: -

  1. Cipher - Provides access to encryption and decryption services using various algorithms.
  2. Encoding - Manages several common character encodings.
  3. SecureRandom - Offers a cryptographically strong random number generator (RNG).

However, the below classes suggest the use of deprecated ciphers and algorithms, and may introduce vulnerabilities: -

  1. WeakCipher
  2. WeakSignature
  3. WeakMac
  4. WeakMessageDiget

Declarative Security via HTTP Headers 

Certain HTTP headers serve as directives that configure security defenses in browsers. In B2C applications, these headers need to be configured appropriately using specific functions or files. HTTP headers can be set through two methods: -

  1. Using the "addHttpHeader()" method on the Response object.
  2. Using the "httpHeadersConf.json" file to automatically set HTTP response headers for all responses.

To ensure robust security, review the code to confirm the presence of important response headers such as Strict-Transport-Security, X-Frame-Options, and Content-Security-Policy etc.
 

Cross-Site Scripting / HTML Injection
B2C Commerce utilizes Internet Store Markup Language (ISML) templates to generate dynamic storefront pages. These templates consist of standard HTML markup, ISML tags, and script expressions. ISML templates offer two primary methods to print variable values: -

  1. Using "${...}": Replace the ellipsis with the variable you want to display.
  2. Using the "<isprint>" tag: This tag also outputs variable values.

When reviewing .isml files, it is crucial to examine the usage of these tags to identify potential vulnerabilities such as Cross-Site Scripting (XSS) or HTML Injection. These vulnerabilities allow attackers to inject malicious client-side scripts into webpages viewed by users. Example of vulnerable code: -

Script Injection
Server Script Injection (Remote Code Execution) occurs when attacker-injected data or code is executed on the server within a privileged context. This vulnerability typically arises when a script interprets part or all of unsafe or untrusted data input as executable code.
The "eval" method is a common vector for this type of vulnerability, as it executes a string as a script expression. To identify potential risks, review the code for the use of the global method "eval(string)", particularly where the string value is derived from user input.
 

Data Validation
In addition to the aforementioned security checks, it is crucial to validate all user input to prevent vulnerabilities. This can be achieved through functions like "Allowlisting" (whitelisting) and "Blocklisting" (blacklisting). Review these functions to ensure proper input and output validations and to verify how security measures are implemented around them.
 

Cross-Site Request Forgery
Salesforce B2C Commerce offers CSRF protection through the dw.web.CSRFProtection package, which includes the following methods: -

  1. getTokenName(): Returns the expected parameter name (as a string) associated with the CSRF token.
  2. generateToken(): Securely generates a unique token string for the logged-in user for each call.
  3. validateRequest(): Validates the CSRF token in the user's current request, ensuring it was generated for the logged-in user within the last 60 minutes.

Review the code to ensure that these methods are used for all sensitive business functions to protect against CSRF attacks.
 

Storage of Secrets
When building a storefront application, it is crucial to manage sensitive information such as usernames, passwords, API tokens, session identifiers, and encryption keys properly. To prevent leakage of this information, Salesforce B2C Commerce provides several mechanisms for protection: -

  1. Service Credentials: These can be accessed through the "dw.svc.ServiceCredential" object in the B2C Commerce API. Ensure that service credentials are never written to logs or included in any requests.
  2. Private Keys: Accessible through the script API using the "CertificateRef" and "KeyRef" classes. Utilize these classes to manage private keys securely.
  3. Custom Object Attributes: Customize attributes and their properties to use the type "PASSWORD" for storing secrets. This helps ensure that sensitive information is handled securely.

Review the code to verify that all secrets are stored using these methods and are not exposed or mishandled.
 

Authentication & Authorization
To ensure that business functions are carried out with appropriate privileges, developers can utilize certain pre-defined functions in Salesforce B2C Commerce: -

  1. userLoggedIn: This middleware capability checks whether the request is from an authenticated user.
  2. validateLoggedIn: This function verifies that the user is authenticated to invoke a particular function.
  3. validateLoggedInAjax: This function ensures that the user is authenticated for AJAX requests.

Review the code to confirm that these functions are used appropriately for any CRUD operations. Additionally, ensure that the code includes proper session validation checks for user permissions related to each action.
 

Redirection Attacks
In general, redirect locations should be set from the server side to prevent attackers from exploiting user-injected data to redirect users to malicious websites designed to steal information. To validate this, review the code for any instances where user input might be directly or indirectly sent to: -

  1. "<isredirect>" element: Used in ISML templates for redirecting.
  2. "dw.system.Response.redirect" object: Utilized to handle redirects in the script.

 

Supply Chain Security
The platform allows the use of various software sources through uploads, external linking, and static resources. However, this introduces the risk of including unwanted or insecure libraries in the storefront code. For SFRA implementations, ensure that the "addJs" and "addCss" helper methods use the integrity hash as an optional secondary argument to verify the integrity of the resources being added.
 

Secure Logging
Salesforce B2C Commerce logs are securely stored and accessible only to users with developer and administrator access. These logs can be accessed via the web interface or over WebDAV. To ensure the security of sensitive information, review the code to confirm that sensitive data such as keys, secrets, access tokens, and passwords are not logged. This is particularly important when using the "Logger" class. Ensure that sensitive information is not passed to any logging functions ("info", "debug", "warning") within the "Logger" class.
 

Business Logic Issues
Business logic issues can arise from various factors, such as excessive information revealed in responses or decisions based on client-side input. When reviewing SFCC code for logical vulnerabilities, focus on the following areas: -

  1. Reward Points Manipulation: In applications that add reward points based on purchases, ensure that the system validates the order number against the user and enforces that rewards are added only once per order. Rewards should also be deducted if an order is canceled or an item is returned. Failure to do so can allow users to manipulate reward points by passing arbitrary values as the order number.
  2. Price Manipulation: When submitting or confirming an order, verify that the final price of the product is calculated on the server side and not based solely on client-supplied values. This prevents users from purchasing products at lower prices by manipulating request data.
  3. Payment Processing: Since applications often leverage third-party payment gateways, ensure that calls to these gateways are made from the server side. If the client side handles payment processing, users might change order values. Review the logic to confirm that payment validation and processing occur server-side to prevent manipulation.
  4. Account Takeover: For password reset functionality, ensure that reset tokens are not sent in responses, that tokens cannot be reused, and that complex passwords are enforced. Avoid sending usernames from the client side for password resets to reduce the risk of account takeover.

Review the code for validation logic in each business function to uncover any exploitable scenarios resulting from missing or improper validations.
 

In a Nutshell
The above points highlight that, despite the robust security controls provided by the B2C platform, poor coding practices can undermine these protections and introduce security vulnerabilities into the application. It is essential not to rely solely on platform security features but also to conduct a thorough secure code review to identify and address potential issues in the implementation.
 

Useful Links

  • https://developer.salesforce.com/docs/commerce/sfra/guide/b2c-sfra-features-and-comps.html
  • https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-cartridges.html
  • https://osapishchuk.medium.com/how-to-understand-salesforce-commerce-cloud-78d71f1016de
  • https://help.salesforce.com/s/articleView?id=cc.b2c_security_best_practices_for_developers.htm&type=5

Article by Maunik Shah & Krishna Choksi


[Case Study] Fast-Paced Adoption of Gen AI – Balancing Opportunities & Risks

Background
ACME has consistently led the way in adopting new technologies, particularly Generative AI (Gen AI) models, to enhance various business processes, including document summarization, data retrieval, customer support automation, content generation, and web search functionalities. However, the security landscape for Large Language Models (LLMs) presents unique challenges where traditional security approaches/strategies fall short. Recognizing this, ACME engaged Blueinfy to devise a tailored strategy to uncover potential vulnerabilities, such as prompt injection attacks and other contextual risks associated with Gen AI applications, along with traditional vulnerabilities.

Challenge
ACME's existing security program, which includes SAST, DAST, and selected manual penetration testing, was inadequate for testing specific to LLMs. The architecture typically involves a front-end layer with a back-end API connecting to LLMs to perform various tasks. Automated scanners failed to detect even traditional attacks like Remote Code Execution (RCE) and SQL injection (SQLi) because the medium was identified through LLM prompts, which these scanners could not effectively evaluate.

Solution
Blueinfy provided crucial support to ACME by implementing a comprehensive security strategy focused on the following key areas: -

AI Model Interpretation & Architecture Study:
Effective testing begins with a thorough understanding of the underlying architecture and the AI model driving the application. This involves grasping the core algorithms, input data, and expected outcomes. With this detailed knowledge, precise test scenarios were developed.

Full-Scope Penetration Testing:
Blueinfy conducted in-depth, human intelligence-driven, full-scope penetration testing of ACME's Gen AI applications. This assessment identified vulnerabilities, both traditional and specific to LLM implementations, such as prompt injection and other manipulation tactics that could compromise the AI models' integrity. 

Scoring Mechanism for Risk Parameters:
To help implement guardrails and mitigate potential brand impact, Blueinfy developed a comprehensive scoring mechanism to evaluate each Gen AI application across critical parameters, including:

  1. Fairness and Bias: Assessing the AI system for fairness across protected attributes and identifying potential biases.
  2. Abuse and Ethics: Evaluating ethical implications, risks of misuse, and the potential for politically biased or harmful outputs.
  3. Data Privacy: Examining the handling of personally identifiable information (PII) and ensuring data security.
  4. Hallucination and Context: Evaluating the risk of hallucinations and out-of-context outputs that could mislead users.
  5. Toxicity and Insults: Assessing the potential for generating insults, sexually explicit content, profanity, and severe toxicity.
  6. Data Exfiltration: Evaluating the risk of unauthorized data extraction from AI models, ensuring that sensitive information is adequately protected.

Ongoing Risk Assessment:
Following the initial penetration testing, Blueinfy recommended an ongoing risk assessment process for identified LLM vulnerabilities. This approach allows ACME to continuously evaluate the risks associated with data and model upgrades, ensuring that security measures remain effective as the technology evolves. This also helped the ACME team to keep up with the various bypass techniques evolving continually against enhanced security measures being implemented by LLM companies.

Conclusion
The collaboration with Blueinfy resulted in several significant outcomes – especially uncovering vulnerabilities leading to data exfiltration, mass phishing attacks, data stealing etc. Vulnerabilities were effectively risk-rated, promptly addressed, and necessary guardrails were implemented, reducing the risks of data exfiltration and the generation of harmful or biased outputs, thereby minimizing potential brand damage. This partnership equipped ACME with the tools and strategies needed to navigate the complexities of Gen AI security, ensuring that its innovative applications remain secure against emerging threats while continuing to drive business value.

Article by Hemil Shah & Rishita Sarabhai

[Case Study] - Enhancing Security Posture of a Product with Multiple Versions and Deployment Models

Background
ACME Inc., one of the data analytics company, offers a robust product providing flexibility of customization. The product is designed to provide multi-tenant support, ensuring seamless deployment in the cloud environment. To cater to the specific needs of its customers, ACME also offers the product under an on-premise deployment model. The company supports feature customization and custom feature development to meet the unique requirements of its customers.

The customization offered by ACME for their product help them gain a high level of customer retention. However, this flexibility comes with a cost of maintaining multiple versions and builds of the same product. ACME faces significant challenges in maintaining the security posture of its product deployments. A scenario where different customers use different build versions with different features and third-party integrations, makes it difficult to ensure consistent security across the board.

Challenges Presented to Blueinfy

  1. Maintaining Security Posture: Ensuring the security of every version/deployment of the product due to the nature and architecture of the product (to add the problem, there is no real good documentation of the deployed features which is expected for any product company).
  2. Vulnerability Management: Identifying and managing vulnerabilities in the core engine and specific build versions during secure code reviews because different versions have mutually exclusive features and use different third-party libraries.
  3. Customer Impact Identification: Identifying which customers are impacted by specific vulnerabilities and sharing patches/upgrades with them.
  4. Prioritizing Development Efforts: Determining the most vulnerable components and prioritizing the development team's efforts to fix higher-risk areas of the product.

Solution by Blueinfy

ACME Inc. engaged Blueinfy to address these challenges. Blueinfy implemented a comprehensive strategy leveraging their security expertise and advanced tools.

1.  Automated Code Scanning

  • Used a Static Application Security Testing (SAST) tool to scan the code of each version of the product
  • Execute Software Composition Analysis (SCA) to scan third-party dependencies for security vulnerabilities

2.  Result Management and Comparison with Custom Automation Script

  • SAST tools traditionally manage and triage vulnerabilities of individual scans and some provide facilities to compare results of multiple scans
  • In this specific scenario, result comparison and analysis were required to be drilled down to the product’s specific version and source code component level
  • Blueinfy team developed custom scripts to automate the process of running code scans, extracting results, managing version and component-specific scan results, and aggregating scan results to generate pivotal metrics

3.  Unique Vulnerability Extraction and Risk Rating

  • Leveraging their security expertise and programming knowledge, Blueinfy team automated the process to extract unique vulnerabilities
  • Developed a system to risk-rate product versions based on the identified vulnerabilities and their number of occurrences, aiding in setting priorities

4.  Vulnerability Data Analysis

  • Performed data analysis to segregate vulnerabilities based on CVE/CWE, product components, libraries, and severity
  • Integrated the CISA Known Exploited Vulnerabilities (KEV) catalog with the data analysis script to identify product dependencies with known exploited vulnerabilities and prioritize dependency upgrades

5.  Statistical Metrics to Support Decision Making

  • Generated various metrics to showcase the most common vulnerabilities, product components with critical and high severity vulnerabilities, most vulnerable dependencies, clients at risk with product versions having severe vulnerabilities, and more such pivotal matrices
  • Provided visual and data-driven insights to make decision-making easier for the ACME team


Impact and Results
The comprehensive approach adopted by Blueinfy yielded significant results for ACME Inc.:

  1. Risk Rating and Strategic Decisions: The company was able to risk rate their product versions effectively. This risk rating facilitated strategic decisions regarding time and cost investment across different product versions.
  2. Focused Development Efforts: By identifying the most vulnerable components and prioritizing them, the ACME team could allocate development resources more effectively, addressing higher-risk areas promptly.
  3. Enhanced Security Posture: Improved the identification and management of vulnerabilities, enhancing the overall security posture of all product versions.
  4. Improved Customer Impact Management: With a clearer understanding of which customers were impacted by specific vulnerabilities, ACME company was able to share patches and upgrades more efficiently, leading to increased customer trust and satisfaction.


The engagement with Blueinfy enabled ACME Inc. to overcome significant challenges in maintaining the security posture of their product. The automated processes, comprehensive analysis, and strategic insights provided by Blueinfy not only improved security management but also facilitated better decision-making and resource allocation. This case study highlights the importance of working experience with advance tools and expertise in managing security for product environments with multiple versions.

Article by Maunik Shah & Hemil Shah