Implement OnValidateTarget callback for target validation hooking

[MarkOtzen]

Adds a callback function at OnValidateTarget, letting users register a func(hostname, IP, port string) error to be run before dialing. Errors returned behave as invalid targets (still triggering that callback).

Main purpose is being able to limit the port in the dialer. I guess that ties into #226. I would have preferred using the already implemented networkpolicy for that, but since only the IP is validated that way (and changing it to ValidateAddressWithPort would be a breaking change I imagine based on test cases) I figured a validation callback was a reasonable path forwards.

[neo-by-projectdiscovery-dev]

Neo - PR Security Review

No security issues found

Highlights

• OnValidateTarget callback properly integrates into security flow after networkpolicy.Validate(ip) and validatePort checks
• Callback error handling correctly rejects invalid targets without information disclosure
• No bypass opportunities or injection vectors present in the implementation

Hardening Notes

• The port parameter passed to OnValidateTarget is a string - document that callback implementers should validate it's numeric and within valid range (1-65535)
• Consider documenting that OnValidateTarget errors should not expose sensitive information as they may be logged by calling code
• Add usage examples in documentation showing secure port blocking patterns to guide users toward proper validation

_{Comment @pdneo help for available commands. · Open in Neo}

[Mzack9999]

While investigating this PR, we found that networkpolicy.ValidatePort has a bug that causes all ports to be rejected when only DenyPortList is configured (see #534).

The existing AllowPortList and DenyPortList options in fastdialer were never enforced at the dial level — only IP validation was being performed via Validate(ip). Rather than adding a callback as a workaround for port blocking, the proper fix is to enforce port policy natively using the existing options.

We've implemented this with a validatePort method directly on the Dialer (bypassing the buggy networkpolicy.ValidatePort), and kept the OnValidateTarget callback as a generic extension point for custom validation logic beyond what network policy covers.

[MarkOtzen]

The existing AllowPortList and DenyPortList options in fastdialer were never enforced at the dial level — only IP validation was being performed via Validate(ip). Rather than adding a callback as a workaround for port blocking, the proper fix is to enforce port policy natively using the existing options.

Absolutely the preferable solution. I tried switching the Validate(ip) to ValidateAddressWithPort(ip, port) but the test suite blew up - I didn't consider that networkpolicy.ValidatePort itself was bugged. I assumed that users were expecting fastdialer to not enforce port restrictions - which would have made this a much more breaking change than I'm comfortable with given my sparse understanding of the ecosystem.

We've implemented this with a validatePort method directly on the Dialer (bypassing the buggy networkpolicy.ValidatePort), and kept the OnValidateTarget callback as a generic extension point for custom validation logic beyond what network policy covers.

Are you intending to release this as a tagged version, and if so, do you have a rough estimate on when it might be tagged?