OUTOFSCOPE doesn't seem to be working

[pgregory118]

Describe the bug
I'm running a fairly standard github action with ZAP baseline
I've got 2 OUTOFSCOPE lines to exclude an error:
10202 OUTOFSCOPE https://master.internal.juriba.com/LoginSplash.aspx?ReturnUrl=%2Fdefault.aspx&sir=1
10202 OUTOFSCOPE https://master.internal.juriba.com/default.aspx

It looks like it's worked in the logs from gitactions:
PASS: Reverse Tabnabbing [10108]
PASS: Modern Web Application [10109]
PASS: Absence of Anti-CSRF Tokens [10202] ⬅️
PASS: Private IP Disclosure [2]
PASS: Session ID in URL Rewrite [3]
PASS: Script Passive Scan Rules [50001]
PASS: Insecure JSF ViewState [90001]

However in the issues report this comes up as an error
Absence of Anti-CSRF Tokens [10202] total: 2:
https://master.internal.juriba.com/LoginSplash.aspx?ReturnUrl=%2Fdefault.aspx&sir=1
https://master.internal.juriba.com/default.aspx

I can use IGNORE to get rid of this error but obviously that is not as good.

Strange that at one point it seemed to work:
Resolved Alerts

Absence of Anti-CSRF Tokens [10202] total: 2:

But now sadly not

To Reproduce
Steps to reproduce the behavior:
Run a zap baseline scan:

zap_scan: runs-on: self-hosted name: Zap Scan steps: - name: Checkout uses: actions/checkout@v2 with: ref: master - name: OWASP ZAP Baseline Scan uses: zaproxy/action-baseline@v0.4.0 with: target: ‘https://example.com’ rules_file_name: ‘.github/workflows/zap/rules.tsv’

Expected behavior
The Absence of Anti-CSRF Tokens is excluded from the results

Screenshots
If applicable, add screenshots to help explain your problem.

Software versions

• ZAP: Latest version downloaded through docker run
• OS: docker

Errors from the zap.log file
n/a

Would you like to help fix this issue?
May be a user error as I'm new to this way of running zap

[kingthorin]

Specific to this one, please provide a valid target: "target: 1httpa:----------.com' "

---

Please don't ask questions as issues - the ZAP User Group is a much better place for questions.

If you’re asking about a third party components such as the Jenkins plugin or VSTS plugin please look for their preferred support mechanism as these were not created by and are not supported by the core team.

[pgregory118]

Thanks for nothing

[kingthorin]

@pgregory118 I've moved the ticket to the appropriate repo. There isn't enough detail in your report to identify an issue aside from the fact that your target appears invalid (yes I understand it isn't full of hyphens but the leading "1" and trailing "a" didn't bode well). Further we have no idea what may have changed between runs or within the environment/code base.

If you can pin point an issue let us know, otherwise it seems like a question to be handled via the User Group.

[thc202]

Actually, the OUTOFSCOPE case is not being handled (yet), just IGNORE. This also applies to the full scan.

[erzz]

Would be nice for this to be included - any ideas of timeline?

[acodeninja]

This issue looks to be related to the mainline @zaproxy/actions-common-scans repo.

https://github.com/zaproxy/action-baseline/blob/master/index.js#L47 < only adds -c ${rulesFileLocation} if the plugins variable has a length greater than 0.

the plugins variable is set here https://github.com/zaproxy/action-baseline/blob/master/index.js#L40

the processLineByLine method here https://github.com/zaproxy/actions-common/blob/master/packages/scans/src/action-helper.js#L38 only adds to the return value if you have at least one IGNORE directive in your config file.

I'm not sure that the call to common.helper.processLineByLine is really needed here, and I found it strange that this logic was in place. If the file is invalid for whatever reason I'd expect the zap-baseline.py program to return a non-zero exit code.

As a temporary workaround I've added this line to our own repos baseline config:

# We ignore a non-existent rule here as the github action won't pass this file without it
# See https://github.com/zaproxy/action-baseline/issues/44
-1	IGNORE	(Fix for https://github.com/zaproxy/action-baseline/issues/44)

[dennis-hh]

This issue unfortunately still exists. Also used @acodeninja's workaround.