How can I verify that Security Controls and Exclusions are being triggered as expected?

  • Updated

Objective

How can I verify that Security Controls and Exclusions are being triggered as expected?

Process

There’s 2 types of policy discussed here:

  • Security Controls - Which tell the agent to treat a function within the application as a validator or sanitizer.
  • Exclusions - Which tell the agent to ignore any findings which meet certain criteria.

At present, it is only possible to tell if a Security Control or Exclusion has been triggered from a debug agent log.  These details are not sent up to the server side or visible in the Contrast UI.

 

Security Controls

A Security Control can be identified as being picked up by the agent from the following message in the agent debug log:

2021-05-11 13:30:22,080 [main d] INFO - Applying rule customizations...
2021-05-11 13:30:22,080 [main ContrastPolicy$a] DEBUG - Adding validator: com.acme.ticketbook.Validator.isValid(java.lang.String*)
2021-05-11 13:30:22,081 [main ContrastPolicy$a] DEBUG - Added validator!
2021-05-11 13:30:22,081 [main d] INFO - Done applying rule customizations...

 

Security Controls work by applying a tag to the data that the Contrast agent is tracking to indicate that it has been validated or sanitized. For example, in the following snippet from a debug agent log, we can see that the agent is tracking the string Swordfish and it’s tagged as being from an untrusted source and vulnerable to XSS:

2021-05-11 13:31:18,891 [http-bio-8080-exec-1 d] DEBUG - TRACE O2R PLUG
  CALLEE: char[] java.lang.String.toCharArray()
    CALLER: java.lang.String.toCharArray(String.java:2901)
    …
    OBJ:java.lang.String[Swordfish]*334046645.toCharArray
    LENGTH: 9
     TAGS: Tags:[untrusted(0,9), cross-site(0,9)]

 

Later in the log, we can see our validation tags being added as the data passes through the function we created the Security Control for:

2021-05-11 13:31:18,892 [http-bio-8080-exec-1 AssessmentContext] DEBUG - Adding custom-validated-reflected-xss to existing map for future use under identity 134187417, new set is [custom-validated-reflected-xss, validated, cross-site, compared]
2021-05-11 13:31:18,892 [http-bio-8080-exec-1 AssessmentContext] DEBUG - Applying tags to 1 traces
2021-05-11 13:31:18,892 [http-bio-8080-exec-1 AssessmentContext] DEBUG - Adding custom-validated-reflected-xss to existing identity 134187417 / trace ID 39
2021-05-11 13:31:18,892 [http-bio-8080-exec-1 a] DEBUG - TRACE boolean com.acme.ticketbook.Validator.isValid(java.lang.String)
         null.isValid[C@2dfedfdf => false Tags:[untrusted(0,9), cross-site(0,9), compared(0,9), validated(0,9), custom-validated-reflected-xss(0,9)]

 

Subsequent events, include the custom validation tag which indicates that the agent is now aware that data was validated:

2021-05-11 13:31:18,893 [http-bio-8080-exec-1 d] DEBUG - TRACE P2O PLUG
    CALLEE: void java.lang.StringBuilder.<init>(java.lang.String)
    …
    OBJ:java.lang.StringBuilder[Swordfish]*1105903362.<init>
    LENGTH: 9
     TAGS: Tags:[untrusted(0,9), cross-site(0,9), compared(0,9), validated(0,9), custom-validated-reflected-xss(0,9)]

 

Exclusions

Exclusions are handled differently to Security Controls.  Rather than teaching the agent that a function is handling untrusted data correctly, Exclusions are applied once the agent has detected a finding. Instead of reporting the finding to the Contrast server, if it matches an Exclusion, it will be suppressed and not sent to the server.

 

You can see which Exclusions have been picked up by the agent in the policy json within the debug agent log:

2021-05-12 00:11:36,519 [Contrast Application Updater b] DEBUG - == RECEIVED 200 after submitting APPCREATE-NG
2021-05-12 00:11:36,519 [Contrast Application Updater b] DEBUG - == BODY OF RESPONSE: {
"success" : true,
"messages" : [ "OK" ],
"settings" : {
   …
   "exceptions" : {
     "urlExceptions" : [ ],
     "inputExceptions" : [ {
       "name" : "Ticketbook Name Param",
       "modes" : [ "assess" ],
       "rules" : [ ],
       "assessmentRules" : [ "reflected-xss" ],
       "matchStrategy" : "ONLY",
       "urls" : [ "/ticketbook/.*" ],
       "inputType" : "PARAMETER",
       "inputName" : "name"
     } ],
      "codeExceptions" : [ ]

We can then see our XSS finding being suppressed later in the log:

2021-05-12 00:11:52,771 [http-bio-8080-exec-5 ContrastDataFlowTriggerDispatcherImpl] DEBUG - !LM!TraceFate|LateStageSuppress|ruleId=reflected-xss&suppressor=com.contrastsecurity.agent.plugins.security.AssessSourceExclusionHandler

2021-05-12 00:11:52,771 [http-bio-8080-exec-5 i] DEBUG - !LM!TraceFate|Denylisted|ruleId=reflected-xss

 

See also:

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request