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

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

🛡️ धडा 13 — Security: कुलूपबंद नोंदवही

📍 तुम्ही इथे आहात: 18 पैकी धडा 13 · मागील: lesson-12-performance-ops · पुढील: lesson-14-advanced-sql

भाग 3 — अधिक खोलात. धडे 01–12 नी रेकॉर्ड रूम बांधली आणि चालवली. धडे 13–18 हे interviews आणि incidents मध्ये विचारले जाणारे विषय आहेत — प्रत्येक त्याच school.db वर प्रत्यक्ष चालतो.

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

धडे 01–13, आणि db/demo.py मधले inject(): टाइप केलेला roll number थेट SQL मध्ये चिकटवणारा login, तोच login parameter सह, आणि DELETE नाकारला जाणारे read-only connection.

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

अभिलेखपाल तुमची चिठ्ठी मोठ्याने वाचते आणि त्यात जे लिहिले आहे तेच करते. चिठ्ठीवर "roll number 3A-02 शोधा" असेल, तर तुम्हाला कतरिना मिळते. पण कोणी रिकाम्या जागेत स्वतःचे शब्द लिहिले तर — "roll number x' OR '1'='1 शोधा"? मोठ्याने वाचल्यावर चिठ्ठी आता म्हणते "roll number x शोधा, किंवा जिथे 1 बरोबर 1 आहे ते सगळे" — आणि 1 नेहमीच 1 बरोबर असतो. अभिलेखपाल प्रत्येक विद्यार्थिनी देऊन टाकते. हेच SQL injection.

उपाय म्हणजे रिकाम्या जागी बंद लिफाफा (?) असलेली चिठ्ठी. लिफाफ्यात जे असेल ते नेहमी फक्त शोधायची एक value असते — अभिलेखपाल पाळते असे शब्द कधीच नाहीत.

आणि प्रत्येक कारकुनाला प्रत्येक किल्ली मिळत नाही: reports कारकुनाला फक्त-वाचण्याचा pass मिळतो.

🗺️ आकृती

flowchart LR
    typed["⌨️ typed: x' OR '1'='1"]
    glued["❌ glued: WHERE roll_no = 'x' OR '1'='1'"]
    param["✅ parameter: WHERE roll_no = ?  +  value"]
    leak["💥 all 5 pupils"]
    none["(no rows)"]
    typed --> glued --> leak
    typed --> param --> none

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

❓ काय

SQL injection — user चे input SQL text चा भाग बनते, त्यामुळे input प्रश्नच बदलू शकते. ते सगळे वाचू शकते, login टाळू शकते, किंवा (इतर drivers सह) DROP TABLE चालवू शकते.
Parameters (?, %s, :name, $1) — SQL आणि values वेगवेगळे जातात; value कधीच SQL म्हणून parse होत नाही. प्रत्येक driver आणि ORM मध्ये ते असतात.
Least privilege — प्रत्येक app फक्त गरजेचे तेवढेच असलेल्या role म्हणून connect होते: GRANT SELECT ON grades TO reports; (Postgres/MySQL). SQLite मध्ये users नाहीत; सर्वात जवळची गोष्ट म्हणजे file read-only उघडणे (mode=ro).
Encryption — transit मध्ये (TLS: Postgres मध्ये sslmode=require) आणि at rest (disk किंवा managed service, उदा. RDS). Passwords secret store किंवा environment मधून येतात, कधीच git मधून नाही.

🤔 का

कारण जो connect झाला आहे त्याच्यावर database विश्वास ठेवतो. दोन दशकांपासून injection हा सर्वात सामान्य web हल्ल्यांपैकी एक आहे, आणि तो एका सवयीने पूर्णपणे थांबतो: strings चिकटवून कधीच SQL बनवू नका. Least privilege इतर प्रत्येक चुकीचे नुकसान मर्यादित ठेवते.

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

db/demo.py मधले inject() database ला प्रत्यक्ष मिळालेली चिकटवलेली query छापते, ती चालवते (प्रत्येक विद्यार्थिनी परत येते), parameter असलेली आवृत्ती चालवते (एकही row नाही), मग school.db read-only उघडून DELETE FROM grades करून पाहते.

🧪 करून पाहा

python3 db/demo.py inject
python3 - <<'EOF'
import sqlite3
c = sqlite3.connect("db/school.db")
for typed in ["3A-02", "x' OR '1'='1", "3A-02'; --"]:
    print(repr(typed), "→", c.execute("SELECT name FROM students WHERE roll_no = ?", (typed,)).fetchall())
EOF

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

चिकटवलेली query WHERE roll_no = 'x' OR '1'='1' छापते आणि पाचही नावे परत देते; parameter (no rows) देतो; read-only connection attempt to write a readonly database म्हणते. Snippet मध्ये फक्त 3A-02 ला कतरिना सापडते.

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

तुम्ही injection चालताना दाखवू शकता, ते का होते हे समजावू शकता, आणि parameter ने ते बंद करू शकता — आणि app ला असा pass देऊ शकता जो काहीच लिहू शकत नाही.

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

parameters वापरण्याऐवजी quotes हाताने escape करणे
"फक्त या एका internal tool साठी" SQL बनवायला f-strings किंवा +
user input मधून table किंवा column ची नावे — parameters मध्ये नावे बसत नाहीत; allow-list वापरा
app database owner किंवा superuser म्हणून connect होणे
repo मध्ये, logs मध्ये, किंवा git मध्ये commit केलेल्या connection string मध्ये passwords

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: security reviews नेमके हेच तपासतात: string ने बनवलेला SQL नाही, app / migrations / reports साठी वेगळे roles, TLS आवश्यक, at rest encryption, vault मधून secrets, आणि superuser च्या logins वर alert.

⏭️ पुढे

git checkout lesson-14-advanced-sql — एकही row न गमावता rankings आणि reports.

🛡️ Lesson 13 — Security: the locked register

📍 You are here: Lesson 13 of 18 · Previous: lesson-12-performance-ops · Next: lesson-14-advanced-sql

Part 3 — going deeper. Lessons 01–12 built and ran the record room. Lessons 13–18 are the topics interviews and incidents ask about — each one runs for real on the same school.db.

📦 What's in this branch

Lessons 01–13, plus inject() in db/demo.py: a login that glues the typed roll number into SQL, the same login with a parameter, and a read-only connection that is refused a DELETE.

🧒 Explain like I'm 5

The archivist reads your slip out loud and does exactly what it says. If the slip is "find roll number 3A-02", you get Katrina. But what if someone writes their own words into the blank — "find roll number x' OR '1'='1"? Read out loud, the slip now says "find roll number x, or anything where 1 equals 1" — and 1 always equals 1. The archivist hands over every pupil. That is SQL injection.

The fix is a slip with a sealed envelope in the blank (?). Whatever is inside the envelope is only ever a value to look up — never words the archivist obeys.

And not every clerk gets every key: the reports clerk gets a read-only pass.

🗺️ Diagram

flowchart LR
    typed["⌨️ typed: x' OR '1'='1"]
    glued["❌ glued: WHERE roll_no = 'x' OR '1'='1'"]
    param["✅ parameter: WHERE roll_no = ?  +  value"]
    leak["💥 all 5 pupils"]
    none["(no rows)"]
    typed --> glued --> leak
    typed --> param --> none

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

❓ What

SQL injection — user input becomes part of the SQL text, so the input can change the question. It can read everything, bypass a login, or (with other drivers) run DROP TABLE.
Parameters (?, %s, :name, $1) — the SQL and the values travel separately; the value is never parsed as SQL. Every driver and ORM has them.
Least privilege — each app connects as a role with only what it needs: GRANT SELECT ON grades TO reports; (Postgres/MySQL). SQLite has no users; the closest thing is opening the file read-only (mode=ro).
Encryption — in transit (TLS: sslmode=require in Postgres) and at rest (the disk or the managed service, e.g. RDS). Passwords come from a secret store or environment, never from git.

🤔 Why

Because the database trusts whoever is connected. Injection has been one of the most common web attacks for two decades, and it is fixed completely by one habit: never build SQL by gluing strings. Least privilege limits the damage of every other mistake.

🔧 How (in this repo)

inject() in db/demo.py prints the glued query the database actually received, runs it (every pupil comes back), runs the parameterised version (no rows), then opens school.db read-only and tries DELETE FROM grades.

🧪 Try it

python3 db/demo.py inject
python3 - <<'EOF'
import sqlite3
c = sqlite3.connect("db/school.db")
for typed in ["3A-02", "x' OR '1'='1", "3A-02'; --"]:
    print(repr(typed), "→", c.execute("SELECT name FROM students WHERE roll_no = ?", (typed,)).fetchall())
EOF

✅ Verify — what you should see

The glued query prints WHERE roll_no = 'x' OR '1'='1' and returns all five names; the parameter returns (no rows); the read-only connection says attempt to write a readonly database. In the snippet, only 3A-02 finds Katrina.

🏁 What you just proved

You can show an injection working, explain why, and close it with a parameter — and you can give an app a pass that cannot write at all.

⚠️ Common mistakes

escaping quotes by hand instead of using parameters
f-strings or + to build SQL "just for this one internal tool"
table or column names from user input — parameters cannot hold names; use an allow-list
the app connecting as the database owner or superuser
passwords in the repo, in logs, or in the connection string committed to git

🏭 Why this matters in production: security reviews check exactly this: no string-built SQL, separate roles for app / migrations / reports, TLS required, encryption at rest, secrets from a vault, and an alert on logins by the superuser.

⏭️ Next

git checkout lesson-14-advanced-sql — rankings and reports without losing a row.

← Previousperformance ops Next →advanced sql

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