Quando si parla di malicious code si va subito a pensare alle SQL injection, tralasciando altri aspetti e particolarità che caratterizzano i siti dinamici di ultima generazione. Come è noto la querystring e le form sono le porte principali d'attacco dalle quali è possibile introdurre del codice pericoloso all'interno di un programma lato server (ad esempio script e CGI) nel tentativo di farlo eseguire con conseguenze più o meno disastrose. L'SQL injection, sia che venga introdotta da querystring, da form o tramite altri canali, quando va in porto crea un ponte tra il web server e il database. Cancellare ad esempio un database o parte di esso è un'operazione piuttosto semplice, così come prelevare dati senza lasciare traccia. Dalla SQL injection ci si difende principalmente filtrando ogni input, poichè, come avrete certo capito, questo tipo di attacco consiste nell'introdurre del "testo speciale" dai canali che sono abilitati di default in particolare via metodo GET e POST.

Dopo questa breve chiacchierata su un problema noto ormai da tempo con il quale il programmatore deve fare i conti, sarebbe bene spostare l'attenzione su altri metodi di attacco. Ecco allora che - come diceva Lubrano - la domanda sorge spontanea: in qualità di programmatori avete ancora studiato le LDAP injection e le XPath injection? Forse voi no, mentre per gli hacker quel "capitolo" è da studiare e da approfondire.

Tralasciamo volutamente LDAP, non solo per la sua complessità ma anche per fattori di diffusione, ed invece diamo una infarinatura su un injection XPath. Sarà poi vostra cura approfondire il discorso che, come per le SQL, è molto vasto.

Con XPath possiamo interagire all'interno ad esempio di XPointer e ad altre tecnologie. Tramite questo linguaggio possiamo interagire su stringhe, su numeri, possiamo accedere ai nodi dell'albero del documento XML di riferimento.
L'XPath injection è per certi versi molto simile all'SQL injection, con la differenza sostanziale che il target non sarà più il database ma piuttosto un documento XML. L'attaccante inietta una stringa di codice pericoloso all'interno di un documento XML valido cercando di ingannare il parser al fine di ottenere accesso ai dati protetti. Se il vostro sito utilizza un documento XML per archiviare dati, il quale può essere interrogato dai visitatori tramite una XPath query potreste essere soggetti ad una injection.
Anche in questo caso dovremmo validare la query, controllare quindi che l'attaccante non abbia inserito caratteri e stringhe che vadano ad esempio a chiudere una parentesi quadra con successivi OR alternati ad una serie di comandi. Infatti basta veramente poco per poter inserire malicious code in una query ad un documento XML. Anche qui dobbiamo validare gli input per stare più tranquilli, oltretutto considerate che una query XPath mal posta non genera errori.

Tra l'SQL injection e la XPath injection l'attaccante preferisce la seconda.
Voi avevate pensato di protegervi dalle XPath injections?