Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

False Positives for Timestamp Disclosure

See original GitHub issue

Describe the bug Getting false positives for Rule 10096 Timestamp Disclosure with values that could never be timestamps - eg, those beginning/ending in the following:

ending in %, eg .33333333%
ending in em , eg .33333333em
ending in rem, eg .33333333rem
beginning with a ., eg 1.1592500000000001
beginning with other numbers, eg 000000000000000000000000000000001

To Reproduce Steps to reproduce the behavior:

Run an active scan on a website containing the semantic offline stylesheet (sorry don’t have an example site)
See false positives

Expected behavior Scan excludes false positives that are identifiable by regex rules and prefixes/suffixes

Screenshots

Software versions

ZAP: 2.11.1
OS: Windows 10
Java Version: Oracle Corporation 1.8.0_311
Browser: N/A

Would you like to help fix this issue? No experience with Java, but could probably help.

Issue Analytics

State:
Created 2 years ago
Comments:6 (3 by maintainers)

Top GitHub Comments

1reaction

kingthorincommented, Feb 2, 2022

After the updated rule is released please let us know if you see further occurrences. Also remember to check the response(s) for multiple occurrences of the evidence string.

1reaction

kingthorincommented, Feb 1, 2022

I put together a UnitTest for the specific cases you mentioned, the only one that currently makes it through is the first one. Alerts are not raised for the rest.

    @ParameterizedTest
    @ValueSource(strings = {"0.33333333%", "0.33333333em", "0.33333333rem", "1.1592500000000001", "000000000000000000000000000000001"})
    void shouldNotRaiseAlertOnIrrelevantValues(String value) throws Exception {
        // Given
        HttpMessage msg = createMessage(value);
        // When
        scanHttpResponseReceive(msg);
        // Then
        assertEquals(0, alertsRaised.size());
    }

Handling the first case is as simple as changing the regex from \\b[0-9]{8,10}\\b to \\b[0-9]{8,10}\\b(?!%).

Would you be able to provide full responses that you got alerts on? The evidence highlighting in ZAP’s alerts is based on first match (so you might be being mislead).

Top Results From Across the Web

False Positives: Timestamp Disclosure - Unix · Issue #5837

Describe the bug. These are almost always false positives for me. For example, here is my current set of timestamps being reported:.

Highest False Positives Last Month - OWASP ZAP

Position Alert Status Rule Type 1 Loosely Scoped Cookie release Passive 2 Information Disclosure ‑ Suspicious Comments release Passive 3 Cross‑Domain Misconfiguration release Passive

Disable the DAST Unix Timestamp Vulnerability Check - GitLab

The Unix Timestamp Disclosure vulnerability should be disabled by default because it often causes False Positive results.

Managing False Positives in OWASP Zed Attack Proxy (ZAP)

The false positives were supposed to be easy to remove according to their documentation on the Baseline Scan.

ICMP Timestamp Response and Request Vulnerability Fix

The Vulnerabilities in ICMP Timestamp Request is prone to false positive reports by most vulnerability assessment solutions. AVDS is alone in using behavior ......