CSY203 Week 01 Intermediate

Web security connects directly to earlier foundations:

Secure Software & Web Security

Track your progress through this week's content

Opening Framing: The Web's Trust Problem

Web applications are built on a fundamental architectural challenge: the client cannot be trusted. Browsers, HTTP requests, cookies, form data—all of it can be manipulated by attackers. Yet applications must accept input to function.

This tension between usability and security creates vulnerabilities. SQL injection happens because user input becomes part of database queries. XSS happens because user input becomes part of web pages. The root cause is always the same: trusting untrusted data.

This week establishes the foundation for web application security testing. You'll understand how web applications work at a deep level, learn the security testing methodology, and set up your testing environment.

Key insight: Most web vulnerabilities exist because developers didn't fully understand what attackers could control.

1) Web Application Architecture

Understanding how web apps work is essential for testing them: 

Three-Tier Architecture:

┌─────────────────┐
│  Presentation   │  ← Browser, HTML, CSS, JavaScript
│     (Client)    │     Attacker controls this entirely
└────────┬────────┘
         │ HTTP/HTTPS
         ▼
┌─────────────────┐
│   Application   │  ← Web server, application logic
│    (Server)     │     Processes requests, enforces rules
└────────┬────────┘
         │ SQL, API calls
         ▼
┌─────────────────┐
│      Data       │  ← Databases, file systems
│    (Backend)    │     Stores sensitive information
└─────────────────┘

Client-Side vs Server-Side: 

Client-Side (Browser):
- HTML rendering
- CSS styling
- JavaScript execution
- Cookie storage
- Form validation (easily bypassed!)
- Local storage

⚠️ Everything client-side can be manipulated!

Server-Side (Web Server):
- Request processing
- Authentication/authorization
- Business logic
- Database queries
- Session management
- Input validation (this is where it matters)

Security controls MUST be server-side.

Modern Web Application Components: 

Frontend:
- Single Page Applications (SPA)
- React, Angular, Vue.js
- Mobile apps using same backend

Backend:
- REST APIs
- GraphQL
- Microservices
- Serverless functions

Data Storage:
- Relational databases (MySQL, PostgreSQL)
- NoSQL (MongoDB, Redis)
- Object storage (S3)
- Caching layers

Infrastructure:
- Load balancers
- CDNs
- Web Application Firewalls (WAF)
- API Gateways

Key insight: Modern applications are complex, with many components that can be vulnerable. Testing requires understanding the entire stack.

2) HTTP Protocol Deep Dive

HTTP is the language of web applications: 

HTTP Request Structure:

POST /api/login HTTP/1.1        ← Method, Path, Version
Host: example.com               ← Required header
User-Agent: Mozilla/5.0...      ← Browser identification
Content-Type: application/json  ← Body format
Content-Length: 42              ← Body size
Cookie: session=abc123          ← Session data
Authorization: Bearer xyz       ← Auth credentials

{"username":"admin","password":"secret"}  ← Request body

HTTP Methods: 

GET    - Retrieve data (parameters in URL)
POST   - Submit data (parameters in body)
PUT    - Update/replace resource
PATCH  - Partial update
DELETE - Remove resource
OPTIONS- Check allowed methods (CORS preflight)
HEAD   - GET without body (metadata only)
TRACE  - Echo request (often disabled, XST attacks)

Security implications:
- GET requests logged in URLs, browser history
- POST can still be intercepted
- PUT/DELETE often not protected
- OPTIONS reveals allowed methods

HTTP Response Structure: 

HTTP/1.1 200 OK                        ← Status code
Server: nginx/1.19                     ← Server info (fingerprint!)
Content-Type: text/html; charset=utf-8
Set-Cookie: session=xyz; HttpOnly; Secure
X-Frame-Options: DENY                  ← Security header
Content-Security-Policy: default-src 'self'

<!DOCTYPE html>...                    ← Response body

Important Status Codes: 

200 OK         - Success
201 Created    - Resource created
301/302        - Redirect (follow for open redirect vulns)
400 Bad Request - Client error
401 Unauthorized - Authentication required
403 Forbidden  - Authorization denied (but resource exists!)
404 Not Found  - Resource doesn't exist (or hidden)
405 Method Not Allowed
500 Internal Server Error - Server-side bug (interesting!)
502/503        - Backend issues

Security testing tip:
- 403 vs 404 can reveal resource existence
- 500 errors often leak information
- Different responses = enumeration opportunity

Security Headers: 

Content-Security-Policy (CSP):
- Controls what content can load
- Mitigates XSS

X-Frame-Options:
- Prevents clickjacking
- DENY or SAMEORIGIN

X-Content-Type-Options: nosniff
- Prevents MIME sniffing

Strict-Transport-Security (HSTS):
- Forces HTTPS
- Prevents downgrade attacks

X-XSS-Protection:
- Legacy XSS filter (mostly deprecated)

Referrer-Policy:
- Controls Referer header leakage

Missing headers = potential vulnerabilities!

Key insight: Every part of an HTTP request can be manipulated by an attacker. Every part of a response can leak information.

3) The OWASP Top 10

The industry standard for web application risks: 

OWASP Top 10 (2021):

A01: Broken Access Control (moved up from #5)
     - IDOR, privilege escalation
     - Missing function-level access control
     - 94% of applications tested had some form

A02: Cryptographic Failures (was Sensitive Data Exposure)
     - Weak encryption, missing encryption
     - Exposed credentials, keys

A03: Injection
     - SQL, NoSQL, OS command, LDAP
     - Still prevalent despite being well-known

A04: Insecure Design (NEW)
     - Design flaws, not implementation bugs
     - Threat modeling failures

A05: Security Misconfiguration
     - Default configs, verbose errors
     - Missing hardening, unnecessary features

A06: Vulnerable and Outdated Components
     - Known CVEs in libraries
     - Unmaintained dependencies

A07: Identification and Authentication Failures
     - Weak passwords, credential stuffing
     - Session management issues

A08: Software and Data Integrity Failures (NEW)
     - Insecure deserialization
     - CI/CD pipeline attacks

A09: Security Logging and Monitoring Failures
     - Insufficient logging
     - No alerting on attacks

A10: Server-Side Request Forgery (NEW)
     - SSRF attacks
     - Cloud metadata access

Testing Each Category: 

This course covers testing for all OWASP Top 10:

Week 3-4: A07 (Authentication/Sessions)
Week 5:   A03 (SQL Injection)
Week 6:   A03 (XSS)
Week 7:   A01 (Access Control), A04 (Insecure Design)
Week 8:   A03 (Other Injection)
Week 9:   A08, A10 (Deserialization, SSRF)
Week 10:  A01, A03 (API-specific)
Week 11:  A06 (Components)

A02, A05, A09 covered throughout.

Key insight: The OWASP Top 10 isn't a checklist—it's a prioritized awareness document. Real testing goes deeper.

4) Web Application Security Testing Methodology

A systematic approach to finding vulnerabilities: 

OWASP Testing Guide Methodology:

Phase 1: Information Gathering
├── Passive reconnaissance
├── Application mapping
├── Technology fingerprinting
└── Entry point identification

Phase 2: Configuration Testing
├── Network configuration
├── Platform configuration
├── File extension handling
├── Backup files
└── HTTP methods

Phase 3: Identity Management
├── User registration
├── Account provisioning
├── Account enumeration
└── Password policies

Phase 4: Authentication Testing
├── Credential transport
├── Default credentials
├── Lockout mechanisms
├── Bypass methods
└── Password recovery

Phase 5: Authorization Testing
├── Directory traversal
├── Access control bypass
├── Privilege escalation
└── IDOR

Phase 6: Session Management
├── Session token analysis
├── Cookie attributes
├── Session fixation
├── CSRF

Phase 7: Input Validation
├── XSS
├── SQL injection
├── Other injection
├── File upload
└── HTTP splitting

Phase 8: Error Handling
├── Error codes
├── Stack traces
└── Information leakage

Phase 9: Cryptography
├── Weak SSL/TLS
├── Sensitive data transmission
└── Weak algorithms

Phase 10: Business Logic
├── Workflow bypass
├── Data validation
└── Trust boundaries

Phase 11: Client-Side
├── DOM-based XSS
├── JavaScript analysis
├── HTML5 security
└── Clickjacking

Testing Mindset: 

Think like an attacker:

1. What does this application do?
2. What data does it handle?
3. Who are the users?
4. What could go wrong?

For every feature, ask:
- What input does this accept?
- Where does that input go?
- What happens if I change it?
- What happens if I break it?

For every request, consider:
- Can I change the method?
- Can I modify parameters?
- Can I access other users' data?
- Can I bypass controls?

Key insight: Methodology ensures comprehensive coverage. Without it, you'll miss vulnerabilities.

5) Burp Suite Mastery Setup

Burp Suite is your primary testing tool: 

Burp Suite Configuration:

1. Proxy Setup
   - Proxy → Options → Proxy Listeners
   - Default: 127.0.0.1:8080
   - Install CA certificate in browser

2. Scope Configuration
   - Target → Scope → Add target
   - Filter proxy history to scope
   - Prevents testing out-of-scope sites

3. Project Options
   - Save project for continuity
   - Configure session handling
   - Set up macros for auth

Essential Burp Features: 

Proxy:
- Intercept and modify requests
- History of all traffic
- WebSocket support

Target:
- Site map visualization
- Scope management
- Issue tracking

Intruder:
- Automated attacks
- Parameter fuzzing
- Brute forcing
- Credential stuffing

Repeater:
- Manual request modification
- Rapid testing
- Response comparison

Scanner (Pro):
- Automated vulnerability detection
- Crawling
- Active and passive scanning

Decoder:
- Encode/decode data
- Hash recognition
- Smart decode

Comparer:
- Response diff
- Find subtle changes

Sequencer:
- Token randomness analysis
- Session token quality

Extender:
- BApp Store plugins
- Custom extensions

Essential Extensions: 

Install from BApp Store:

Authentication:
- AuthMatrix - Authorization testing
- Auth Analyzer - Session analysis

Detection:
- Param Miner - Hidden parameter discovery
- Backslash Powered Scanner - Edge cases
- Software Vulnerability Scanner

Productivity:
- Logger++ - Enhanced logging
- Turbo Intruder - Fast fuzzing
- Copy As Python-Requests
- JSON Beautifier
- Hackvertor - Encoding/decoding

Specialized:
- JWT Editor - Token manipulation
- GraphQL Raider - GraphQL testing
- SAML Raider - SAML testing
- Autorize - Access control testing

Key insight: Master your tools. Efficiency in Burp Suite multiplies your testing effectiveness.

Real-World Context: Web App Security Today

The web application threat landscape:

Attack Trends: Web applications remain the primary attack vector. API attacks are increasing rapidly. Client-side attacks (XSS, prototype pollution) are evolving. Supply chain attacks target JavaScript dependencies.

Defense Evolution: WAFs are more sophisticated but bypassable. Content Security Policy adoption is growing but often misconfigured. Modern frameworks have built-in protections that developers sometimes disable.

Bug Bounty Impact: Bug bounty programs have raised the bar. Low-hanging fruit is often found quickly. Valuable findings require deep understanding and creativity.

MITRE ATT&CK Mapping:

  • T1190 - Exploit Public-Facing Application: Web exploitation
  • T1059.007 - JavaScript: Client-side attacks
  • T1071.001 - Web Protocols: C2 via HTTP

Key insight: Web security is an arms race. Attackers and defenders constantly evolve. Staying current is essential.

Guided Lab: Environment Setup

Set up your web application testing environment.

Step 1: Burp Suite Configuration

# Install Burp Suite (Community or Pro)
# Download from: https://portswigger.net/burp

# Configure browser proxy
# Firefox: Settings → Network → Manual proxy
# Set: 127.0.0.1:8080

# Install Burp CA certificate
# Browse to http://burp
# Download CA certificate
# Import in browser certificate store

# Verify: Browse HTTPS site, check Burp history

Step 2: Install Vulnerable Applications

# DVWA (Docker)
docker run -d -p 8081:80 vulnerables/web-dvwa

# OWASP WebGoat (Docker)
docker run -d -p 8082:8080 webgoat/webgoat

# OWASP Juice Shop (Docker)
docker run -d -p 8083:3000 bkimminich/juice-shop

# Access:
# DVWA: http://localhost:8081
# WebGoat: http://localhost:8082/WebGoat
# Juice Shop: http://localhost:8083

Step 3: PortSwigger Web Security Academy

# Create free account
https://portswigger.net/web-security

# This provides:
# - Structured labs for every vulnerability type
# - Apprentice → Practitioner → Expert levels
# - Free, browser-based labs
# - Aligned with this course

Step 4: Explore Burp Features

# Browse a target application through Burp
# Explore:
# 1. Proxy history - see all requests
# 2. Target site map - application structure
# 3. Send request to Repeater - modify and resend
# 4. Decoder - encode/decode values

# Practice intercepting and modifying requests

Reflection (mandatory)

  1. What surprised you about the HTTP requests you intercepted?
  2. What data is transmitted that users might not realize?
  3. How might an attacker abuse the ability to modify requests?
  4. What security headers did you observe (or not observe)?

Week 1 Outcome Check

By the end of this week, you should be able to:

  • Explain web application architecture and trust boundaries
  • Understand HTTP requests and responses in detail
  • Describe the OWASP Top 10 vulnerability categories
  • Apply web application testing methodology
  • Configure and use Burp Suite effectively
  • Set up a web application testing lab

Next week: Information Gathering and Mapping—systematically discovering an application's attack surface.

📚 Building on Prior Knowledge

Web security connects directly to earlier foundations:

  • CSY101 Week 13 (Threat Modeling): Identify attack paths before testing.
  • CSY101 Week 14 (Standards): Align findings to CIS/NIST/ISO controls.
  • CSY104 Week 11 (CVSS): Score and prioritize vulnerabilities.
  • CSY103 (Programming): Read and reason about insecure code paths.

🎯 Hands-On Labs (Free & Essential)

Apply what you learned by setting up and mastering your primary web security testing tool. Complete these labs before moving to reading resources.

🎮 TryHackMe: Burp Suite - The Basics

What you'll do: Learn Burp Suite fundamentals through hands-on practice. Master proxy setup, intercepting requests, repeater, intruder, and decoder tools. Practice modifying requests and analyzing responses.

Why it matters: Burp Suite is the industry-standard web security testing tool used by professionals worldwide. Mastering Burp is essential for all web security testing—every vulnerability you'll exploit requires Burp proficiency.
Time estimate: 2-3 hours

Start TryHackMe Burp Suite Basics →

🎮 TryHackMe: Burp Suite Repeater

What you'll do: Deep dive into Burp Repeater—the most-used Burp tool. Learn to manually test requests, modify parameters, analyze responses, and identify vulnerabilities through systematic testing.

Why it matters: Repeater is where you'll spend 80% of your time in Burp. Mastering Repeater efficiency (keyboard shortcuts, request history, comparison) dramatically improves testing speed.
Time estimate: 1.5-2 hours

Start TryHackMe Burp Repeater →

🧃 OWASP WebGoat: Getting Started

What you'll do: Set up OWASP WebGoat—a deliberately vulnerable application for learning. Complete the introduction lessons and practice basic web attacks in a safe environment.

Why it matters: WebGoat provides a safe, legal environment to practice web attacks. Many future labs will use WebGoat, so setting it up now prepares you for systematic practice.
Time estimate: 1 hour

Start OWASP WebGoat Setup →

💡 Lab Strategy: Master Burp Suite first—it's your primary tool for all future weeks. Start with Basics, then Repeater for efficiency. Set up WebGoat for future practice labs. These tools form the foundation of your web security testing toolkit: 450 total XP, 4-6 hours!

🛡️ Defensive Architecture & Secure Design Patterns

Offensive skills show you how web applications break. Defensive skills show you how to build them correctly from day one.

Secure SDLC Fundamentals

Security is not a final checklist. It is a design discipline that starts at requirements and continues through deployment. 

Secure SDLC loop:
1. Requirements: define security objectives + abuse cases
2. Design: threat model data flows and trust boundaries
3. Build: secure coding standards + peer reviews
4. Test: SAST/DAST + manual verification
5. Release: security gates + monitoring and patching

Threat Modeling Starter (STRIDE)

Map assets, entry points, and trust boundaries, then classify threats using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege).

Real-World Breach: Equifax 2017

The breach began with an unpatched Apache Struts vulnerability. Security failures included weak asset inventory, delayed patching, and missing security gates in the SDLC. Lessons learned: maintain a full application inventory, automate patch validation, and require security checks before release.

Defensive Labs

Lab: Threat Model a Web App with OWASP Threat Dragon

Create a data flow diagram, mark trust boundaries, and list the top five threats with concrete mitigations.

Lab: Write Security Requirements & Abuse Cases

Draft 8-10 security requirements aligned to OWASP ASVS or CIS Controls, plus three abuse cases for critical workflows.

📚 Building on CSY101 Week-13: Use STRIDE and DFDs to formalize threats before coding. CSY101 Week-14: Map requirements to CIS Controls or NIST 800-53.

Reading Resources (Free + Authoritative)

Complete the required resources to build your foundation.

Week 01 Quiz

Test your understanding of Web Application Security Fundamentals.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz

Lab: Application Reconnaissance

Goal: Practice systematic application mapping using Burp Suite.

Part 1: Environment Setup

  1. Configure Burp Suite proxy
  2. Install CA certificate
  3. Deploy at least one vulnerable application
  4. Verify traffic flows through Burp

Part 2: Application Mapping (DVWA)

  1. Browse all pages of DVWA through Burp
  2. Document the site map in Target tab
  3. Identify all forms and input points
  4. Note all cookies and their attributes

Part 3: HTTP Analysis

  1. Capture a login request
  2. Identify all parameters sent
  3. Analyze response headers
  4. Use Decoder on any encoded values

Part 4: Documentation

  1. Create application map/diagram
  2. List all identified entry points
  3. Note potential vulnerability areas
  4. Document security headers present/missing

Deliverable (submit):

  • Application structure diagram
  • Entry point inventory
  • HTTP analysis notes
  • Security header assessment

Checkpoint Questions

  1. Why must security controls be implemented server-side?
  2. What is the difference between a 403 and 404 response?
  3. What does the Content-Security-Policy header do?
  4. What moved from #5 to #1 in the OWASP Top 10 (2021)?
  5. What is the Burp Suite Intruder tool used for?
  6. Why is client-side validation insufficient for security?

Weekly Reflection

Reflection Prompt (200-300 words):

This week you established the foundation for web application security testing. You learned how web apps work, the OWASP Top 10, and set up your testing environment.

Reflect on these questions:

  • "Trust nothing from the client" is the core principle. How does this change how you think about web applications you use daily?
  • The OWASP Top 10 has existed for over 20 years, yet these vulnerabilities persist. Why do you think developers still make these mistakes?
  • What surprised you when intercepting your own web traffic with Burp Suite?
  • How does understanding HTTP at this level change your perspective on web security?

A strong reflection will connect technical concepts to real-world implications for both attackers and developers.

Verified Resources & Videos

This week establishes the foundation for everything that follows. The HTTP protocol understanding and Burp Suite skills you develop now will be used in every subsequent week. Master these fundamentals before moving forward. Next week: systematically mapping applications to find every attack surface.

← Course Overview Next: Week 02 →