Skip to main content
Critical Safety Notice: The Normo Unsecure PWA contains intentional security vulnerabilities and should NEVER be run outside a properly isolated sandbox environment. Following these best practices is essential to protect your systems, data, and network.

​
Core Safety Principles

​
Never Run in Production

Prohibited Environments

  • Production servers
  • Corporate networks
  • Shared hosting platforms
  • Cloud services with production data
  • Systems with sensitive information

Approved Environments

  • Isolated VMs or containers
  • Dedicated testing hardware
  • Secure architecture sandboxes
  • Properly configured cloud development environments
  • Air-gapped systems

​
Network Isolation

Ensure your sandbox environment is properly isolated from production networks:
1

Verify Network Configuration

  • Use NAT or Host-only networking in VMs
  • Never use Bridged mode with vulnerable applications
  • Configure Docker with --internal networks when appropriate
  • Disable external network access if not needed for testing
2

Test Isolation

# From within sandbox, verify you cannot reach production
ping production-server.local  # Should fail
curl https://internal-api.company.com  # Should fail
3

Monitor Network Traffic

Use tools like Wireshark to monitor and verify network isolation during testing.
If testing network-related vulnerabilities, ensure you have a dedicated testing network that is completely isolated from production infrastructure.

​
Data Management

​
Never Use Real Data

Golden Rule: Only use synthetic or anonymized test data in sandbox environments. Never import production databases, user information, or sensitive files.

​
Safe Test Data Guidelines

Use:
  • Fictional names and addresses
  • Test email addresses (e.g., [email protected])
  • Synthetic phone numbers
  • Dummy credit card numbers (test card numbers from payment processor docs)
Never Use:
  • Real user credentials
  • Actual email addresses
  • Personal information from databases
  • Production API keys or tokens
Create test databases with:
  • Generated lorem ipsum text
  • Faker libraries for realistic but fake data
  • Small datasets (< 1000 records for most tests)
  • Clear identifiers that data is for testing
Never:
  • Copy production databases
  • Use backups containing real data
  • Import user-generated content from production
Use:
  • Temporary test credentials
  • Sandbox-only API keys
  • Development-specific tokens
  • Well-known test passwords (document them clearly)
Never:
  • Reuse production credentials
  • Test with your personal passwords
  • Store real API keys in test code
  • Commit secrets to version control

​
Data Cleanup

1

Document All Test Data

Maintain a list of all test accounts, databases, and credentials created during testing.
2

Regular Cleanup

Periodically purge test data and reset the sandbox to a clean state.
3

Secure Disposal

When decommissioning a sandbox, ensure all data is securely deleted, especially if using cloud services.

​
Security Testing Best Practices

Legal Notice: Students MUST be extremely aware of the legal implications of performing unauthorized penetration testing. Students MUST only perform penetration tests on:
  • Their own applications
  • Peers’ applications with expressed permission
  • Applications explicitly designated for security testing
Unauthorized penetration testing is illegal and can result in criminal charges.

​
Testing Scope and Boundaries

1

Define Testing Scope

Before beginning security tests, document:
  • What systems will be tested
  • What testing methods will be used
  • Time windows for testing
  • Success criteria and stop conditions
2

Obtain Permission

If testing peer applications:
  • Get written or documented permission
  • Share your testing plan
  • Agree on communication protocols
  • Establish incident response procedures
3

Set Boundaries

Understand what is out-of-scope:
  • Social engineering against real people
  • Testing production environments
  • Attacks that could cause data loss
  • Excessive resource consumption (DoS)

​
SAST Best Practices

Static Application Security Testing analyzes source code without execution.

Code Review Checklist

Review code for:
  • Privacy issues (unnecessary data storage)
  • Authentication mechanisms
  • Authorization controls
  • Data validation
  • Exception handling
  • Session management
  • Logging practices
  • Encryption usage

Automated SAST Tools

Utilize tools from the OWASP SAST Tools List:
  • Bandit (Python)
  • SonarQube
  • GitHub Security Scanning
  • Semgrep
Privacy:
  • Is sensitive data stored unnecessarily?
  • Are passwords encrypted before storage?
  • Can users download and delete their data?
  • Are users provided access to privacy policy?
  • Is sensitive data logged to error files?
Authentication:
  • Are users properly authenticated?
  • What authentication factors are used?
  • Are there password complexity policies?
  • Are sessions properly managed?
Data Validation:
  • Is user-submitted data validated?
  • When is validation performed?
  • What validation methods are used (whitelist/blacklist)?
  • Are SQL queries using parameterized statements?
Error Handling:
  • What error details are shown to users?
  • Are errors logged with sufficient detail?
  • Are database errors properly handled?

​
DAST Best Practices

Dynamic Application Security Testing examines running applications.
1

Prepare Testing Environment

  • Ensure sandbox is properly isolated
  • Deploy application in testing mode
  • Configure logging for detailed capture
  • Prepare monitoring tools
2

Use Automated DAST Tools

Leverage tools from the OWASP DAST Tools List:
3

Test Common Vulnerabilities

Systematically test for:
  • SQL injection
  • Cross-site scripting (XSS)
  • Cross-site request forgery (CSRF)
  • Broken authentication
  • Security misconfigurations
  • Sensitive data exposure
4

Document Findings

Record all vulnerabilities with:
  • Detailed description
  • Steps to reproduce
  • Impact assessment
  • Recommended remediation
  • Screenshots or evidence
DAST Tool Selection: For the NESA Software Engineering Syllabus, students only need to know that penetration testing tools exist and have basic experience with using a tool and its reporting capabilities. Don’t spend excessive time comparing tools.

​
Penetration Testing Best Practices

Penetration testing simulates real-world attacks to find and exploit vulnerabilities.

​
Types of Penetration Testing

White-Box

Full knowledge of application. Tester has access to source code and can monitor logs in real-time.

Grey-Box

Partial knowledge of application. Some documentation and credentials provided.

Black-Box

No background information. Only the front-end is accessible, simulating external attacker.

​
Brute Force Testing

Test input fields and URL parameters with non-destructive XSS test scripts:
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg/onload=alert('XSS')>
Test locations:
  • Form input fields
  • URL parameters
  • HTTP headers
  • File upload names
  • Search queries
Test authentication and data queries with SQL injection patterns:
' OR '1'='1
' OR '1'='1' --
' OR '1'='1' /*
admin' --
1' UNION SELECT NULL--
Test locations:
  • Login forms
  • Search fields
  • URL parameters
  • Any user input that queries a database
Use common username and password lists for dictionary attacks:Common weak passwords:
  • password, 123456, admin
  • Default credentials
  • Password variations
Test responsibly:
  • Implement rate limiting in testing
  • Don’t overwhelm the system
  • Document successful compromises

​
Useful Testing Tools

HTTP Request Testing

Simple HTTP Request Tool - Test HTTP requests for localhost websites

Data Analysis

CyberChef - Swiss Army Knife for analyzing and decoding data

DNS/Network Scanning

ViewDNS - DNS and hosting scanning tools

SSL/TLS Testing

SSL Labs - SSL scanning and validation tools

API Testing

Postman - Test APIs and applications

Network Analysis

Wireshark - Network protocol analyzer

​
Testing Workflow and Documentation

​
Systematic Testing Approach

1

Phase 1: Reconnaissance

Information Gathering:
  • Map application structure
  • Identify technologies used
  • Document endpoints and functionality
  • Review available source code (white-box)
Tools: Browser DevTools, Wappalyzer, manual exploration
2

Phase 2: Automated Scanning

SAST:
  • Run static code analysis tools
  • Review tool reports
  • Prioritize findings by severity
DAST:
  • Run automated vulnerability scanners
  • Configure scanners for thorough coverage
  • Review and triage findings
Tools: Bandit, SonarQube, ZAPROXY, Burp Suite
3

Phase 3: Manual Testing

Code Review:
  • Examine authentication logic
  • Review data validation
  • Check error handling
  • Assess session management
Penetration Testing:
  • Test for injection flaws
  • Attempt XSS attacks
  • Test CSRF protection
  • Verify access controls
4

Phase 4: Documentation

For Each Vulnerability:
  • Vulnerability name and type
  • Severity level (Critical/High/Medium/Low)
  • Detailed description
  • Affected components
  • Steps to reproduce
  • Proof of concept (screenshots, code)
  • Impact assessment
  • Recommended remediation
5

Phase 5: Remediation

Implement Fixes:
  • Develop patches using HTML/CSS/JS/SQL/JSON/Python
  • Test patches in sandbox
  • Verify vulnerability is resolved
  • Document the fix
  • Re-scan to ensure no new issues introduced
6

Phase 6: Final Report

Professional Report Including:
  1. Overview of technical analysis approach
  2. Out-of-scope items
  3. All vulnerabilities with impact assessments
  4. Recommendations for security by design
  5. Implementation of patches and fixes

​
Report Structure Template

  • Project overview
  • Testing methodology
  • High-level findings
  • Critical vulnerabilities summary
  • Overall security posture assessment
  • Testing scope and boundaries
  • Tools and techniques used
  • Testing environments
  • Timeline of activities
  • Team members involved
Security/privacy issues that cannot be mitigated by technical solutions:
  • Organizational policies
  • User behavior and training
  • Physical security
  • Third-party dependencies
Issues that must be tested in production:
  • Performance under real load
  • Integration with production services
  • Actual SSL/TLS configurations
  • Production network security
For each vulnerability:
  • ID: VUL-001
  • Title: SQL Injection in Login Form
  • Severity: Critical
  • Description: The login form does not properly sanitize user input…
  • Location: /login endpoint, username parameter
  • Steps to Reproduce:
    1. Navigate to login page
    2. Enter admin' OR '1'='1 in username
    3. Enter any password
    4. Click submit
  • Impact: Attacker can bypass authentication and gain admin access
  • Evidence: [Screenshot or code snippet]
  • Recommendation: Use parameterized queries
  • Authentication and authorization improvements
  • Input validation strategies
  • Security headers implementation
  • Encryption requirements
  • Logging and monitoring
  • Secure development practices
  • Security testing in SDLC
  • Incident response procedures
For each patched vulnerability:
  • Vulnerability ID: VUL-001
  • Fix Description: Implemented parameterized queries
  • Code Changes: 
    # Before
query = f"SELECT * FROM users WHERE username='{username}'"

# After  
query = "SELECT * FROM users WHERE username=?"
cursor.execute(query, (username,))
  • Files Modified: app.py, line 45-50
  • Testing: Verified SQL injection no longer possible
  • Status: Resolved

​
Environment Maintenance

​
Regular Updates

1

Update Base System

Keep your sandbox OS and container images updated:
# For Ubuntu/Debian VMs
sudo apt update && sudo apt upgrade

# For Docker images
docker pull python:3.9-slim
2

Update Dependencies

Regularly update Python packages and testing tools:
pip install --upgrade flask
pip list --outdated
3

Update Testing Tools

Keep SAST/DAST tools current for latest vulnerability detection:
# Update ZAPROXY, Burp Suite, etc.

​
Snapshot Management

For VM-based sandboxes, maintain a library of snapshots at key stages of testing for easy rollback and comparison.
Recommended snapshots:
  • Clean Install: Fresh OS with dependencies installed
  • Application Deployed: App running with test data
  • Pre-Test: Before beginning security assessment
  • Post-Patch: After implementing security fixes

​
Resource Monitoring

1

Monitor Disk Space

df -h  # Check available disk space
du -sh /path/to/sandbox  # Check sandbox size
2

Monitor Memory Usage

free -h  # Check available RAM
docker stats  # Monitor container resource usage
3

Clean Up Regularly

# Remove old Docker containers and images
docker system prune -a

# Clear logs
sudo journalctl --vacuum-time=7d

​
Emergency Procedures

​
If Sandbox is Compromised

If you suspect your sandbox has been compromised or behaving unexpectedly:
1

Isolate Immediately

  • Disconnect network access
  • Pause or stop the VM/container
  • Do not access any other systems
2

Document the Incident

  • Note what you were testing
  • Record any unusual behavior
  • Save logs if accessible
  • Take screenshots
3

Restore from Snapshot

  • Restore to last known good state
  • If no snapshots, rebuild from scratch
  • Do not attempt to “fix” a compromised sandbox
4

Review and Learn

  • Analyze what went wrong
  • Update testing procedures
  • Document lessons learned
  • Share with peers if appropriate

​
If Host System is Affected

Critical: If you believe your host system (not just the sandbox) has been compromised:
  1. Disconnect from network immediately
  2. Contact your instructor or IT security team
  3. Do not attempt to investigate alone
  4. Follow institutional incident response procedures
  5. Report as required by Australian Government guidelines: Responding to cyber security incidents

​
Additional Resources

OWASP Testing Guide

Comprehensive web security testing resource

Australian Privacy

Privacy compliance guidelines

NESA Syllabus

Software Engineering course specifications

Student Resources

Implementation guides and testing resources

​
Next Steps

Start Security Testing

Begin your systematic security assessment of the Normo Unsecure PWA

Review Vulnerabilities

Learn about common vulnerabilities and how to identify them

Build docs developers (and LLMs) love

Get started for freeTalk to us