Authorization, scope, and ethics

Why this matters

The single difference between a security professional and a criminal is permission. The commands are often identical. Sending ' OR 1=1-- to a login form is a paid, respected job when the system owner asked you to test it and a crime when they did not. Courts around the world treat unauthorized access to a computer as an offence regardless of whether any data was changed or any harm was intended. In the United States that is the Computer Fraud and Abuse Act; the United Kingdom has the Computer Misuse Act; most countries have an equivalent. "I was only looking" is not a defence, and "the site was insecure" is not consent.

So before you learn a single attack, you learn the discipline that makes attacks lawful and useful: authorization (someone with the authority to say yes has said yes, in writing), scope (exactly which systems, which techniques, and which times are permitted), and rules of engagement (what you will do if you find something dangerous, and what you will never do). A practitioner who cannot write these down cannot be trusted with the techniques that follow.

There is a second reason this comes first. Every offensive skill in this course exists to serve defence. You learn how SQL injection works so you can write code that resists it, find it in a code review, and recognise it in a log. The attacker's view is a means to a defender's end. If you ever feel the pull to "just try it" on something you do not own, you have lost the plot of this course.

Concepts

The lab contract. Everything you do in this course happens inside one isolated lab. You are given two machines: `attacker01`, a Linux workstation with a browser and command-line tools, and `target01`, a single deliberately vulnerable web application. They sit on a private network with no route to the internet and default-deny rules: target01 can be reached only from attacker01, and neither can reach anything outside the lab. This is not a formality. It means a mistake cannot escape, and it means you are never tempted to point a tool at a real system. The non-negotiable rule of this course: every technique targets only your own assigned `target01`. There is no internet-facing or third-party scanning, ever.

Authorization is explicit, documented permission from the party that owns or operates the system, granted by someone with the authority to grant it. A tester keeps this in writing because memory and good intentions are not evidence. In this lab, your authorization is the enrolment itself: Ultiblob owns the lab and authorizes you to test target01 and nothing else.

Scope is the fence around the work. A real scope document lists the exact hosts, URLs, or IP ranges in scope; the techniques allowed (for example, "no denial-of-service, no social engineering, no phishing of staff"); the testing window; and the accounts you may use. Anything not named is out of scope and therefore forbidden. Scope protects the client from surprises and protects you from crossing a line.

Rules of engagement (RoE) describe conduct: who your point of contact is, how you report a serious finding immediately rather than exploiting it further, that you will not exfiltrate real personal data, that you will not pivot to systems outside scope even if you *can*, and how you stop cleanly. Good RoE also cover the "stop button" — the signal to halt everything at once.

Prohibited by this course, regardless of skill. This course never teaches, and you will never practise: developing malware, ransomware, or command-and-control frameworks; stealing credentials from real accounts; evading defences in order to attack real systems; or attacking anything you do not own. The tools are the standard teaching set — a browser and its developer tools, curl, nmap used only against target01, and deliberately vulnerable practice apps. Where a professional tool needs a licence (for example the intercepting proxy Burp Suite), we describe the concept and use an open equivalent so you can complete the course without one.

The blue-team payoff. Keep a habit from lesson one: for every attack you learn, write the fix and a detection idea next to it. That is the shape of the whole course and the shape of a valuable practitioner. Anyone can paste a payload; the professional closes the hole and makes sure the next attempt is seen.

Guided exercise

You will confirm the lab is isolated and write your own rules-of-engagement note. This note is a habit you will reuse in every engagement for the rest of your career.

Open the lab console for `target01` and confirm it is provisioned and running. You are confirming the machine you are *authorized* to test exists and is the only target.

On `attacker01`, create a working folder and open a new file for your rules of engagement:

``bash mkdir -p ~/assessment nano ~/assessment/scope.md

Write a short rules-of-engagement note. Use this as a template and complete each line in your own words:

``text # Rules of engagement — Ultiblob Learning ethical-hacking lab Authorization: I am enrolled in ULC-007 and authorized by Ultiblob to test target01 only. In scope: target01 (the teaching application on my isolated lab network). Out of scope: every other host; the internet; any real or third-party system. No exceptions. Techniques: web application testing with a browser, curl, and nmap against target01 only. No denial-of-service. No attacks on the lab platform itself. Data: the app's data is synthetic. I will not treat any value as a real secret. Conduct: if I find something I do not understand, I stop and take notes before continuing. Stop: I can tear down and reset the lab at any time (see the reset guide).

Save the file. Confirm it names target01 and records your authorization and scope.

Submit your rules-of-engagement note for instructor review. Your instructor confirms it is complete before you move on to techniques.

Troubleshooting

Symptom → *I want to test my own website / my company's site to practise.* → cause: that site is out of scope for this course and may be hosted by a third party who has not authorized you. → fix: practise only on target01. To test a real system you must have written authorization from its owner; that is a separate, formal engagement, not coursework.

Symptom → *The lab says target01 is not running.* → cause: the environment has not finished provisioning, or a previous session left it stopped. → fix: start target01 from the lab console and wait for it to report running; if it will not start, use the reset procedure your instructor provides.

Symptom → *A tool I read about online needs me to "just point it at any URL".* → cause: generic internet tutorials assume you own the target. → fix: in this course, the only URL you ever point a tool at is your target01. If an instruction anywhere tells you to scan something else, it is wrong for this course — do not follow it.

Symptom → *I found something that looks like a real credential or personal record.* → cause: the teaching app ships with lifelike but synthetic data. → fix: treat it as synthetic, do not reuse it anywhere, and note it as a finding. In a real engagement you would stop and notify your contact rather than explore further.

Check your understanding

A friend asks you to "quickly check if their bank's website is hackable." What do you do?

Decline. You have no authorization from the bank, and the bank is out of scope for anything you do. Unauthorized testing of a system you do not own is illegal regardless of intent. The only lawful way to test a real system is with written authorization from its owner.

Why write scope and rules of engagement down instead of just remembering them?

Because they protect both sides and must be evidence, not memory. A written scope proves what you were permitted to do, keeps you from drifting into forbidden systems, and gives the client confidence. If a dispute ever arises, "we agreed verbally" is worth very little.

This course teaches attacks. How is that a defensive skill?

You cannot defend against what you do not understand. Learning exactly how an attack works lets you write code that resists it, catch it in review, and detect it in logs. Every technique here is paired with its fix and a detection idea for that reason.

Summary and next step

The difference between security work and crime is authorization; scope and rules of engagement

put that permission in writing and keep you inside it.

This entire course lives in an isolated, internet-free lab; you test only your own target01,

and the course never teaches real-world intrusion, malware, or credential theft.

For every attack, you will also write the fix and a way to detect it — that is the point.

Next, lesson 2 builds the shared language you need before touching the target: how HTTP requests and responses, cookies, and sessions actually work, seen through curl and your browser's developer tools.

References

OWASP Web Security Testing Guide — testing principles and rules of engagement — https://owasp.org/www-project-web-security-testing-guide/ (accessed 2026-09-13)
OWASP Juice Shop project (the deliberately vulnerable teaching target used in this course) — https://owasp.org/www-project-juice-shop/ (accessed 2026-09-13)
CISA — Coordinated Vulnerability Disclosure Process — https://www.cisa.gov/coordinated-vulnerability-disclosure-process (accessed 2026-09-13)

Signing in saves eligible progress. It does not enroll you or include a lab; review the career path for access terms.