SQL Injection | Maritime Cyber Learning

📚 Series Maritime Cybersecurity Learning Roadmap | PART 2 Lesson 10 of 7 · Course Index →

PART 2 · Lesson 10 Injection SQLi · Web App

SQL Injection

In-band SQLi · Blind SQLi · Union-based Extraction · Error-based · Parameterised Queries · Input Validation · ORM · WAF — one of the longest-lived and most consistently exploited vulnerability classes in web applications.

Captain Paul

Maritime Cybersecurity · IACS UR E26/E27

September 2026

🎯 Lesson Objective

After this lesson you can explain what SQL Injection is and why it occurs, describe the main SQLi variants (in-band, blind, out-of-band), demonstrate conceptually how a Union-based injection extracts data, explain why parameterised queries are the definitive fix, describe supporting controls (input validation, ORM, WAF), and identify which maritime web applications present the highest SQLi risk.

SQL Injection first appeared as a documented vulnerability in 1998 and has remained on the OWASP Top 10 list — the canonical ranking of the most critical web application security risks — virtually every year since the list was created in 2003. Despite being thoroughly understood and trivially preventable, SQLi continues to power major data breaches. Its persistence is a function of developer unfamiliarity, deadline pressure, and legacy code that has never been modernised.

The attack exploits a single fundamental mistake: treating user-supplied input as part of an SQL command rather than as data. When an application constructs a database query by concatenating a user's input directly into the query string, an attacker can inject SQL syntax that changes the logic of the query, extracts data the attacker should not see, modifies records, or even drops tables entirely.

Maritime applications relevant to SQLi include Fleet Management Systems (FMS), Port Management Information Systems (PMIS), crew management portals, vessel tracking dashboards, and the administrative backends of any web-based tool that stores voyage or compliance data in a relational database. A successful SQLi attack against a fleet database could expose crew personal data, voyage history, cargo manifests, and access credentials.

1. Why SQL Injection Happens — The Root Cause

Consider a login form. When a user enters their username admin and password mypassword, a vulnerable application might build the database query by string concatenation:

VULNERABLE — string concatenation

query = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"

RESULT WITH NORMAL INPUT

SELECT * FROM users WHERE username='admin' AND password='mypassword'

ATTACKER INPUT: username = admin'--

SELECT * FROM users WHERE username='admin'--' AND password='anything'

→ The -- comments out the rest. Authentication is bypassed entirely. The attacker logs in as admin.

The single quote ' closes the string in the SQL syntax. The double-dash -- begins an SQL comment that makes the database engine ignore everything that follows. The attacker's input changed the query's logic.

2. SQLi Variants — What Attackers Can Do

SQL Injection Types

In-band — Error-based	The database returns error messages that reveal schema details — table names, column names, data types. The attacker crafts inputs that trigger informative errors and reads the database structure from the responses.
In-band — Union-based	SQL's UNION operator combines results from multiple SELECT statements. An attacker appends a crafted UNION SELECT to retrieve data from other tables — credentials, email addresses, private records — which appear alongside the normal query results in the application's response.
Blind — Boolean-based	The application shows no data in its response but behaves differently based on whether a condition is true or false (e.g. displays a result versus a blank page). The attacker asks true/false questions and reads data one bit at a time from the behavioural difference. Slow but functional when no errors or data are returned.
Blind — Time-based	The attacker injects SQL that causes the database to delay its response (e.g. SLEEP(5) in MySQL) if a condition is true. By measuring response time, data is extracted without any application-level feedback. No errors, no data — just timing.
Out-of-band	Data is exfiltrated through an out-of-band channel (DNS or HTTP callbacks) rather than the main application response. Less common; requires the database server to have outbound network access. Used when blind techniques are too slow.

3. Defences — How to Prevent SQL Injection

Defence Layers — Priority Order

🔒 1. Parameterised Queries (Prepared Statements) — Primary Defence

Parameterised queries separate SQL code from data. The query template is sent to the database engine first, and user input is passed as parameters that are treated purely as data — never interpreted as SQL syntax. A single quote in a parameterised query is stored as a literal character, not as a string delimiter that changes query logic.

SECURE — Parameterised Query (Python/psycopg2 example)

cursor.execute(
  "SELECT * FROM users WHERE username=%s AND password=%s",
  (username, password)
)

No matter what the user enters, the database never treats it as SQL syntax. This eliminates SQLi completely at the query level.

🛡️ 2. ORM (Object-Relational Mapping)

ORMs (SQLAlchemy, Hibernate, ActiveRecord, Django ORM) generate parameterised queries by default, removing the need to write raw SQL. Applications built on mature ORMs are largely protected from SQLi as long as developers do not bypass the ORM to write raw query strings.

🔍 3. Input Validation (Defense-in-Depth)

Validate that input conforms to expected type, length, and character set before passing it to any database query. A vessel IMO number field should accept only 7-digit integers; a username field should accept only alphanumeric characters. Reject input that fails validation. This is not a substitute for parameterised queries but reduces the attack surface.

🌐 4. WAF (Web Application Firewall)

A WAF inspects HTTP requests and blocks patterns matching known SQLi signatures (UNION SELECT, OR 1=1, SLEEP(), etc.). WAFs reduce noise from automated SQLi scanning tools and provide a detection and blocking layer. They should not be considered a substitute for secure code — an attacker with application knowledge can often craft bypass payloads that evade WAF signatures.

4. Maritime Context — Which Applications Are at Risk?

Maritime Applications — SQLi Risk Profile

Application	Risk Level	Data at Risk
Fleet Management Systems	HIGH	Crew PII, voyage records, maintenance logs, certification data
Port Management Information Systems	HIGH	Cargo manifests, berth scheduling, vessel call data
Crew Management Portals	HIGH	Passport/STCW data, contracts, payroll records, contact details
Vessel Tracking / AIS Web Portals	MEDIUM	Position history, route data (potential cargo intelligence)
Compliance Reporting Portals	MEDIUM	MARPOL/ISM inspection records, audit findings, non-conformities

✍️ Author Insight — From the Field

Captain Paul · Maritime Cybersecurity Consultant · IACS UR E26/E27

During E26 CRSI assessments, web application security is frequently the weakest layer. Fleet management and crew management portals are often developed by specialised maritime software vendors or in-house teams whose primary expertise is operational, not cybersecurity. SQL Injection vulnerabilities in login forms, search functions, and filter parameters are not uncommon findings.

The impact in a maritime context can extend well beyond the database itself. Crew records in a compromised fleet database expose STCW certification details, home addresses, next of kin contacts, and passport numbers — a significant data protection liability. Worse, credentials extracted from the database can provide access to other systems if password reuse is present — which, in the absence of a password management policy, it very often is.

Practical assessment note: Testing for SQLi does not require sophisticated tooling. A single quotation mark entered in a search field or URL parameter that produces a database error message is sufficient evidence of vulnerability. All web-facing application inputs should be reviewed for injection risk, and vendor-supplied applications should be assessed or their security assurances documented before deployment.

✅ Key Takeaways — Lesson 10

• SQL Injection occurs when user input is concatenated into SQL queries, allowing attackers to change query logic.
• In-band SQLi (error-based, union-based) extracts data directly through the application response; blind SQLi infers data from application behaviour or timing.
• Parameterised queries (prepared statements) are the primary, definitive defence — they separate code from data at the database protocol level.
• ORMs provide parameterised queries by default; WAFs and input validation are additional layers, not substitutes for secure code.
• Maritime fleet management, port management, and crew management systems are high-value SQLi targets with significant data protection consequences.
• A single quote in an input field producing a database error is a red flag requiring immediate remediation.

▶ Next — Lesson 11

Lesson 11 — Cross-Site Scripting (XSS) examines another injection vulnerability class — but targeting the user's browser rather than the server's database. We explore Reflected, Stored, and DOM-based XSS, how malicious scripts steal cookies and credentials, and the Content Security Policy (CSP) controls that prevent script execution.

📚 PART 2 — Understanding Cyber Attacks

DoneLesson 6 — Phishing & Social Engineering

DoneLesson 7 — Ransomware & the Cyber Kill Chain

DoneLesson 8 — DoS and DDoS Attacks

DoneLesson 9 — Man-in-the-Middle (MitM) Attacks

Current Lesson 10 — SQL Injection

NextLesson 11 — Cross-Site Scripting (XSS)

ComingLesson 12 — DNS Spoofing & DNS-based Attacks

← View Full Course Index

⚓ Join the ShipPaulJobs Community

Join →