False positive for: HackenProof

[sudo-nano]

Additional info

Searching goslnt reliably produces a false positive for HackenProof, and unreliably produced false positives for ArtStation (redirected to 404) and AskFM.

Code of Conduct

• I agree to follow this project's Code of Conduct

[ppfeister]

When you say unreliably...

Does it work at first, and then it suddenly stops for a while, before resetting? Or is it sporadic and unpredictable?

Wondering if it's rate limit related. If so, normally an easy fix.

[aytvill]

I just run check of my nickname, and it also makes reproducible false positive for Hackenproof

On first run of URL with presumably my profile, it bumped into robot-protection from CloudFlare. Once passed, it gave redirect to URL https://hackenproof.com/error and large 404 letters in the middle. All consecutive attempts to access URL ascribed as my profile led to same error page.

Running curl to same URL leads to 403 code, presumably Cloudflare protection: curl -I https://hackenproof.com/hackers/aytvill

$ curl -I https://hackenproof.com/hackers/aytvill
HTTP/2 403
date: Thu, 21 Nov 2024 11:08:05 GMT
content-type: text/html; charset=UTF-8
content-length: 8189
accept-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
critical-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
cross-origin-embedder-policy: require-corp
cross-origin-opener-policy: same-origin
cross-origin-resource-policy: same-origin
origin-agent-cluster: ?1
permissions-policy: accelerometer=(),autoplay=(),browsing-topics=(),camera=(),clipboard-read=(),clipboard-write=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()
referrer-policy: same-origin
x-content-options: nosniff
x-frame-options: SAMEORIGIN
cf-mitigated: challenge
cf-chl-out: Sv2+vtocz0SlhLjA5i6Lnor9wJz3IWWAUzBu7gfJzanfxHRiAu0xablsw6aXnfYo1eY9xc0hEhUQ3Yk0aHbjqfGaUTl470Yq4tiSYGVZO7hqe+eP53BfN5wQ6YJacUjDOH3RmG2L5+CJ4sE/9UIA2A==$V8332+2cuRDBzA/tKECAww==
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=GOt81Ha8gCJxv9xmn1Y7WwES2MYsbsuPRPd9wlOyRAULbLaGtVU6F2kbnHDIETnGoN%2FBt1aCUAkE%2FIZvl%2FUWw11PrrV7AMo%2Fr7yAEFUZ%2FGkdy4AvyPBSfkcevV7eiSHvSw%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 8e6038452c1b8da5-HEL
server-timing: cfL4;desc="?proto=TCP&rtt=15985&sent=5&recv=7&lost=0&retrans=0&sent_bytes=3398&recv_bytes=807&delivery_rate=180537&cwnd=245&unsent_bytes=0&cid=9e130cd7ef02879f&ts=33&x=0"

[sudo-nano]

When I initially filed the issue, HackenProof gave a false positive the first time and then gave correct negatives after that. Now that I've gone back to reproduce the issue again, it's reproducibly producing false positives. Passing --dump-response reveals that it's getting an HTTP 403, likely due to Cloudflare protection as aytvill said above.