Security Testing — Specialised

1 The Hook

In 2019, an NZ health provider discovered that a simple SQL injection vulnerability in their patient portal had been leaking personal health information for eight months. A security researcher — not a malicious hacker, thankfully — found it by typing a single quote into a search box and watching the database error message reveal the internal schema.

The breach affected 12,000 patients. The organisation faced an investigation by the Privacy Commissioner, mandatory public notification, and a complete rebuild of their authentication layer. Total cost: estimated $4.7 million.

The vulnerability was detectable with a free tool in under 10 minutes.

Security testing is not just for banks and spy agencies. In NZ, the Privacy Act 2020 requires every organisation to take "reasonable safeguards" against unauthorised access to personal information. The Health Information Privacy Code is even stricter. And if you handle credit cards, PCI-DSS compliance is non-negotiable.

Security testing is the difference between finding a hole in your fence yourself — and discovering it when someone has already taken everything.

2 The Rule

Security testing identifies vulnerabilities that could allow unauthorised access, data exposure, or system compromise, and verifies that controls prevent, detect, and respond to attacks.

It is not about proving the system is "secure" — security is a process, not a destination. It is about reducing risk to an acceptable level, and knowing exactly what risks remain.

3 The Analogy

Analogy

Hiring a professional burglar to test your home security.

You have locks, alarms, and cameras. But a professional burglar knows tricks you have never thought of: sliding a credit card through a door frame, using a ladder you left against the garage, or finding the spare key under the fake rock. A security tester is that professional burglar — hired by you, before the real criminals arrive. They do not just check if the door is locked. They test every window, every blind spot, and every human habit that creates vulnerability.

4 OWASP Top 10: The Essential Checklist

The Open Web Application Security Project (OWASP) publishes the industry-standard list of the most critical web application security risks. Every tester should know these by heart.

1 Broken Access Control [Critical]

Users can access resources or perform actions they should not be able to. Example: changing a URL parameter from user_id=123 to user_id=124 and seeing someone else's data.

2 Cryptographic Failures [Critical]

Sensitive data exposed through weak encryption, hardcoded keys, or plaintext storage. Example: passwords stored without salting, credit card numbers in logs.

3 Injection [Critical]

Untrusted data sent to an interpreter as part of a command or query. SQL injection is the most famous, but NoSQL, OS command, and LDAP injection are equally dangerous.

4 Insecure Design [High]

Fundamental design flaws that cannot be fixed with patches. Example: a password reset flow that reveals whether an email exists in the system.

5 Security Misconfiguration [High]

Default credentials, unnecessary features enabled, verbose error messages, unprotected cloud storage. Often the easiest vulnerability to find and exploit.

6 Vulnerable Components [High]

Using outdated libraries, frameworks, or plugins with known vulnerabilities. Example: an old version of Log4j that allows remote code execution.

7 Authentication Failures [Critical]

Weak password policies, no MFA, session tokens that never expire, brute-force protection missing. Allows attackers to impersonate legitimate users.

8 Data Integrity Failures [High]

Unsafe deserialization, untrusted CI/CD pipelines, lack of integrity checks on software updates. Supply chain attacks fall into this category.

9 Logging Failures [Medium]

Insufficient logging and monitoring means breaches go undetected for months. The average time to detect a breach is 287 days without proper monitoring.

10 SSRF [High]

Server-Side Request Forgery: the server fetches a remote resource without validating the URL. Can expose internal services, cloud metadata, and internal APIs.

5 Types of Security Testing

Vulnerability Scanning

Automated tools that crawl your application and check for known vulnerabilities. Fast, broad, but prone to false positives. Good for regular baseline checks. Tools: OWASP ZAP (baseline scan), Nessus, Qualys.

Penetration Testing (Pen Testing)

A human security expert simulates a real attack. They think creatively, chain vulnerabilities together, and probe business logic flaws that scanners miss. Required annually for PCI-DSS. In NZ, look for CREST or OSCP certified testers.

Authentication & Authorisation Testing

Verify that users can only do what they are allowed to do. Test role-based access control (RBAC), session management, token expiration, password policies, and multi-factor authentication bypass attempts.

Injection Testing

Deliberately send malicious input to every input field, URL parameter, header, and API endpoint. SQL injection, XSS (Cross-Site Scripting), command injection, XML external entity (XXE) attacks.

API Security Testing

APIs are often less protected than web UIs. Test for broken object-level authorisation (BOLA), excessive data exposure, mass assignment, and lack of rate limiting. OWASP API Security Top 10 is the standard here.

6 Tools in Action

OWASP ZAP — Automated baseline scan

ZAP is free, open-source, and the most accessible security testing tool for testers. Run a baseline scan against any web application in minutes.

# Docker one-liner for a baseline scan
# Replace TARGET with your staging URL
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.example.co.nz \
  -r zap-report.html

This command spiders your site, scans for vulnerabilities, and generates an HTML report with risk ratings (High, Medium, Low, Informational). Run it in CI/CD before every deployment.

Manual SQL Injection Test — Step by Step

Find any input field that queries a database (search box, login form, filter).
Enter a single quote: '
If the application returns a database error (e.g., "Unclosed quotation mark"), it is vulnerable.
Try: ' OR '1'='1 — if this bypasses authentication, you have confirmed injection.
Try: ' UNION SELECT username, password FROM users-- — this extracts data.
Never test on production. Always use a dedicated test environment with synthetic data.

Burp Suite is the professional standard for manual penetration testing. Its proxy intercepts all traffic between your browser and the application, letting you modify requests, replay them, and automate attacks. The Community Edition is free; Professional adds the scanner and advanced tools.

7 NZ Compliance & NZISM

Security testing in NZ is not just good practice — it is often legally required.

Privacy Act 2020: Organisations must protect personal information from loss, unauthorised access, and misuse. A "notifiable privacy breach" must be reported to the Privacy Commissioner and affected individuals (see Privacy Testing for the full IPP framework).
Health Information Privacy Code 2020: Stricter rules for health data. Security testing is effectively mandatory for any health application.
PCI-DSS: If you store, process, or transmit credit card data, you must perform annual penetration testing and quarterly vulnerability scans.
NZISM (New Zealand Information Security Manual): Issued by GCSB/NCSC, the NZISM is mandatory for public service agencies and most Crown entities. Baseline controls cover authentication, identity and access management, cryptography, incident management, logging, supply chain, vulnerability management, and zero trust. Testers verify configured controls match the classification (OFFICIAL, SENSITIVE, RESTRICTED) that applies to the system. See nzism.gcsb.govt.nz.
ISO 27001 / SOC 2: Private-sector contractors to government or enterprise often align with these alongside NZISM.

NZISM checks a tester can verify without a security clearance

TLS 1.2+ enforced; weak ciphers disabled (test with testssl.sh or SSL Labs)
Passwords stored with a modern hash (bcrypt, argon2id) — check the DB column
MFA available and enforceable for privileged accounts
Audit logs exist for access to sensitive data, not just writes
Session expiry and reauthentication for privileged actions
No sensitive data in URL query strings, browser console, or client-side storage
Supply chain: third-party scripts and CDNs documented; Subresource Integrity (SRI) on external scripts

8 Hands-On Labs

Reading about SQL injection is not the same as doing SQL injection. Build a personal pentest lab at home so you can practise attacks safely, without touching anything you do not own. These are the labs the rest of the industry uses.

Lab 1: OWASP Juice Shop

The most modern and sophisticated insecure web application in open source. Covers the entire OWASP Top 10 plus many real-world flaws. Over 100 hacking challenges with a scoreboard and hints.

Start Juice Shop in under 2 minutes

docker run --rm -p 3000:3000 bkimminich/juice-shop
# Open http://localhost:3000
# Scoreboard URL is intentionally hidden — your first challenge is to find it

Starter challenges:

Find the scoreboard page (hint: view source)
Log in with SQL injection in the email field
Find a reflected XSS in the search
Access another user’s basket (broken access control)
Download a file outside the intended directory (path traversal)
Discover the secret admin section (forced browsing)

Official guidebook (Pwning OWASP Juice Shop) gives full solutions when you are stuck: help.owasp-juice.shop.

Lab 2: Damn Vulnerable Web Application (DVWA)

A classic MySQL/PHP app built to be attacked. Each vulnerability has four security levels (Low, Medium, High, Impossible) so you can learn how defences evolve against the same attack.

Run DVWA via Docker

docker run --rm -p 80:80 vulnerables/web-dvwa
# Open http://localhost
# Default login: admin / password
# Set DVWA Security = Low to start

Work through Brute Force, Command Injection, CSRF, File Inclusion, SQL Injection (including Blind), XSS (Reflected, Stored, DOM). Then repeat at Medium and High to see how parameterised queries, CSRF tokens, and output encoding defeat the attacks.

Lab 3: PortSwigger Web Security Academy

Free, browser-based labs from the makers of Burp Suite. Covers OWASP Top 10, authentication, business logic, WebSockets, GraphQL, OAuth, JWT, prototype pollution, race conditions, and 2025 additions for HTTP/2 request smuggling.

No installation required — labs run in your browser
Each topic has explainer content + guided labs + expert labs
Pair with free Burp Suite Community Edition as your interception proxy
Work toward the Burp Suite Certified Practitioner cert if you want a recognisable credential
URL: portswigger.net/web-security

Lab 4: Build a Kali + vulnerable-target lab

When you have outgrown browser-based labs, build a two-VM setup: a Kali Linux attacker and a vulnerable target (Juice Shop + DVWA in Docker on a separate VM). Snapshot both. Keep the lab isolated from your home network.

Tools to learn in Kali

Burp Suite Community — intercepting proxy for manual pentesting
OWASP ZAP — free dynamic application scanner
Nmap — network discovery and port scanning
SQLMap — automated SQL injection exploitation
Nikto — web server scanner
Hydra / John the Ripper — credential brute force and password cracking
Wireshark — packet capture and inspection
gobuster / ffuf — directory and parameter fuzzing

Lab 5: API security with OWASP crAPI

The Completely Ridiculous API (crAPI) is a Docker-based vulnerable API covering the OWASP API Security Top 10. Essential if you test REST or GraphQL APIs.

git clone https://github.com/OWASP/crAPI.git
cd crAPI/deploy/docker
docker compose up -d
# Web UI http://localhost:8888, API http://localhost:8888/api/

Safety first: Never point these tools at systems you do not own and have not been explicitly authorised to test. Unauthorised security testing in NZ is an offence under the Crimes Act 1961 (ss 248–252: accessing a computer system without authorisation). Keep labs on isolated networks.

9 Common Mistakes

🚫 Testing only the login page

I used to think: If login is secure, the app is secure.
Actually: Every endpoint, every API, every file upload, every query parameter is an attack surface. A secure front door means nothing if the back window is open.

🚫 Running security tests on production

I used to think: Production is the only place that matters.
Actually: A SQL injection test on production can corrupt data, lock accounts, or trigger fraud alerts. Always use an isolated test environment with synthetic data. Get written permission before any testing.

🚫 Treating security as a final gate

I used to think: Run a scan the week before launch.
Actually: Security defects are cheapest to fix during design. Shift left: threat model during requirements, code review for security, SAST in CI/CD, DAST in staging. The earlier you find it, the cheaper it is to fix.

🚫 Ignoring business logic flaws

I used to think: Scanners find everything.
Actually: No scanner can detect "buy a $1,000 item for $1 by intercepting and modifying the price parameter in the checkout API request." Business logic testing requires human creativity.

10 Now You Try

🎯 Scenario Exercise (45 min)

Scenario: You are testing an NZ online insurance quote system. Users enter personal details (name, address, vehicle registration, prior claims) and receive a quote. The application stores this data and allows users to retrieve quotes by entering their email and a quote reference number.

Your task: Design a security test plan covering at least four different attack vectors. For each, specify:

The vulnerability you are testing for
The test input or technique
The tool you would use
What a "pass" looks like

11 Self-Check

Click each question to reveal the answer.

Q1. What is the difference between vulnerability scanning and penetration testing?

Scanning is automated and broad; it finds known vulnerabilities quickly but with false positives. Penetration testing is manual and deep; a human expert chains vulnerabilities, tests business logic, and simulates real attacker behaviour.

Q2. What does SQL injection allow an attacker to do?

Execute arbitrary database commands. This can expose, modify, or delete data; bypass authentication; and in severe cases, execute operating system commands on the database server.

Q3. Under NZ law, when must a privacy breach be reported?

The Privacy Act 2020 requires notification if the breach has caused or is likely to cause serious harm to affected individuals. Notification goes to the Privacy Commissioner and the individuals themselves.

Q4. Why is "shift left" important in security testing?

Security defects found in design or code are orders of magnitude cheaper to fix than those found in production. A flaw in architecture may require a complete rebuild; the same flaw caught in a threat model is a one-hour design tweak.