Don't Get Arrested

Start HereLesson 2 of 215 minutes

Learning objectives

By the end of this lesson

• Explain what authorized access means in practice.
• Recognize when permission does not cover the research you want to perform.
• Identify the targets that are safe to use throughout this course.

Permission is the boundary

Vulnerability research involves making computers do things their owners did not expect. Whether that work is research or a crime depends heavily on one question: are you authorized to do it?

In the United States, the main federal law governing unauthorized computer access is the Computer Fraud and Abuse Act, or CFAA. The CFAA covers several different offenses involving access to computers “without authorization” or in a way that “exceeds authorized access.”

This lesson is not personal legal advice, and the CFAA is not the only law that may apply. Laws also vary by location. Our course rule is deliberately simpler: only investigate systems when you have clear permission from someone who has the authority to give it.

Safety note

Public does not mean authorized

A system being connected to the internet does not make it a practice target. A visible door is not the same thing as an open invitation.

What authorized access means

Authorization is permission to access a particular system in a particular way. It comes from the owner or another person who has the authority to grant it.

Permission has boundaries. Being allowed to create an account on a website does not give you permission to access another user’s account. A bug bounty may authorize testing one application while specifically excluding another. Permission to scan a system does not automatically include permission to exploit it or retrieve its data.

The CFAA defines exceeding authorized access as using authorized computer access to obtain or alter information that you are not entitled to obtain or alter. In Van Buren v. United States, the Supreme Court explained that this concerns entering parts of a computer that are off limits, rather than merely using accessible information for an improper reason.

That distinction matters in court, but it is not a loophole to experiment around. You should not need a Supreme Court opinion and a flowchart to decide whether your next command is a good idea. If permission is missing, unclear, revoked, or does not cover what you want to do, stop.

Good intentions are not permission

The Department of Justice’s current CFAA charging policy says that good-faith security research should not be charged. It describes that research as work performed solely to test, investigate, or correct a vulnerability; designed to avoid harm; and used primarily to improve security or safety.

That is an important recognition that legitimate research benefits everyone. It is not permission to test any system you choose. The policy guides federal prosecutors; it does not create a legal defense, bind other authorities, or protect someone who claims “research” after ignoring a system owner’s boundaries.

Your intention to help does not replace authorization. Neither does curiosity, technical ability, or confidence that nobody will notice.

Crime is not a career plan

There is a persistent movie myth about the brilliant black-hat hacker who gets arrested, impresses the government, and is recruited from the courtroom into a secret cyber unit. That is fiction. An arrest is not an unconventional internship, and a criminal record is a remarkably bad addition to a security resume.

It is not cool to be arrested for hacking. You will not become a mysterious underground legend. You will lose time, money, equipment, opportunities, and possibly your freedom. You will also be made fun of in prison, which is a fairly undignified ending to a story that probably began with “I was just curious.”

Real vulnerability researchers build trust. They work within authorization, keep their word, and report what they find responsibly. Those habits open doors. Breaking into someone else’s systems tends to close them.

Targets you may use in this course

Throughout this course, limit your work to:

• targets provided by the course, used according to the lab instructions;
• systems and software you own and control;
• intentionally vulnerable training platforms, used within their published rules; or
• systems covered by clear, specific authorization from someone who can grant it.

Bug bounty programs count only within their written scope. Read the allowed targets, prohibited techniques, and reporting rules before testing. A company having a bounty program does not make everything the company owns fair game.

Checkpoint

The authorization check

Before testing anything, answer three questions:

1. Who owns this target?
2. What gives me permission to test it?
3. Does that permission cover the exact action I am about to take?

If any answer is unclear, do not proceed.

The rule going forward

Every course lab will give you an authorized target and boundaries. Stay inside them. When you want to try something beyond a lab’s instructions, reproduce the idea on a system you own instead of borrowing a stranger’s server.

Authorization is not paperwork we endure before the real research begins. It is part of the research process. Learn that habit now, and it will still be there when the tools become much more powerful.

Knowledge check

Question 1 of 3

A company has a public bug bounty program. What are you authorized to test?

Anything the company ownsOnly the targets and techniques allowed by the program rulesAny system you can reach without bypassing a password

Check answer

Next, we will learn what a virtual machine is and build the controlled environment used for the rest of the course.