WP- en cPanel-fetches: DNS-resolutie naar privé-IP werd niet gecontroleerd #127
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
jesse-a/OpenCRM#127
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Severity: MEDIUM
Mijn ronde-1+3 SSRF-fixes valideerden alleen de hostname-string (IP-literal/localhost/interne-TLD-check). Een publieke hostname die via DNS naar een privé-IP wijst (
interne-wp.example.com → 10.0.0.5) passeerde alle string-checks. Daarnaast hadsrc/lib/wordpress.tseen eigen zwakkere duplicate vanrejectInternalTargetdie single-label-hosts niet blokkeerde.Ook de TLS-socket-check in
inspectSslCert()opende een verbinding naar de hostname zonder validatie van de geresolvede IP — DNS-rebinding tussen lookup en connect bleef mogelijk.Fix:
resolveAndValidateHost()insrc/lib/url-security.ts: DNS-lookup + IP-range-check tegen privé (10.x, 172.16-31, 192.168, 127.x, 169.254, CGNAT 100.64-127, IPv6 loopback/link-local/ULA).cpanelUapi()(cpanel.ts) vóór elke fetch en incheckSite()(wordpress.ts) vóór de WP-health-fetches.inspectSslCert()bindt de TLS-socket nu op de geresolvede IP metservernameals SNI voor cert-matching — DNS-rebinding-venster gedicht.rejectInternalTargetuit wordpress.ts verwijderd, gebruik nu centrale helper.Files: src/lib/url-security.ts, src/lib/wordpress.ts, src/lib/cpanel.ts
Opgelost in commit
de87b11.