User Input Security - Advanced configuration and usage instructions on Documentation - V2

User Input Security - Advanced configuration to improve performance

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Enabling User Input Security checks will impact overall analysis performance - i.e. the analysis of a given Application will take longer to complete if you enable User Input Security checks. This is due to the additional checks and metrics that need to be processed during this type of analysis. However, the impact on performance will vary according to various different aspects related to the Applications you are analyzing:

Number of lines of code (LOC)
Number of objects after analysis
Number of violations after analysis

In other words, the impact will be less noticeable on small/simple Applications, whereas the impact will be more significant for larger/complex Applications. If you need to use the User Input Security with a large or complex Application and you need to try and limit the performance hit that this will have, then there are some advanced configuration settings that can be set to do this. This page explains these settings.

User Input Security - Detailed onboarding process instructions

Mon, 01 Jan 0001 00:00:00 +0000

Info

Summary: Detailed instructions for onboarding an Application specifically to run User Input Security checks

Introduction

Previous versions of the Dataflow onboarding process used to put the focus on tooling (linq, Excel) for blackbox definitions production. Since AIP Core 8.3.3, the process has been simplified thanks to:

pass-through mode: since 8.3.0, when the engine encounters an unknown external method, it is considered as a collection (continue the flow), instead of stopping the current search.
automatic blackboxing: since 8.3.3, the DataflowRunner engine will decide “on-the-fly” the method’s semantic, based on internal rules (signatures and advanced patterns). This does complement with a few (10 to couple of dozens definition) the predefined methods.

However, in case of unsupported presentation layer or SOA layer, the flow is stopped and cannot reach the input layer, and thus the definition of alternate input methods is still required. As a consequence, the process is “lighter”, and has two main branches, depending on the presentation layer in the source code:

User Input Security - Architecture review

Mon, 01 Jan 0001 00:00:00 +0000

Info

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

Warning

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

User Input Security - Checklist for User Input Security analysis

Mon, 01 Jan 0001 00:00:00 +0000

This checklist answers the following questions:

When is the User Input Security analysis configuration finished?
As an AIA, when can I hand over to the FO or customer?
What should I document as part of the implementation process?
As a reviewer, what is the proof that demonstrates the User Input Security configuration has been performed correctly?

Info

Ensure you duplicate this page, and fill in the last column with the result of the check for each checked item. Upon completion, the AIA can assess whether they executed the process from end to end, and ensure the analysis results are in line with the analyzer’s current capacity.

User Input Security - How to read the SecurityAnalyzer log in one go

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

The SecurityAnalyzer log reports the inner behavior of the User Input Security analysis. It must be read by the AIA in order to figure out what happened on several topics listed in the table below.

Main steps and checks to perform

The table below lists the main phases of the User Input Security analysis. Each phase is reported in the SecurityAnalyzer.log, through a number of log records. The success of each step must be controlled, in order to ensure correct execution. Some types of error do not stop the User Input Security analysis, so a proper examination must take place. Global numbers (number of entrypoints for each flaw, total number of flaws found, etc.) must the controlled too (see the checklist for this control).

User Input Security - When do you need to create blackbox

Mon, 01 Jan 0001 00:00:00 +0000

Blackbox definition

Blackbox is the means by which an AIA can drive the User Inout Security engine, giving semantics to methods. The four main actions you can give a method are the following:

Action	Meaning	Comment
input	data acquisition, from the user input in a form or page. Exposed REST API, message queues and other middlewares are also considered as insecure data acquisition.	Sample for JEE : serveltRequest.getParameter() Sample for .NET : winForm.control.getText() For full list of methods, see Predefined methods. User Input Security - Sanitization and co - how to protect from injection flaws and how to define them in AIP Mon, 01 Jan 0001 00:00:00 +0000 Introduction Objectives To protect against injection vulnerabilities, the software developer has several means at his disposal. In order to get accurate analysis results, the AIA needs to discover if any of these mechanisms have been used in the application, and how to configure AIP Core to take them into account, when required. Collect usage of protection mecanism(s) used by ACME organization, in an interview. usage of presentation layer validator, standard or custom the names of the sanitization vetted libraries, standard or custom for SQL injection prevention, usage of parameter binding, akaSQL Bind Variables/Parameters If the collection of information is not possible or incomplete upfront, the AIA must use his knowledge to detect the presence of the mechanism(s) in the source code itself and/or in the SecurityAnalyzer.log. Presence of JAR or assemblies could be a first sign Dependency inside Maven pom.xml is a better sign Presence of a protection mechanism is not a proof the application is 100% covered. Methodology presentation The default configuration will cover 90% of the cases for public sanitization library (with AIP Core >= 8.3.15). Then, once flaws are found and validation or any interview / observation reveals some specific configuration should be done, add a custom blackbox file to define the specific methods as sanitization (mode=clear). Then the invalid violations (protected by a sanitization method) will be removed from list of violations, and the remaining violations are deemed true positives.

Action

Meaning

Comment

input

data acquisition, from the user input in a form or page.

Exposed REST API, message queues and other middlewares are also considered as insecure data acquisition.

Sample for JEE : serveltRequest.getParameter()
Sample for .NET : winForm.control.getText()

For full list of methods, see Predefined methods.

User Input Security - Sanitization and co - how to protect from injection flaws and how to define them in AIP

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Objectives

To protect against injection vulnerabilities, the software developer has several means at his disposal. In order to get accurate analysis results, the AIA needs to discover if any of these mechanisms have been used in the application, and how to configure AIP Core to take them into account, when required.

Collect usage of protection mecanism(s) used by ACME organization, in an interview.
1. usage of presentation layer validator, standard or custom
2. the names of the sanitization vetted libraries, standard or custom
3. for SQL injection prevention, usage of parameter binding, akaSQL Bind Variables/Parameters
If the collection of information is not possible or incomplete upfront, the AIA must use his knowledge to detect the presence of the mechanism(s) in the source code itself and/or in the SecurityAnalyzer.log.
1. Presence of JAR or assemblies could be a first sign
2. Dependency inside Maven pom.xml is a better sign
3. Presence of a protection mechanism is not a proof the application is 100% covered.

Methodology presentation

The default configuration will cover 90% of the cases for public sanitization library (with AIP Core >= 8.3.15). Then, once flaws are found and validation or any interview / observation reveals some specific configuration should be done, add a custom blackbox file to define the specific methods as sanitization (mode=clear). Then the invalid violations (protected by a sanitization method) will be removed from list of violations, and the remaining violations are deemed true positives.