Page tree
Skip to end of metadata
Go to start of metadata

Summary: Detailed instructions for performing an architecture review for a User Input Security analysis.

Introduction

The architecture review is a critical task, whose objectives are:

  • qualify application for User Input Security analysis
  • adapt User Input Security configuration to application's architecture, in order to ensure reliable analysis results

If you bypass the architecture review, it means you are shooting in the dark, and is an assurance of false results.

The gap analysis is limited to :

  1. qualification of the input layer: is it supported or not?
  2. identification of any SOA internal layer

Other gap analysis (resource access, validation and sanitization libraries) are deferred to the checklist.

Input method qualification / gap analysis

This part is critical as it determines the ability of searches to reach an input method. We have two cases:

  1. presentation layer is supported: use the process lane that is straight to the results (upper branch in the diagram in User Input Security - Detailed onboarding process instructions)
  2. presentation layer is not supported :

Global checks - qualification - boundary review

Check for potential breaks in the flow due to unsupported patterns. These patterns are unsupported MVC presentations and SOA layers.

No.Pattern or frameworkCommentWorkaround or remediation
#1MVC presentation layer

The indirection is managed through annotations or via an XML file. None of them is interpreted for CASTIL generation (as of AIP 8.3.23), this results in an interruption of the flow.

In Java, most MVC frameworks rely on the Servlet API, and hide the calls to the Servlet API, thus no predefined method will be found in CASTIL (these calls are made inside the framework's JAR).

In general with MVC frameworks, the application does not have an explicit call to acquire data. Instead some application methods are called by the framework. They are somehow callback methods. This does not cope with the way dataflow rules work, which requires a caller.

For Struts 2.x, support has been implemented in AIP 8.3.20.

For ASP.NET MVC, support has been implemented in AIP 8.3.20.

For other frameworks (Struts 1.x and JSF), some methods should be defined on-the-fly as input, but this need a small adaptation on a case by case basis. See the two lab extensions: 

Generally speaking, as a remediation to MVC indirection, "start lower", i.e. for Struts, define input methods for getters of Form classes, or getters of Action classes.

#2SOA layerDepending on where the SOA layer resides, this can break the flow.

See below table below for the different types of SOA architecture, and consequence on dataflow analysis configuration.

#3Usage of annotations for callLinksThe same way as presentation framework and IoC/CDI driven by annotations, usage of annotations in other contexts can also affect the search in CASTIL.

None.

You should still onboard the application and find the other flaws that can be found.

Qualification for SOA layer - Web Service

The following table presents (side by side) the configuration actions required for AFP onboarding (or just Transaction identification) and for User Input Security onboarding.

PatternOut of the box supportAFP onboardingUser Input Security onboarding
Web Services consumed

Transaction configuration kit will define it as end point.

For most analyses: not an issue, thus no specific configuration.
For advanced analysis, in WS calls we would consider the sent parameters as potential threats for the consumer.

To achieve that, such WS calls must be defined as a target (take one of the existing flaw searches to do that, as a convention, since there is no specific CWE/flaw search for "Web Service injection").

Web Services exposed

Transaction configuration kit will define it as the start of the transaction.

Exposed REST API or SOAP service increase the surface attack. Tainted data is coming from an "untrusted source", even if you think this is the regular front-end. It could also be an attacker, so it must be defined as tainted input.

For REST services, the standard extensions Spring MVC and JAX-RS do the job automatically: each method decorated by @Requestmapping or @path are considered as input for servicecall virtual stub.

For SOAP services, JAX-WS extension does not yet provide this feature. As a workaround, if you want to configure it, see How to define alternate input methods or alternate target methods in case of unsupported presentation or SOA framework.

Internal SOA layer: the application consumes the services exposed by itself. This is typical of multi-tier architecture.

The chasm (call link from client request to server operation) is filled by the Web Service Linker (WBS). However, each case must studied: WBS will create the callLink only when both the client and server operation frameworks are supported and the URL is resolved.
This is addressed by extensions like JAX-RS, Spring MVC, AWS Java, REST Service Calls for Java or WCF. 

This could be a flow stopper if not addressed appropriately, because usually the presentation layer and the database access layer are two distinct tiers, and the HTTP communication between the two stops the flow, but not the attacks.

Workaround is somewhat tricky: define 2 half-flows, or focus just on the front-end, defining 1 half-flow. See How to define alternate input methods or alternate target methods in case of unsupported presentation or SOA framework.

  • No labels