Vulnerabilities

Co to jest SQL Injection (SQLi)?

SQL Injection (SQLi) to rodzaj ataku, w którym atakujący wprowadza złośliwe polecenie SQL do pola wejściowego, aby manipulować bazą danych.

Czym jest SQL Injection (SQLi)?

SQL Injection (SQLi) to rodzaj ataku, w którym atakujący wprowadza złośliwe polecenie SQL do pola wejściowego, aby manipulować bazą danych.

Ten atak jest skierowany na aplikacje, które nieprawidłowo obsługują walidację i dane wejściowe użytkownika, co pozwala na nieautoryzowany dostęp do wrażliwych danych, takich jak hasła czy dane kart kredytowych.

Jak działa SQL Injection

Gdy aplikacja bezpośrednio uwzględnia dane wejściowe użytkownika w zapytaniu do bazy danych bez odpowiedniej walidacji, atakujący mogą zmodyfikować zachowanie zapytania, wprowadzając złośliwe polecenie SQL.

Na przykład:

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

Atakujący mógłby wprowadzić:

' OR '1'='1

Co skutkuje:

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

To zawsze zwraca prawda, umożliwiając nieautoryzowany dostęp.

Dlaczego SQL Injection ma znaczenie w cyberbezpieczeństwie

SQL Injection jest najniebezpieczniejszą i najstarszą techniką w cyberbezpieczeństwie. Ten rodzaj ataku jest konsekwentnie wymieniany w OWASP Top 10.

Nawet małe podatności pozwalają atakującemu na:

  • Dostęp, modyfikacja lub usuwanie danych
  • Omijanie uwierzytelniania
  • Wykonywanie operacji administracyjnych na bazie danych.
  • Kompromitacja całego systemu.

Typowe rodzaje ataków SQL Injection

  • Klasyczny SQLi: Bezpośrednia iniekcja przez formularze internetowe lub parametry URL.
  • Blind SQLi: Atakujący pośrednio wnioskują o informacjach z bazy danych (np. poprzez komunikaty o błędach lub czas odpowiedzi).
  • Union-based SQLi: Wykorzystuje operator UNION do łączenia wyników z wielu zapytań.
  • Error-based SQLi: Polega na komunikatach o błędach bazy danych do wyciągania informacji.
  • Time-based Blind SQLi: Wykorzystuje opóźnienia w odpowiedzi serwera do zgadywania wyników zapytań.

Jak zapobiegać atakom SQL Injection

1. Używaj zapytań parametryzowanych (przygotowanych instrukcji)

Zapewnij, że polecenia SQL traktują dane wejściowe użytkownika jako dane, a nie kod wykonywalny.

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

2. Walidacja i sanitacja danych wejściowych

Waliduj wszystkie dane wejściowe od użytkowników, pozwalając tylko na oczekiwane znaki.

3. Używaj frameworków ORM

Frameworki takie jak Prisma, Hibernate itp. redukują bezpośrednią obsługę SQL.

4. Zasada najmniejszych uprawnień

Ograniczaj uprawnienia użytkowników, przyznając tylko te, które są potrzebne.

5. Regularne testy bezpieczeństwa

Używaj narzędzi do testowania bezpieczeństwa aplikacji, takich jak SAST, DAST lub IAST, aby wcześnie wykrywać wady związane z iniekcją.

Przykład w rzeczywistym świecie

Strona internetowa sklepu online doświadczyła naruszenia bezpieczeństwa, gdzie atakujący użyli iniekcji SQL w formularzu logowania, aby wyciągnąć dane kart kredytowych z bazy danych.

Powiązane terminy

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)