Vulnerabilities

Cos'è l'SQL Injection (SQLi)?

L'SQL Injection (SQLi) è un tipo di attacco in cui gli aggressori inseriscono istruzioni SQL dannose in un campo di input per manipolare il database.

Cos’è l’Iniezione SQL (SQLi)?

L’Iniezione SQL (SQLi) è un tipo di attacco in cui gli aggressori inseriscono istruzioni SQL dannose nel campo di input per manipolare il database.

Questo attacco prende di mira applicazioni che non gestiscono correttamente la validazione, l’input dell’utente, permettendo l’accesso non autorizzato a dati sensibili come password o dettagli della carta di credito, ecc.

Come Funziona l’Iniezione SQL

Quando un’applicazione include direttamente l’input dell’utente in una query di database senza una corretta validazione, gli aggressori possono modificare il comportamento della query per inserire un’istruzione SQL dannosa.

Per esempio:

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

Un aggressore potrebbe inserire:

' OR '1'='1

Risultando in:

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

Questo restituisce sempre vero, concedendo accesso non autorizzato.

Perché l’Iniezione SQL è Importante nella Sicurezza Informatica

L’Iniezione SQL è la tecnica più pericolosa e antica nella sicurezza informatica. Questo tipo di attacco è costantemente elencato nella Top 10 di OWASP.

Anche piccole vulnerabilità permettono a un aggressore di:

  • Accedere, modificare o eliminare dati
  • Bypassare l’autenticazione
  • Eseguire operazioni amministrative sul database.
  • Compromettere l’intero sistema.

Tipi Comuni di SQL Injection

  • SQLi Classico: Iniezione diretta tramite moduli web o parametri URL.
  • SQLi Cieco: Gli attaccanti deducono indirettamente informazioni dal database (ad es., tramite messaggi di errore o tempo di risposta).
  • SQLi Basato su Union: Utilizza l’operatore UNION per combinare risultati da più query.
  • SQLi Basato su Errori: Si basa su messaggi di errore del database per estrarre informazioni.
  • SQLi Cieco Basato sul Tempo: Sfrutta i ritardi di risposta del server per indovinare i risultati delle query.

Come Prevenire SQL Injection

1. Usare Query Parametrizzate (Prepared Statements)

Assicurarsi che i comandi SQL trattino l’input dell’utente come dati, non come codice eseguibile.

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

2. Validazione e Sanitizzazione dell’Input

Validare tutti gli input degli utenti, permettendo solo i caratteri previsti.

3. Usare Framework ORM

Framework come Prisma, Hibernate, ecc., riducono la gestione diretta di SQL.

4. Principio del Minimo Privilegio

Limitare i permessi degli utenti, concedendo solo i permessi necessari.

5. Test di Sicurezza Regolari

Usa strumenti di test di sicurezza delle applicazioni come SAST, DAST o IAST per rilevare i difetti di iniezione precocemente.

Esempio nel Mondo Reale

Un sito web di un negozio online ha subito una violazione in cui gli attaccanti hanno utilizzato un’iniezione SQL in un modulo di login per estrarre i dettagli delle carte di credito dal suo database.

Termini Correlati

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)