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. |
For full list of methods, see Predefined methods. + embedded rules in on-the-fly blackboxing engine (part of DataflowRunner) : definition not documented. |
| collection | continue the flow | Most getters, setters, and any method not in the 3 other categories. Different flavors of collection exist: add, set, get (with combination of alternative and assign on sink and source), however, current implementation does not take the different flavors into account (when using the Excel template to generate the .blackbox.xml file). |
| target | access a resource (database, network, file name, log record, ...). | Sample: executeSQL(param1, ...), writeLogRecord(param1, ...), OpenFilename(param1, ...) This is the start of the graph search: it starts from resource access up to user input (tainted input), that is the opposite way compared to runtime data flow. |
| sanitization | neutralize the special characters, thus stop the flow. | Sample method names: escapeForSQL, escapeForJson, escapeForHTML, encodeForSQL, setParameter, setString,... See Sanitization and Co - how to protect from injection flaws and how to define them in AIP. |
Dataflow configuration tools
With CASTIL, there are no Reference Patterns, Update CAST KB, SDKs, create_link, or similar enrichment tools: they are available for the Analysis Service (local schema) only. With CASTIL, there is no real means to enrich or "repair" the content of a default analysis. In case of a broken flow, that is an interrupted flow due to an SOA layer or incorrect CASTIL generation, (think of a missing link in a transaction), you cannot fill this gap (the way you would add the missing link). The remediation is to define two half-flows, thanks to blackboxes.
To start a flow, define a target. To finish a flow, define an input.
Any un-interrupted flow from a target up to an input would be reported as a violation: this is an injection from the input, down to the target (the tainted input flows that way at runtime).
Potentially, there are 2 means to configure the dataflow engine:
- white box (write you own Java or .Net code, to generate additional CASTIL). Objective: link 2 methods.
- blackbox: to give semantics to a method, both to external methods not yet defined, or to override generated CASTIL.
When do you need to define blackboxes - different types of blackboxes
Across versions of AIP Core, the requirements and the type of blackbox evolved:
| type of blackbox | 7.2-7.3 | 8.0-8.2 | 8.3.0-8.3.2 | 8.3.3+ |
|---|---|---|---|---|
blackbox external methods 'No implementation found for XYZ' or since 8.3.13 'Method without neither implementation nor definition' : neither a source file .java or .cs or .vb has been found, nor any predefined method. Engine doesn't know what to do, and assumes method is a collection, unless it matches a on-the-fly rule. | process #1 from .log.secondary iterative (8-12 iterations) | process #2 using the API one go | automatic: pass-through mode any undefined method is assumed a collection = continue the flow | automatic: on-the-fly blackboxing
|
| consequence of failure to configure external methods | graph exploration stopped : by design (to avoid false positives) the engine stops as soon as an external method is encountered, and issue a message in log secondary 'No implementation found for XYZ' . This behavior pave the road for false-, since external methods calls are very frequent. → false negatives | graph exploration stopped → false negatives | for 5% of the methods that are not collection: collection instead of target : false negative collection instead of sanitization: false positive collection instead of input: false negative | if decision is correct : all good if decision is not correct : see cell to the left (8.3.0-8.3.2 behavior) |
defining input methods for synchronous read (JMS, MQ, MSMQ, ...) | input not defined : false negative | input not defined : false negative | input not defined : false negative | input not defined : false negative |
defining alternate input methods for MVC presentation frameworks Typically : define the getters of Struts ActionForm as input. | required for all MVC frameworks and REST API | required for all MVC frameworks and REST API | required for all MVC frameworks and REST API | required for all MVC frameworks except: a) Spring MVC: com.castsoftware.springmvc.1.5.0 generates automatically the needed to define input methods for each @RequestMapping b) JAX-RS: com.castsoftware.jaxrs/1.4.5 generates automatically the needed to define input methods for each @Path |
| consequence of failure to configure alternate input methods in case of MVC presentation frameworks | no input method scope of QRs = 0 (or limited to called predefined input methods) → QR grayed in CED | no input method scope of QRs = 0 (or limited to called predefined input methods) → QR grayed in CED → QR absent in AED | no input method scope of QRs = 0 (or limited to called predefined input methods) → QR grayed in CED → QR absent in AED | no input method scope of QRs = 0 (or limited to called predefined input methods) → QR grayed in CED → QR absent in ED |
