Avancerede SQLi- og NoSQLi-teknikker
Undersøg mere komplekse scenarier for SQL- og NoSQL-injektion, og lær avancerede defensive kodningsmønstre til effektivt at imødegå dem.
Avancerede SQLi- og NoSQLi-teknikker er en gratis Sikker kodning og OWASP Top 10 til backend-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Sikker kodning og OWASP Top 10 til backend, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Sikker kodning og OWASP Top 10 til backend-kurset indeholder 4 lektioner i alt.
Et dybere kig på SQLi
Du har lært om grundlæggende SQL-injektion (SQLi), hvor direkte brugerinput manipulerer databaseforespørgsler. Angribere bruger dog mere subtile og komplekse metoder til at omgå forsvarsmekanismer.
I denne lektion undersøger vi disse 'avancerede' SQLi-teknikker, f.eks. blinde injektioner og andenordensinjektioner, og skifter derefter fokus til sårbarheder ved NoSQL-injektion. Vigtigst af alt gennemgår vi, hvordan du effektivt beskytter dig mod dem!
Hvad er blind SQL-injektion?
Blind SQL-injektion (blind SQLi) opstår, når en applikation er sårbar over for SQLi, men dens HTTP-svar ikke direkte viser resultaterne af SQL-forespørgslen eller fejlmeddelelser.
I stedet må en angriber udlede oplysninger ved at observere applikationens adfærd eller svartider. Der findes to hovedtyper af blind SQLi:
- Boolesk-baseret blind SQLi: Angriberen observerer ændringer i sidens indhold (f.eks. at en bestemt meddelelse vises eller forsvinder) baseret på sande/falske betingelser i de injicerede udsagn.
- Tidsbaseret blind SQLi: Angriberen udleder data ved at observere forsinkelser i serverens svartid, som udløses af injicerede databasefunktioner.
Demo af tidsbaseret blind SQLi
Angribere kan bruge databasefunktioner, der forsinker udførelsen, f.eks. SLEEP() (MySQL) eller PG_SLEEP() (PostgreSQL), til at udlede data. Hvis en betingelse, de injicerer, er sand, opstår forsinkelsen; hvis den er falsk, gør den ikke.
En *sårbar* forespørgsel kan f.eks. udnyttes til at kontrollere, om det første bogstav i en adgangskode er 'a':
SELECT * FROM users WHERE username = 'admin' AND IF(SUBSTRING(password, 1, 1) = 'a', SLEEP(5), 0);En sikker tilgang bruger altid parametriserede forespørgsler og behandler alt brugerinput som data, ikke som kode. Prøv at køre det sikre eksempel:
import sqlite3
import time
def get_user_data_secure(username):
conn = sqlite3.connect(':memory:')
cursor = conn.cursor()
cursor.execute('''
CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY,
username TEXT NOT NULL,
password TEXT NOT NULL
)
''')
cursor.execute("INSERT INTO users (username, password) VALUES (?, ?)", ('admin', 'securepassword'))
conn.commit()
# Secure query using parameterized statement
query = "SELECT username FROM users WHERE username = ?"
start_time = time.time()
cursor.execute(query, (username,))
result = cursor.fetchone()
end_time = time.time()
print(f"Query for '{username}' took {end_time - start_time:.4f} seconds.")
if result:
print(f"Found user: {result[0]}")
else:
print("User not found or query failed.")
conn.close()
if __name__ == "__main__":
print("--- Secure Query Example ---")
get_user_data_secure("admin")
get_user_data_secure("nonexistent")Beskyttelse mod blind SQLi
Det bedste forsvar mod blind SQLi er det samme som mod almindelig SQLi: parametriserede forespørgsler eller forberedte udsagn. Disse metoder sikrer, at SQL-kode holdes strengt adskilt fra brugerinput.
Ved at behandle alle brugerleverede data som bogstavelige værdier bliver det umuligt for en angriber at injicere ondsindede kommandoer, uanset om outputtet er synligt eller ej.
- Validér og rens altid brugerinput grundigt.
- Brug en Web Application Firewall (WAF) til at filtrere ondsindede forespørgsler.
- Overvåg mønstre i databaseadgangen for afvigelser eller usædvanligt lange forespørgselstider.
Andenordens SQL-injektion
Andenordens SQL-injektion opstår, når ondsindet input først gemmes i en database (eller et andet permanent lager) og senere hentes og bruges i en anden forespørgsel uden korrekt rensning igen.
Denne type injektion er ofte sværere at opdage under den indledende test, fordi den første interaktion med inputtet kan virke harmløs. Sårbarheden viser sig først, når de gemte data bruges i en anden kontekst eller på et senere tidspunkt.
Tænk på det som en bombe med forsinket udløsning – lunten tændes nu, men eksplosionen sker senere!
Scenarie med andenordens SQLi
Forestil dig et scenarie, hvor en bruger registrerer sig med et brugernavn som 'admin'--. Når brugernavnet gemmes første gang, bliver det måske håndteret sikkert.
Senere henter et administratorpanel dog brugeroplysninger ved hjælp af en forespørgsel, der er opbygget ved at sammenkæde det gemte brugernavn:
SELECT email FROM users WHERE username = ' . $username_from_db . ';Hvis $username_from_db (som nu indeholder 'admin'--) ikke renses igen, før det bruges i denne anden forespørgsel, kan kommentaren (--) afkorte forespørgslen. Det kan gøre det muligt for angriberen at omgå betingelser eller afsløre følsomme data, fordi forespørgslen reelt bliver til SELECT email FROM users WHERE username = 'admin'.
Introduktion til NoSQL-injektion
NoSQL-databaser som MongoDB, Cassandra og Redis bruger ikke det traditionelle SQL-forespørgselssprog. De er dog stadig sårbare over for injektionsangreb, hvis brugerinput ikke håndteres korrekt.
Angribere manipulerer de datastrukturer (f.eks. JSON, BSON og XML), der bruges i NoSQL-forespørgsler, for at:
- Omgå godkendelse og opnå uautoriseret adgang.
- Få adgang til eller ændre uautoriserede data.
- Udføre denial-of-service-angreb ved at konstruere komplekse forespørgsler.
De specifikke teknikker afhænger i høj grad af NoSQL-databasetypen og dens særlige forespørgselssprog eller API.
Injektion af MongoDB-operatorer
En almindelig NoSQL-injektionsteknik i MongoDB går ud på at manipulere forespørgselsoperatorer. MongoDB-forespørgsler bruger ofte JSON-lignende objekter med særlige operatorer (f.eks. $eq for lig med, $gt for større end og $ne for ikke lig med).
Hvis en backend opbygger en MongoDB-forespørgsel direkte ud fra brugerinput uden validering, kan en angriber injicere disse operatorer. Hvis man f.eks. injicerer {"password": {"$ne": null}} i et adgangskodefelt, kan det omgå godkendelsen ved at matche enhver adgangskode, der ikke er null, i stedet for en bestemt adgangskode.
Det gør det muligt at finde poster, der opfylder andre betingelser end nøjagtig lighed.
Eksempel på NoSQLi (MongoDB)
Forestil dig en loginfunktion, der modtager et brugernavn og en adgangskode. Hvis adgangskoden bruges direkte i en MongoDB-forespørgsel uden rensning, kan en angriber omgå den.
Her er et *simuleret* sikkert Python-eksempel, der viser, hvordan korrekt håndtering forhindrer injektion, selv hvis en angriber forsøger at sende en konstrueret streng som '{" $ne": None}'.
def simulate_mongodb_login(username, password):
# Simulate a collection in memory
users_db = [
{"username": "admin", "password": "secure_password123"},
{"username": "guest", "password": "guestpass"}
]
print(f"Attempting login for '{username}' with password '{password}'")
# --- VULNERABLE CONCEPT ---
# If 'password' was parsed as a JSON object directly into the query:
# Attacker input: password = {"$ne": None}
# This would become: {"username": "admin", "password": {"$ne": None}}
# which means "password not equal to None" and matches any non-null password.
# --- SECURE APPROACH ---
# Always treat user input as a literal string unless explicitly parsed and validated.
# This ensures 'password' is treated as a literal string, preventing operator injection.
for user in users_db:
if user["username"] == username and user["password"] == password:
print(f"Login SUCCESS for {username} (secure). ")
return True
print(f"Login FAILED for {username} (secure).")
return False
if __name__ == "__main__":
print("--- NoSQLi Secure Login Example ---")
simulate_mongodb_login("admin", "secure_password123") # Correct password
simulate_mongodb_login("admin", "wrong_password") # Incorrect password
# Simulate attempted bypass with a crafted password string:
simulate_mongodb_login("admin", '{"$ne": None}') # Still fails due to secure handlingForebyggelse af NoSQL-injektion
Det primære forsvar mod NoSQL-injektion er grundig validering og rensning af input. Da NoSQL-databaser har forskellige forespørgselssprog, kan de konkrete forsvarsmekanismer variere, men de grundlæggende principper er de samme:
- Hvidlistning: Tillad kun kendte sikre tegn, mønstre eller bestemte datatyper. Afvis alt, der ikke passer.
- Stærk typning: Sørg for, at tal, der forventes at være tal, faktisk er tal, at strenge er strenge, og at booleske værdier er booleske.
- Driver-API'er: Brug altid NoSQL-databasens indbyggede API'er til at konstruere forespørgsler. Disse API'er er designet til at forhindre injektion ved at behandle brugerinput som data og ikke som kode.
- Undgå sammenkædning: Sammenkæd aldrig brugerinput direkte i forespørgselsstrenge eller JSON-strukturer uden korrekt escaping eller parameterisering.
- Mindst mulige privilegier: Databasebrugere bør kun have de nødvendige minimumstilladelser.
Hurtigt tjek: Injektionstyper
Test din forståelse af avancerede injektionsteknikker.
Opsummering og næste trin
Vi har gennemgået avancerede SQL- og NoSQL-injektionsteknikker, der går videre end simpel direkte manipulation:
- Blind SQLi (både tidsbaseret og boolesk) udleder data uden direkte output fra databasen.
- Andenordens SQLi indebærer lagring af skadeligt input, som udføres i en senere, separat forespørgsel.
- NoSQL-injektion retter sig mod NoSQL-forespørgselsstrukturer (f.eks. MongoDB-operatorer) for at manipulere databasehandlinger.
Det bedste forsvar er fortsat robust inputvalidering, parameteriserede forespørgsler til SQL og brug af sikre driver-API'er til NoSQL. Gå altid ud fra, at alt input er skadeligt, og valider alt!
Lær Sikker kodning og OWASP Top 10 til backend med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Avancerede SQLi- og NoSQLi-teknikker” gratis?
Ja — alle 3 lektioner i læringssporet Sikker kodning og OWASP Top 10 til backend, inklusive “Avancerede SQLi- og NoSQLi-teknikker”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Sikker kodning og OWASP Top 10 til backend-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Avancerede SQLi- og NoSQLi-teknikker”?
Undersøg mere komplekse scenarier for SQL- og NoSQL-injektion, og lær avancerede defensive kodningsmønstre til effektivt at imødegå dem. Du øver dig i Sikker kodning og OWASP Top 10 til backend med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Sikker kodning og OWASP Top 10 til backend?
Der kræves ingen tidligere erfaring. Sikker kodning og OWASP Top 10 til backend på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.
Hvor lang tid tager lektionen “Avancerede SQLi- og NoSQLi-teknikker”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Sikker kodning og OWASP Top 10 til backend-lektion?
Ja. Alle Sikker kodning og OWASP Top 10 til backend-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Avancerede SQLi- og NoSQLi-teknikker
- Omfattende strategier til inputvalidering
- Content Security Policy (CSP) til backend
- Forebyggelse af kommando- og LDAP-injektion