feat: WordPress-native tripwires (#13)#29
Merged
Merged
Conversation
Traps targeting WP-specific recon that node's framework-agnostic SDK can't express. - WebDecoy_WP_Traps: fake vulnerable-plugin path prefixes for well-known scanner-targeted slugs (wp-file-manager, revslider, ...), armed as tripwire prefixes ONLY when that plugin is not installed here (guarded by is_dir on WP_PLUGIN_DIR) so a real plugin's routes are never shadowed. - Optional xmlrpc.php path trap (off by default — legit clients use XML-RPC). - Author enumeration: ?author=N (unauth) and the REST /wp/v2/users endpoint return a canary username instead of leaking the real one; the probe is recorded. A later login with that canary is caught by the #12 canary-credential detection — closing the enumeration→credential-stuffing loop. Authenticated requests are untouched. - Path traps flow through the engine (DENY + violation + clearance + optional decoy); query/REST traps record a synthetic tripwire violation (local log + clearance-carrying report). New WordPress Traps settings section. Verified plugin-prefix guarding (absent armed, installed skipped), REST canary serving + recording, the served canary is a recognized canary credential, and authenticated/non-users requests are untouched. Closes #13. Part of #16. Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Traps that require knowing WordPress internals — the recon every wpscan-style tool runs — which
@webdecoy/node's framework-agnostic core can't express. This is differentiated, WP-owned deception.Traps
wp-file-manager,revslider,duplicator, …) armed as tripwire prefixes, only when that plugin is not actually installed here (guarded byis_dir()onWP_PLUGIN_DIR), so a genuinely installed plugin's routes are never shadowed. On by default.xmlrpc.phptrap, off by default because legitimate clients (Jetpack, the WordPress mobile app, some pingbacks) use it.?author=N(unauthenticated) and the REST/wp/v2/usersendpoint return a canary username instead of leaking a real one, and record the probe. Because that canary is a recognized canary credential, a later login attempt with it is flagged CRITICAL by the Deceptive tripwire responses — fake content, canary credentials, tarpit #12 detection — closing the enumeration → credential-stuffing loop. Authenticated requests (block editor, etc.) are untouched.Wiring
Path traps flow through the rule engine, so they inherit the full DENY + violation +
wd_clearanceforwarding + optional decoy-response treatment. The query/REST traps hook WP directly and record a synthetic tripwire violation (local detection + clearance-carrying cloud report), so they feed enforcement identically. New WordPress Traps settings section.Tests
Verified plugin-prefix guarding (absent slugs armed, an installed slug skipped), REST users canary serving + probe recording, that the served author canary is recognized as a canary credential (loop closure), and that authenticated / non-users requests pass through untouched (10 checks). SDK suite still green (41).
Closes #13. Part of #16.