Il blog sull'informatica

Durante la realizzazione di un portale multiutente, ho riscontrato la necessità di ricavare l'ID dell'ultimo record inserito, in modo da salvarlo all'interno di un'altra tabella. Essendo però, come già detto, un portale multiutente, ho deciso di evitare eventuali comportamenti "imprevisti" semplicemente effettuando un LOCK/UNLOCK delle tabelle interessate. Nella fattispecie ecco il codice PHP:

$lock = $mysqli->query("LOCK TABLE cartaimbarco WRITE");

$insert = $mysqli->query("INSERT INTO cartaimbarco (DataPartenza, Prezzo) VALUES ('$datapartenza', '$prezzo')");

$idcarta = $mysqli -> insert_id;

$unlock = $mysqli->query("UNLOCK TABLES");

Per prima cosa "blocco" la tabella "cartaimbarco" in scrittura. Successivamente inserisco all'interno di tale tabella un record e ne ricavo l'ID utilizzando $mysqli -> insert_id; (come potete notare sto utilizzando il paradigma ad oggetti e non quello procedurale). L'equivalente nel paradigma procedurale di tale chiamata è la funzione mysql_insert_id().

Dopo aver ricavato l'ID del record "sblocco" le tabelle.

Ma perchè si rende necessario il LOCK/UNLOCK delle tabelle? Semplicemente perchè un altro utente potrebbe inserire un record immediatamente prima dell'istruzione $mysqli -> insert_id, la quale ci restituirà (erroneamente) l'ID del record inserito dall'altro utente (e non l'ID del record da noi inserito).

Spero di essere stato esauriente. A presto.

NB: $mysqli -> insert_id; restituirà 0 nel caso in cui L'ID non sia un campo AUTO_INCREMENT.

E' risaputo che i campi di un form disabilitati vengono ignorati dal server. Spesso, però, si verifica la necessità di dover inibire all'utente la possibilità di modificare il contenuto di un campo di input ed allo stesso tempo fare in modo che il server non lo ignori. Se il campo di input è testuale basta renderlo "readonly" (anzichè "disabled"), mentre se abbiamo a che fare con una select il discorso si fa più complesso. Una soluzione abbastanza rapida a tale problematica consiste nell'uso uno stralcio di codice Javascript, riportato nell'esempio sottostante:

<select name="clienti" class="bordotar" tabindex="1" id="clienti" onclick="old=this.selectedIndex; alert('Operazione non consentita')"  onchange="if(this.options[this.selectedIndex].className=='disable') this.selectedIndex=old"><option class="disable">Seleziona cliente</option></select>

In questo modo, ogni volta che l'utente proverà a fare una selezione, lo script riporterà il campo sull'opzione predefinita ed invierà in output l'avviso "Operazione non consentita".

A presto.

In questo post abbiamo parlato del Cross Site Scripting. Ora ci concentreremo su un altro tipo di attacco Web piuttosto diffuso, ovvero il CSRF (Cross Site Request Forgery). A differenza dell'XSS, la cui logica si basa sulla fiducia riposta dagli utenti su un determinato sito Web, il CSRF si fonda sulla fiducia di un sito Web nei confronti del browser degli utenti. Bhè, mi rendo conto che tale affermazione può risultare un pò criptica, ma lasciatemi spiegare meglio.

Supponiamo che l'utente Bob si sia autenticato sul portale on-line della propria banca, ovvero http://bank.example. Supponiamo inoltre che tale portale salvi le credenziali di accesso all'interno di un cookie e che l'expiration date (la data di scadenza) di quest'ultimo non sia proprio "imminente". Bob, dopo aver effettuato alcune operazioni sul portale sopra citato (ad esempio controllare il saldo, la lista movimenti, ecc.), continua la navigazione passando da un sito Web all'altro. Accede quindi su un forum che è solito frequentare, clicca su un 3D che ha richiamato la sua attenzione in cui è presente un tag <img> con il seguente attributo: src="http://bank.example/withdraw?account=bob&amount=10000000&for=Trudy" e, nel momento in cui il suo browser cercherà di caricare l'immagine dall'indirizzo precedentemente menzionato... boom, il danno è fatto. Da notare che la riuscita dell'attacco (e la realizzazione dello stesso), avviene in modo completamente trasparente, sarebbe a dire che la vittima non si accorgerà assolutamente di nulla.

Ma come mai un semplice tag <img> è bastato a far cadere il povero Bob nella trappola tesa da Trudy? Esaminiamo l'indirizzo http://bank.example/withdraw?account=bob&amount=100000&for=Trudy. Possiamo notare la presenza dei caratteri ? e &, classici delle querystring, attraverso le quali gli utenti inviano i dati ai server WEB sfruttando il metodo HTTP GET. Nella fattispecie, viene autorizzata una transazione dal conto dell'utente Bob per un ammontare pari a 100000 $ (o €, fate voi), verso l'utente Trudy, ovvero l'attacker, anche lui cliente della banca di Bob.

Inutile dire che gli effetti potenziali di questo attacco sono completamente imprevedibili (come già detto per l'XSS), anche se, in realtà, l'attuazione del CSRF non è così semplice come può sembrare. Infatti, affinchè tale attacco vada a buona fine, è necessario che vi siano alcune situazioni concomitanti, quali:

1) Il sito a cui punta l'URL malevolo generato dall'attaccante non deve prevedere il controllo del campo referrer presente nell'header HTTP (ovvero verificare il sito di provenienza dei visitatori);

2) L'attaccante deve individuare i giusti parametri da passare al server mediante querystring;

3) La vittima deve essere ancora loggata al sito vulnerabile nel momento in cui l'attacco viene sferrato.

La prevenzione è piuttosto semplice e si basa su alcune regole di buon senso. Ad esempio il sito deve garantire il controllo del referrer, deve consentire la sola autenticazione mediante HTTP POST e GET o, in alternativa, ridurre sensibilmente la durata dei cookie. Inoltre, sarebbe opportuno utilizzare un token (gettone) univoco e pseudocasuale per ogni richiesta HTTP POST effettuata dagli utenti.

Prossimamente analizzeremo alcune varianti del CSRF. A presto.

Esistono diversi strumenti che facilitano la vita ai programmatori/DBA. Uno su tutti è certamente PHPMyAdmin, che con la sua interfaccia user-friendly consente di effettuare modifiche sul database in maniera semplice ed intuitiva.

Spesso, però, accade che sia disponibile solo l'interfaccia a linea di comando del nostro DBMS, ragion per cui è bene ricordare alcuni comandi utili:

1) USE nomedb;

ci consente di selezionare il database.

2) SHOW TABLES;

ci consente di visualizzare tutte le tabelle relative al database selezionato;

3) DESCRIBE nometabella;

ci permette di visualizzare la struttura della tabella specificata;

Un altro comando utile riguarda il reset dei campi di auto-increment. Per fare ciò basta digitare:

ALTER TABLE nometabella AUTO_INCREMENT = 1;

Ovviemente, per visualizzare il contenuto di una tabella, per cancellare determinate righe o per modificare la struttura della tabella stessa (o di una sua entry), basta usare la pura e semplice sintassi SQL.

Ad esempio:

1) SELECT * FROM nometabella;

visualizza tutte le righe di una tabella;

2) DELETE FROM nometabella;

cancella tutti i record contenuti in una tabella;

3) DELETE FROM nometabella WHERE ID = '1';

cancella dalla tabella il record avente ID pari a 1;

4) DROP TABLE nometabella;

cancella la tabella;

5) INSERT INTO nometabella (campo1, campo2) VALUES ('valore1', 'valore2');

inserisce nella tabella i valori "valore1" e "valore2" rispettivamente per "campo1" e "campo2";

6) UPDATE nometabella SET campo1 = 'valore1', campo2 = 'valore2' WHERE ID = '1';

aggiorna il contenuto di "campo1" e "campo2" rispettivamente a "valore1" e "valore2" per la entry che possiede ID pari a 1.

Inutile dire che quelli da me elencati sono solo alcuni dei comandi che MySQL ci mette a disposizione. Morale della favola: meglio non abusare di PHPMyAdmin :D

A presto.