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 :
- qualification of the input layer: is it supported or not?
- 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:
- 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)
- presentation layer is not supported :
- the required configuration is described in a separate article: How to define alternate input methods or alternate target methods in case of unsupported presentation or SOA framework
- if this configuration is not done, then any analysis will perform all searches...but will reach no end point - no chance to reach an input method that is not defined.
- if the analysis finds flaws despite the lack of configuration of the main presentation layer, it means the flaws have been found in the secondary presentation layer(s), 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 framework | Comment | Workaround or remediation |
|---|---|---|---|
| #1 | MVC presentation layer | The indirection is managed through annotations or via an XML file. None of them is interpreted for CASTIL generation (as of AIP Core 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 Core 8.3.20. For ASP.NET MVC, support has been implemented in AIP Core 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. |
| #2 | SOA layer | Depending 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. |
| #3 | Usage of annotations for callLinks | The 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.
| Pattern | Out of the box support | AFP onboarding | User 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. 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 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. |
