Ethical Hacker Career in the Fintech Industry

# payment_api_test.py — testing a payment API for common fintech flaws
# Run only against systems you own or have written permission to test.
# Use a staging environment or a bug bounty program with clear scope.

import requests
from urllib.parse import urljoin

BASE = "https://staging-api.example-fintech.com"
TOKEN = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."   # test user's token

def test_idor_payment_status():
    """
    Test 1: IDOR (Insecure Direct Object Reference).
    Can we read another user's payment by changing the ID?
    """
    own_payment_id = "pay_12345"          # belongs to our test user
    other_payment_id = "pay_99999"        # belongs to another test user

    own = requests.get(
        f"{BASE}/api/payments/{own_payment_id}",
        headers={"Authorization": f"Bearer {TOKEN}"},
        timeout=10,
    )
    other = requests.get(
        f"{BASE}/api/payments/{other_payment_id}",
        headers={"Authorization": f"Bearer {TOKEN}"},
        timeout=10,
    )
    print(f"Own payment status: {own.status_code}")
    print(f"Other payment status: {other.status_code}")
    if other.status_code == 200:
        print("FAIL: IDOR — you can read another user's payment")

def test_rate_limit_on_pin_verification():
    """
    Test 2: Brute-force protection.
    Can we submit an unlimited number of wrong PINs?
    """
    for attempt in range(10):
        resp = requests.post(
            f"{BASE}/api/upi/verify-pin",
            headers={"Authorization": f"Bearer {TOKEN}"},
            json={"pin": "0000", "txn_id": "txn_test_001"},
            timeout=10,
        )
        print(f"Attempt {attempt + 1}: {resp.status_code}")

    # If all return 200/400 and no rate-limit (429) appears,
    # the endpoint has no brute-force protection — a serious flaw.

def test_negative_amount_transfer():
    """
    Test 3: Negative amount.
    Can we transfer -₹100 and gain money?
    """
    payload = {
        "from_account": "acc_001",
        "to_account": "acc_002",
        "amount": -100,
        "currency": "INR",
    }
    resp = requests.post(
        f"{BASE}/api/transfers",
        headers={"Authorization": f"Bearer {TOKEN}"},
        json=payload,
        timeout=10,
    )
    print(f"Negative transfer response: {resp.status_code} {resp.text[:100]}")
    if resp.status_code == 200:
        print("FAIL: negative amount accepted — logic flaw")

def test_pii_in_error_messages():
    """
    Test 4: Information disclosure.
    Do error messages leak PAN, account numbers, or stack traces?
    """
    resp = requests.post(
        f"{BASE}/api/transfers",
        headers={"Authorization": f"Bearer {TOKEN}"},
        json={"from_account": "invalid", "to_account": "invalid", "amount": 100},
        timeout=10,
    )
    body = resp.text.lower()
    sensitive_keywords = ["pan", "aadhaar", "cvv", "account_number", "traceback", "stack"]
    leaks = [kw for kw in sensitive_keywords if kw in body]
    if leaks:
        print(f"FAIL: sensitive info leaked in error: {leaks}")

if __name__ == "__main__":
    print("=== Fintech API Security Checks ===")
    test_idor_payment_status()
    test_rate_limit_on_pin_verification()
    test_negative_amount_transfer()
    test_pii_in_error_messages()

# Why this matters in fintech:
# - IDOR and rate-limit flaws are the top causes of fintech breaches.
# - Negative amount transfers have caused real financial losses.
# - PII leaks in errors are a PCI-DSS and RBI compliance issue.
#
# What interviewers look for:
# - You test business logic, not just injection.
# - You understand financial impact of each finding.
# - You know that rate limits and idempotency are security controls.
# - You report cleanly — no data extracted beyond what proves the point.

# android_apk_checks.sh — static security checks on an Android fintech app
# Run on an APK you own or are authorised to test.
# Use MobSF (Mobile Security Framework) alongside this for a full report.

#!/usr/bin/env bash
set -euo pipefail

APK="app-release.apk"
DECOMPILED="./decompiled"

echo "=== Step 1: Basic APK info ==="
apktool d -f "$APK" -o "$DECOMPILED" > /dev/null
echo "Package info:"
grep -m1 "package=" "$DECOMPILED/AndroidManifest.xml"

echo ""
echo "=== Step 2: Check for debuggable flag (should be false in production) ==="
if grep -q 'android:debuggable="true"' "$DECOMPILED/AndroidManifest.xml"; then
  echo "FAIL: debuggable=true — attackers can attach a debugger"
else
  echo "PASS: debuggable is not true"
fi

echo ""
echo "=== Step 3: Check for cleartext traffic (should be false) ==="
if grep -q 'android:usesCleartextTraffic="true"' "$DECOMPILED/AndroidManifest.xml"; then
  echo "FAIL: cleartext traffic allowed — HTTP is possible"
else
  echo "PASS: cleartext traffic not enabled"
fi

echo ""
echo "=== Step 4: Check for exported activities (common fintech flaw) ==="
EXPORTED=$(grep -c 'android:exported="true"' "$DECOMPILED/AndroidManifest.xml" || true)
echo "Exported components: $EXPORTED"
echo "Review each exported component — is it meant to be public?"

echo ""
echo "=== Step 5: Check for hardcoded secrets (simple heuristic) ==="
grep -rniE "(api[_-]?key|secret|password|bearer|token)\s*[:=]\s*[\"'][^\"']{8,}" \
  "$DECOMPILED" 2>/dev/null | head -20 || echo "No obvious hardcoded secrets found."

echo ""
echo "=== Step 6: Check for root detection (should exist in fintech apps) ==="
if grep -rniE "(RootBeer|isRooted|superuser|magisk)" "$DECOMPILED" 2>/dev/null | head -3; then
  echo "PASS: root detection likely implemented"
else
  echo "WARN: no root detection found — app may run on rooted devices"
fi

echo ""
echo "=== Step 7: Check certificate pinning ==="
if grep -rniE "(CertificatePinner|certificatePinning|sha256/)" "$DECOMPILED" 2>/dev/null | head -3; then
  echo "PASS: certificate pinning likely implemented"
else
  echo "WARN: no certificate pinning found — MITM may be possible"
fi

echo ""
echo "=== Step 8: Run MobSF for full report ==="
# Run MobSF locally or via Docker
# docker run -p 8000:8000 opensecurity/mobile-security-framework-mobsf
echo "Upload the APK to MobSF for a full report with CVSS scores."

# Why this matters in fintech:
# - Android apps are the primary user-facing surface for most fintechs.
# - Debggable, cleartext, exported components, and missing pinning
#   are the top reasons fintech apps fail compliance audits.
# - Root detection and certificate pinning are expected in any
#   app that handles money — their absence is a finding.
#
# What interviewers look for:
# - You test the app the way an attacker would, not just a tool.
# - You know that static checks catch 60% of common issues.
# - You report each finding with impact and remediation.
# - You respect authorisation — every test is on your own APK or
#   a bug bounty program with clear scope.

-- fraud_detection.sql — a real query a fintech fraud analyst writes
-- This is what "security analytics" looks like day to day.

WITH
-- 1. Flag suspicious transaction patterns
suspicious AS (
  SELECT
    txn_id,
    user_id,
    amount,
    txn_at,
    channel,                -- 'UPI', 'card', 'netbanking'
    device_id,
    ip_country,
    -- Flag rapid successive attempts
    LAG(txn_at) OVER (PARTITION BY user_id ORDER BY txn_at) AS prev_txn_at,
    LAG(amount) OVER (PARTITION BY user_id ORDER BY txn_at) AS prev_amount
  FROM transactions
  WHERE txn_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
),

-- 2. Score each transaction for fraud risk
scored AS (
  SELECT
    *,
    -- Rule 1: multiple failed PIN attempts within 15 minutes
    CASE
      WHEN channel = 'UPI'
       AND prev_txn_at IS NOT NULL
       AND TIMESTAMP_DIFF(txn_at, prev_txn_at, MINUTE) <= 15
      THEN 30 ELSE 0
    END
    +
    -- Rule 2: amount significantly higher than the user's previous
    CASE
      WHEN prev_amount IS NOT NULL
       AND amount > prev_amount * 5
       AND amount > 5000
      THEN 25 ELSE 0
    END
    +
    -- Rule 3: logins from high-risk countries
    CASE
      WHEN ip_country IN ('XX', 'YY', 'ZZ')  -- maintain a risk list
      THEN 40 ELSE 0
    END
    +
    -- Rule 4: new device within 24 hours of a large transfer
    CASE
      WHEN device_id IS NULL THEN 15 ELSE 0
    END
    AS fraud_score
  FROM suspicious
)

-- 3. Surface high-risk transactions for review
SELECT
  txn_id,
  user_id,
  amount,
  txn_at,
  channel,
  device_id,
  ip_country,
  fraud_score,
  CASE
    WHEN fraud_score >= 60 THEN 'block_and_review'
    WHEN fraud_score >= 30 THEN 'step_up_auth'
    ELSE 'allow'
  END AS action
FROM scored
WHERE fraud_score >= 30
ORDER BY fraud_score DESC, txn_at DESC
LIMIT 100;

-- Why this matters in fintech:
# - Most fraud is caught by rules, not by ML models.
# - A rules-based fraud analyst saves companies millions.
# - This is a real SQL pattern for fraud detection.
#
# What interviewers look for:
# - You understand the difference between a detection rule
#   and a false positive.
# - You know that rule tuning is a continuous process.
# - You think in terms of business impact, not just the query.
# - You respect PCI-DSS and RBI data handling while writing
#   these queries.
#
# Entry roles in fintech security often use these skills
# directly — SOC analysts, fraud analysts, and risk engineers
# all write queries like this daily.