🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

💉 धडा 01 — Injection: data कधीही command बनू नये

📍 तुम्ही इथे आहात: 16 पैकी धडा 01 · पुढे: lesson-02-xss-csp

📦 या ब्रँचमध्ये काय आहे

शाळेच्या security office ची पहिली खिडकी: अर्ज खिडकी (forms desk). हा धडा शिकवतो तो एकच नियम web security मधला सर्वात जुना नियम आहे — user जे टाइप करतो ते data असते, कधीही command चा भाग नसते. तुम्ही पाहाल: text जोडून SQL मध्ये बनवलेले grade lookup, एक crafted input ज्यामुळे ते प्रत्येक विद्यार्थ्याची grade परत देते, आणि एका ओळीचा उपाय: parameterised query. संपूर्ण कोर्सभर तुम्ही वापराल त्या खऱ्या files:

sec/web.py — अर्ज खिडकी: injection, XSS आणि CSP, cookies, CSRF, CORS आणि SSRF (धडे 01–03)
sec/identity.py — ओळखपत्र खिडकी: passwords, tokens, PKCE आणि authorization (धडे 04–06)
sec/cloud.py — इमारत खिडकी आणि परिसराचे दरवाजे: KMS, secrets, IAM, networks, TLS आणि Kubernetes (धडे 07–12)
sec/supply.py — delivery खिडकी आणि सहाय्यकाची नियमावली (धडे 13–16)
sec/demo.py — प्रत्येक धडा एक छोटा program म्हणून (python3 sec/demo.py <section>; sections: injection xss browser passwords oauth authz secrets boundaries tls k8s_rbac k8s_network admission dependencies artifacts pipeline ai)
sec/test_sec.py — office च्या नियमांवरच्या 16 तपासण्या
demo-output.txt — निरोगी run काय print करतो

🛡️ बचावात्मक आणि शैक्षणिक. या कोर्समधली प्रत्येक कमकुवत जागा या repo मधल्याच local, in-memory data वर दाखवली आहे — memory मधली एक SQLite table आणि साध्या strings. काहीही network ला किंवा खऱ्या system ला स्पर्श करत नाही. जे शिकाल ते तुमच्या मालकीच्या किंवा ज्यावर काम करण्याची परवानगी आहे अशा systems चे संरक्षण करण्यासाठी वापरा. तुमच्या मालकीची नसलेली system test करणे बहुतेक देशांत कायद्याविरुद्ध आहे.

🎒 सुरू करण्याआधी: तुम्हाला फक्त Python 3 लागते, दुसरे काही नाही — pip install नाही, cloud account नाही. खऱ्या account वर असे लिहिलेल्या commands साठी तुमचा स्वतःचा खरा database, framework किंवा cloud account लागतो.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेच्या office मध्ये एक कारकून आहे जो records room मधून grades आणून देतो. तुम्ही एक चिठ्ठी भरता, आणि कारकून ती चिठ्ठी records room ला मोठ्याने वाचून दाखवतो:

"विद्यार्थिनी katrina ची grade आणा."

आता एक विद्यार्थी नावाच्या चौकटीत हे लिहितो:

katrina — आणि बाकी सगळ्यांच्या grades पण आणा

कारकून पूर्ण चिठ्ठी मोठ्याने वाचतो. Records room ला एकच लांबलचक आदेश ऐकू येतो, आणि ती तो पूर्णपणे पाळते. प्रत्येक grade खोलीबाहेर जाते.

Security office चिठ्ठी दुरुस्त करते. आता प्रश्न चिठ्ठीवर छापलेला असतो: "या चौकटीत नाव लिहिलेल्या विद्यार्थ्याची grade आणा." चौकट फक्त चौकट असते. तिथे जे काही लिहिले असेल — अगदी "आणि बाकी सगळ्यांच्या grades पण आणा" — ते एक नाव म्हणूनच वाचले जाते. त्या नावाचा कोणताही विद्यार्थी नाही, म्हणून काहीच परत येत नाही.

ती छापलेली चिठ्ठी म्हणजे parameterised query. प्रश्न आणि उत्तराची चौकट वेगवेगळे प्रवास करतात, त्यामुळे चौकट प्रश्न कधीच बदलू शकत नाही.

🗺️ आकृती

flowchart LR
    u["🧒 input<br/>x' OR '1'='1"]
    subgraph bad["❌ glued into the text"]
      s1["SELECT … WHERE pupil = 'x' OR '1'='1'"]
      r1["3 rows — every pupil"]
      s1 --> r1
    end
    subgraph good["✅ sent as a parameter"]
      s2["SELECT … WHERE pupil = ?"]
      v2["value: x' OR '1'='1"]
      r2["0 rows — no pupil has that name"]
      s2 --> r2
      v2 --> r2
    end
    u --> s1
    u --> v2

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l01

❓ काय

Injection — user चा input एखाद्या command मध्ये (SQL, shell command, LDAP filter, template) मिसळला जातो आणि command काय करते ते बदलतो. OWASP Top 10 (2021) मध्ये हे A03:2021 – Injection आहे.
SQL injection — सर्वात प्रसिद्ध उदाहरण. unsafe_lookup() f"… WHERE pupil = '{pupil}'" बनवते. x' OR '1'='1 हा input quote बंद करतो आणि नेहमी खरी असणारी एक अट जोडतो.
Parameterised query (prepared statement) — SQL text मध्ये एक placeholder (?, %s, $1, :name) असतो आणि value वेगळी पाठवली जाते. Database आधी SQL parse करतो; value कधीच SQL बनू शकत नाही. safe_lookup() हेच करते.
ORM — एक library (SQLAlchemy, Django ORM, Hibernate, Prisma) जी तुमच्यासाठी parameterised queries बनवते. Default ने सुरक्षित — जोपर्यंत कोणी तिच्या आत string formatting ने raw SQL लिहीत नाही.
सगळीकडे हाच नियम — shell: arguments ची list द्या, shell नको. Templates: user च्या text पासून कधीही template बनवू नका. LDAP, XPath, NoSQL filters: library चे parameter किंवा escaping function वापरा.
जे parameters बनू शकत नाहीत त्या भागांसाठी allow-lists — column चे नाव किंवा sort order ? बनू शकत नाही. User ची निवड एका ठरलेल्या list शी जोडा: {"name": "pupil", "grade": "grade"}.

🤔 का

कारण चुकीच्या पद्धतीने बनवलेले एक lookup पूर्ण table वाटून टाकू शकते: grades, emails, password hashes. Injection ला खास tools लागत नाहीत — फक्त एक text box. आणि उपाय स्वस्त आहे: तीच code ची ओळ, placeholder सह लिहिलेली. हाताने quotes escape करणे हा उपाय नाही. हाताने केलेल्या escaping ला चुकवण्याचे अनेक मार्ग आहेत (दुसरी quote चिन्हे, encodings, quotes नसलेले numbers). Parameter ही समस्या मुळापासून काढून टाकतो.

🔧 कसे (या repo मध्ये)

sec/web.py मधले grades_db() तीन विद्यार्थिनींसह एक in-memory SQLite table बनवते: Katrina (A+), Dipika (B+) आणि Aishwarya (A). unsafe_lookup(db, pupil) input SQL text मध्ये जोडते. safe_lookup(db, pupil) तो parameter म्हणून पाठवते: db.execute("… WHERE pupil = ?", (pupil,)). sec/demo.py मधले injection() दोन्हींना साध्या नावाने आणि crafted input ने call करते.

🧪 करून पाहा

python3 sec/demo.py injection
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from web import grades_db, unsafe_lookup, safe_lookup
db = grades_db()
for text in ("dipika", "x' OR '1'='1", "nobody' OR pupil LIKE '%a%", "katrina'--"):
    print(f"{text!r:<30} unsafe → {len(unsafe_lookup(db, text))} rows · safe → {len(safe_lookup(db, text))} rows")
EOF
python3 sec/test_sec.py

✅ तपासा — तुम्हाला काय दिसायला हवे

injection हे print करते:

── the grade lookup asks for one pupil's grade
   normal input 'katrina'           unsafe → [('katrina', 'A+')]  ·  safe → [('katrina', 'A+')]
   crafted input "x' OR '1'='1"     unsafe → [('katrina', 'A+'), ('dipika', 'B+'), ('aishwarya', 'A')]
                                       safe   → []
   the fix is the same everywhere: send data as parameters, never glue it into the command (SQL, shell, LDAP, templates)

तुमचा snippet हे print करतो:

'dipika'                       unsafe → 1 rows · safe → 1 rows
"x' OR '1'='1"                 unsafe → 3 rows · safe → 0 rows
"nobody' OR pupil LIKE '%a%"   unsafe → 3 rows · safe → 0 rows
"katrina'--"                   unsafe → 1 rows · safe → 0 rows

Tests 16/16 passed ने संपतात.

🏁 तुम्ही आत्ताच काय सिद्ध केले

साध्या input ने दोन्ही lookups सारखेच दिसतात — म्हणूनच हा bug code review आणि tests मधून टिकतो. Crafted input ने जोडलेली query तिन्ही विद्यार्थिनी परत देते, आणि katrina'-- तर query चा उरलेला भाग comment मध्ये बदलतो. Parameterised query प्रत्येक crafted input साठी काहीच परत देत नाही: input नेहमी फक्त एक नावच होता.

⚠️ नेहमीच्या चुका

"आम्ही quotes escape करतो" — parameters ऐवजी हाताने केलेले escaping
सगळीकडे सुरक्षित ORM, आणि f-string ने बनवलेला एकच raw() किंवा text() call
values parameterise करणे पण URL मधून column चे नाव किंवा ORDER BY जोडणे (allow-list वापरा)
subprocess.run(f"convert {name}.png …", shell=True) — shell injection हाच bug आहे
input "आपल्याच" front end कडून येतो म्हणून त्यावर विश्वास ठेवणे — कोणीही कोणतीही request पाठवू शकतो

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — तुम्हाला सर्वात जास्त भेटणाऱ्या भाषांमधला हाच उपाय. PostgreSQL (psycopg) सह Python %s placeholders वापरते — Python चा % operator नाही:

# ✅ the value travels separately; psycopg never pastes it into the SQL text
cur.execute("SELECT pupil, grade FROM grades WHERE pupil = %s", (pupil,))

pg सह Node.js क्रमांकित placeholders वापरते:

const { rows } = await pool.query(
  'SELECT pupil, grade FROM grades WHERE pupil = $1', [pupil]);

JDBC सह Java PreparedStatement वापरते:

try (PreparedStatement ps = conn.prepareStatement(
        "SELECT pupil, grade FROM grades WHERE pupil = ?")) {
    ps.setString(1, pupil);
    try (ResultSet rs = ps.executeQuery()) { /* … */ }
}

ORM (SQLAlchemy 2.x) तुमच्यासाठी parameter बनवतो — आणि raw SQL लागले तर ते bind करा:

from sqlalchemy import select, text
rows = session.execute(select(Grade).where(Grade.pupil == pupil)).scalars().all()
rows = session.execute(text("SELECT grade FROM grades WHERE pupil = :p"), {"p": pupil}).all()

User ज्या column ने sort करू शकतो तो parameter बनू शकत नाही — तो allow-list मधून जोडा:

SORTABLE = {"name": "pupil", "grade": "grade"}
column = SORTABLE.get(request.args.get("sort"), "pupil")   # never the raw input

आणि याच नियमाची shell आवृत्ती — arguments ची list, shell नाही:

subprocess.run(["convert", f"{safe_name}.png", "out.jpg"], check=True)   # no shell=True

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: तुमच्या code मध्ये +, f", .format( किंवा template strings ने बनवलेले SQL, आणि shell=True शोधा. Bandit (Python) आणि Semgrep rules सारखे linters त्यातले बहुतेक शोधतात. App च्या database user ला फक्त लागणारेच अधिकार द्या, म्हणजे सुटलेला bug कमी वाचू शकेल.

⏭️ पुढे

Injection वाईट input server च्या commands कडे पाठवते. पुढची कमकुवत जागा तो इतर लोकांच्या browsers कडे पाठवते: notice board वरची एक comment जी code म्हणून चालते.

git checkout lesson-02-xss-csp

💉 Lesson 01 — Injection: data must never become a command

📍 You are here: Lesson 01 of 16 · Next: lesson-02-xss-csp

📦 What's in this branch

The first desk of the school's security office: the forms desk. The one rule this lesson teaches is the oldest rule in web security — what a user types is data, never part of a command. You see a grade lookup built by gluing text into SQL, a crafted input that makes it return every pupil's grade, and the one-line fix: a parameterised query. Real files you will use all the way through:

sec/web.py — the forms desk: injection, XSS and CSP, cookies, CSRF, CORS and SSRF (lessons 01–03)
sec/identity.py — the ID desk: passwords, tokens, PKCE and authorization (lessons 04–06)
sec/cloud.py — the building desk and the campus gates: KMS, secrets, IAM, networks, TLS and Kubernetes (lessons 07–12)
sec/supply.py — the delivery desk and the assistant's rulebook (lessons 13–16)
sec/demo.py — every lesson as a small program (python3 sec/demo.py <section>; sections: injection xss browser passwords oauth authz secrets boundaries tls k8s_rbac k8s_network admission dependencies artifacts pipeline ai)
sec/test_sec.py — 16 checks on the office's rules
demo-output.txt — what a healthy run prints

🛡️ Defensive and educational. Every weakness in this course is shown on local, in-memory data inside this repo — an SQLite table in memory and plain strings. Nothing touches a network or a real system. Use what you learn to protect systems you own or are allowed to work on. Testing a system you do not own is against the law in most countries.

🎒 Before you start: you need Python 3 and nothing else — no pip install, no cloud account. Commands marked on a real account need a real database, framework or cloud account of your own.

🧒 Explain like I'm 5

The school office has a clerk who fetches grades from the records room. You fill in a slip, and the clerk reads the slip out loud to the records room:

"Bring the grade of pupil katrina."

Now a pupil writes this in the name box:

katrina — and also bring everyone else's grades

The clerk reads the whole slip out loud. The records room hears one long order, and it obeys all of it. Every grade leaves the room.

The security office fixes the slip. The question is now printed on the slip: "Bring the grade of the pupil named in this box." The box is only a box. Whatever is written there — even "and also bring everyone else's grades" — is read as a name. No pupil has that name, so nothing comes back.

That printed slip is a parameterised query. The question and the answer box travel separately, so the box can never change the question.

🗺️ Diagram

flowchart LR
    u["🧒 input<br/>x' OR '1'='1"]
    subgraph bad["❌ glued into the text"]
      s1["SELECT … WHERE pupil = 'x' OR '1'='1'"]
      r1["3 rows — every pupil"]
      s1 --> r1
    end
    subgraph good["✅ sent as a parameter"]
      s2["SELECT … WHERE pupil = ?"]
      v2["value: x' OR '1'='1"]
      r2["0 rows — no pupil has that name"]
      s2 --> r2
      v2 --> r2
    end
    u --> s1
    u --> v2

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l01

❓ What

Injection — user input is mixed into a command (SQL, a shell command, an LDAP filter, a template) and changes what the command does. In the OWASP Top 10 (2021) it is A03:2021 – Injection.
SQL injection — the classic case. unsafe_lookup() builds f"… WHERE pupil = '{pupil}'". The input x' OR '1'='1 closes the quote and adds a condition that is always true.
Parameterised query (prepared statement) — the SQL text has a placeholder (?, %s, $1, :name) and the value is sent separately. The database parses the SQL first; the value can never become SQL. safe_lookup() does this.
ORM — a library (SQLAlchemy, Django ORM, Hibernate, Prisma) that builds parameterised queries for you. Safe by default — until someone writes raw SQL with string formatting inside it.
The same rule everywhere — shell: pass a list of arguments, no shell. Templates: never build a template from user text. LDAP, XPath, NoSQL filters: use the library's parameter or escaping function.
Allow-lists for the parts that cannot be parameters — a column name or sort order cannot be a ?. Map the user's choice to a fixed list: {"name": "pupil", "grade": "grade"}.

🤔 Why

Because one lookup built the wrong way can hand out a whole table: grades, emails, password hashes. Injection needs no special tools — only a text box. And the fix is cheap: the same line of code, written with a placeholder. Escaping quotes by hand is not the fix. There are many ways around hand-made escaping (other quote characters, encodings, numbers with no quotes). The parameter removes the problem at its root.

🔧 How (in this repo)

grades_db() in sec/web.py makes an in-memory SQLite table with three pupils: Katrina (A+), Dipika (B+) and Aishwarya (A). unsafe_lookup(db, pupil) glues the input into the SQL text. safe_lookup(db, pupil) sends it as a parameter: db.execute("… WHERE pupil = ?", (pupil,)). injection() in sec/demo.py calls both with a normal name and with the crafted input.

🧪 Try it

python3 sec/demo.py injection
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from web import grades_db, unsafe_lookup, safe_lookup
db = grades_db()
for text in ("dipika", "x' OR '1'='1", "nobody' OR pupil LIKE '%a%", "katrina'--"):
    print(f"{text!r:<30} unsafe → {len(unsafe_lookup(db, text))} rows · safe → {len(safe_lookup(db, text))} rows")
EOF
python3 sec/test_sec.py

✅ Verify — what you should see

injection prints:

── the grade lookup asks for one pupil's grade
   normal input 'katrina'           unsafe → [('katrina', 'A+')]  ·  safe → [('katrina', 'A+')]
   crafted input "x' OR '1'='1"     unsafe → [('katrina', 'A+'), ('dipika', 'B+'), ('aishwarya', 'A')]
                                       safe   → []
   the fix is the same everywhere: send data as parameters, never glue it into the command (SQL, shell, LDAP, templates)

Your snippet prints:

'dipika'                       unsafe → 1 rows · safe → 1 rows
"x' OR '1'='1"                 unsafe → 3 rows · safe → 0 rows
"nobody' OR pupil LIKE '%a%"   unsafe → 3 rows · safe → 0 rows
"katrina'--"                   unsafe → 1 rows · safe → 0 rows

The tests end with 16/16 passed.

🏁 What you just proved

With normal input, both lookups look the same — that is why this bug survives code review and tests. With crafted input, the glued query returns all three pupils, and katrina'-- even turns the rest of the query into a comment. The parameterised query returns nothing for every crafted input: the input was only ever a name.

⚠️ Common mistakes

"we escape quotes" — hand-made escaping instead of parameters
a safe ORM everywhere, and one raw() or text() call built with an f-string
parameterising values but gluing in a column name or ORDER BY from the URL (use an allow-list)
subprocess.run(f"convert {name}.png …", shell=True) — shell injection is the same bug
trusting input because it comes from "our own" front end — anyone can send any request

🏭 In production

On a real account — the same fix in the languages you meet most. Python with PostgreSQL (psycopg) uses %s placeholders — not Python's % operator:

# ✅ the value travels separately; psycopg never pastes it into the SQL text
cur.execute("SELECT pupil, grade FROM grades WHERE pupil = %s", (pupil,))

Node.js with pg uses numbered placeholders:

const { rows } = await pool.query(
  'SELECT pupil, grade FROM grades WHERE pupil = $1', [pupil]);

Java with JDBC uses a PreparedStatement:

try (PreparedStatement ps = conn.prepareStatement(
        "SELECT pupil, grade FROM grades WHERE pupil = ?")) {
    ps.setString(1, pupil);
    try (ResultSet rs = ps.executeQuery()) { /* … */ }
}

An ORM (SQLAlchemy 2.x) builds the parameter for you — and when you need raw SQL, bind it:

from sqlalchemy import select, text
rows = session.execute(select(Grade).where(Grade.pupil == pupil)).scalars().all()
rows = session.execute(text("SELECT grade FROM grades WHERE pupil = :p"), {"p": pupil}).all()

A column the user may sort by cannot be a parameter — map it through an allow-list:

SORTABLE = {"name": "pupil", "grade": "grade"}
column = SORTABLE.get(request.args.get("sort"), "pupil")   # never the raw input

And the shell version of the same rule — a list of arguments, no shell:

subprocess.run(["convert", f"{safe_name}.png", "out.jpg"], check=True)   # no shell=True

🏭 Why this matters in production: search your code for SQL built with +, f", .format( or template strings, and for shell=True. Linters such as Bandit (Python) and Semgrep rules find most of them. Give the app's database user only the rights it needs, so a missed bug reads less.

⏭️ Next

Injection sends bad input to the server's commands. The next weakness sends it to other people's browsers: a comment on the notice board that runs as code.

git checkout lesson-02-xss-csp

← Course homeall lessons Next →xss csp

This page is the lesson's README from the lesson-01-injection branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.