junit.run

[lfatty]

@continuumsecurity, I am testing junit.run for your late fix, but it kept hanging at the following point: junit] Running net.continuumsecurity.jbehave.JUnitStoryRunner

[iriusrisk]

Try editing the build.xml file and in the junit.run target, uncomment the following line:

And change the value of "value" to "-skip" as above. See if that works.
Another thing to try is run junit.zap.run to see if that works.

[lfatty]

junit.zap runs but hanged on the second scenarios of app_scan story. However, junit.run still doing the same thing which is hanging at junit Running net.continuumsecurity.jbehave.JUnitStoryRunner. Although I edited the build.xml file.

[iriusrisk]

Ok, the second scenario of app_scan is the XSS scan. Can you run just that scenario and see if it works?

[lfatty]

Here is the output and as you see I ran only once scenario and it went through but get hang at the end.

[junit] Scenario: The application should not contain SQL injection vulnerabilities [junit] Meta: [junit] @cwe-89 [junit] @id scan_sql_injection [junit] @skip [junit] groovy: (story == 'authentication' || story == 'session_management' || story == 'app_scan' || story == 'authorisation' || story == 'data_security' || story == 'http_headers') && skip == false [junit] Scenario: The application should not contain Cross Site Scripting vulnerabilities [junit] Meta: [junit] @cwe-79 [junit] @id scan_xss [junit] Given a scanner with all policies disabled [junit] And all existing alerts are deleted [junit] And the URL regular expressions listed in the file: [junit] |tables/exclude_urls.table| [junit] are excluded from the scanner [junit] And the Cross-Site-Scripting policy is enabled [junit] And the attack strength is set to High [junit] And the alert threshold is set to Low [junit] 16:03:10,681 INFO [net.continuumsecurity.steps.AppScanningSteps] - Scanning: http://my-vulnerable-app

[iriusrisk]

Looks like it started scanning. Can you startup zap in GUI mode, then run the tests through ZAP and see where it's getting stuck during the scan. The active scan tab in ZAP will show the scanning status.

[lfatty]

jUnit.Run still sucks but junit.zap.run ran fine but did not find the vulnerabilities that are on my vulnerable. Passive scan was able to pick up x-frame options. It used to find all the vulnerabilities on the site but i do not know what happen. May be we are scanning to fast. I will continue to investigate.

[lfatty]

Also Maybe we need to disable the passive scan.

[lfatty]

Testing with junit.zap.run runs fine but junit.run still hangs. Also we need to let people know that they need ant-junit if they wish to run junit.zap.run on redhead or centos.

[iriusrisk]

You can disable the passive scan by commenting out the last two lines of navigate_app.story: And the XML report is written to the file passive.xml Then no Medium or higher risk vulnerabilities should be present

The requirement for ant-junit is mentioned in the getting started guide: http://www.continuumsecurity.net/bdd-getstarted.html

If it's not finding vulns, you can look through the history of zap requests to see what it's testing. Just run 1 scenario where you know there are vulns and check the requests that zap sends in the scanner.

[lfatty]

@continuumsecurity, It seems like both junit.framework.testsuite and net.continuumsecurity.steps.AppScanningSteps are reporting the same thing which may a duplicate. Below is an example of finding about ldap. It is only displayed when using junit report plugin on Jenkins.

net.continuumsecurity.steps.AppScanningSteps.Then no Medium or higher risk vulnerabilities should be present​​​​​​​​​​​​ junit.framework.TestSuite.Scenario: The application should not be vulnerable to LDAP injection

[iriusrisk]

I don't understand. Could we do this over email instead and send me a screenshot of the duplicate finding?

[lfatty]

[iriusrisk]

This is a problem with the JBehave/xUnit integration in that every JBehave step becomes a separate JUnit test.
As a workaround, you can regard the JUnit results purely as an indication that something has failed. Then use the JBehave results themselves to investigate what has failed and why.