Vulnerabilities

Mikä on SQL-injektio (SQLi)?

SQL-injektio (SQLi) on hyökkäystyyppi, jossa hyökkääjät syöttävät haitallisia SQL-lauseita syöttökenttään manipuloidakseen tietokantaa.

Mikä on SQL-injektio (SQLi)?

SQL-injektio (SQLi) on hyökkäystyyppi, jossa hyökkääjät syöttävät haitallisen SQL-lauseen syöttökenttään manipuloidakseen tietokantaa.

Tämä hyökkäys kohdistuu sovelluksiin, jotka eivät käsittele asianmukaisesti validointia tai käyttäjän syötettä, mahdollistaen luvattoman pääsyn arkaluontoisiin tietoihin, kuten salasanoihin tai luottokorttitietoihin jne.

Kuinka SQL-injektio toimii

Kun sovellus sisällyttää käyttäjän syötteen suoraan tietokantakyselyyn ilman asianmukaista validointia, hyökkääjät voivat muokata kyselyn toimintaa syöttämällä haitallisen SQL-lauseen.

Esimerkiksi:

SELECT * FROM users WHERE username = 'admin' AND password = '12345';

Hyökkääjä voisi syöttää:

' OR '1'='1

Johtaen seuraavaan:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

Tämä palauttaa aina totta, mahdollistaen luvattoman pääsyn.

Miksi SQL-injektio on tärkeä kyberturvallisuudessa

SQL-injektio on vaarallisin ja vanhin tekniikka kyberturvallisuudessa. Tämä hyökkäystyyppi on jatkuvasti listattu OWASP Top 10

.

Jopa pienet haavoittuvuudet mahdollistavat hyökkääjän:

  • Pääsy, muokkaus tai poistaminen dataa
  • Autentikoinnin ohittaminen
  • Hallinnollisten toimintojen suorittaminen tietokannassa.
  • Järjestelmän kokonaisvaltainen vaarantaminen.

Yleiset SQL-injektiotyypit

  • Klassinen SQLi : Suora injektio verkkolomakkeiden tai URL-parametrien kautta.
  • Sokea SQLi : Hyökkääjät päättelevät tietokannan tietoja epäsuorasti (esim. virheilmoitusten tai vasteajan kautta).
  • Union-pohjainen SQLi : Käyttää UNION-operaattoria yhdistääkseen tulokset useista kyselyistä.
  • Virhepohjainen SQLi : Perustuu tietokannan virheilmoituksiin tiedon keräämiseksi.
  • Aikapohjainen sokea SQLi : Hyödyntää palvelimen vasteviiveitä arvaten kyselyn tuloksia.

Kuinka estää SQL-injektio

1. Käytä parametrisoituja kyselyitä (valmistellut lauseet)

Varmista, että SQL-komennot käsittelevät käyttäjän syötteenä dataa, ei suoritettavaa koodia.

cursor.execute("SELECT * FROM users WHERE username = ?", (username,))

2. Syötteen validointi ja puhdistus

Validoi kaikki käyttäjiltä tuleva syöte, sallien vain odotetut merkit.

3. Käytä ORM-kehyksiä

Kehykset kuten Prisma, Hibernate jne. vähentävät suoraa SQL-käsittelyä.

4. Vähimmäisoikeusperiaate

Rajoita käyttäjän oikeuksia, anna vain tarvittavat oikeudet.

5. Säännöllinen turvallisuustestaus

Käytä sovellusten tietoturvatestaustyökaluja, kuten SAST, DAST tai IAST, havaitaksesi injektiovirheet varhaisessa vaiheessa.

Esimerkki tosielämästä

Verkkokauppasivusto kärsi tietomurrosta, jossa hyökkääjät käyttivät SQL-injektiota kirjautumislomakkeessa saadakseen luottokorttitietoja tietokannasta.

Liittyvät termit

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)