Per chi usa MySQL: configurate una collation :p

Agorà
1

Se usate MySQL per qualche app, vi consiglio di configurare una collation che riconosce punycode. Molte applicazioni sono vulnerabili per esempio con password reset, ed e’ molto facile fare account takeover con password reset :p

Questo trucco e’ come una cash machine :asd:

3 Likes
2

utf8mb4_* vanno bene?

3

devi specificarla tipo che sia accent sensitive e case sensitive

4

Ci ho capito una fava. Qualcuno che fa lo spiegone?

5

“I love Tesler! It’s all computer!”

2 Likes
6

C’è qualche esempio pubblico o test per verificare se si è impattati o basta usare

O simili?

7

Trovato questo articolo

Che spiega alcune casistiche e possibili utilizzi

8

Punycode and security, name a worse duo

1 Like
9

Yep!

L’importante e’ che quella che usi supporta tutti i caratteri Unicode, incluso il full range di code points necessario per pjunycode che lo standard utf8 non supporta. utf8mb4 oppure utf8mb4_0900_bin per binary-safe storage e confronto, oppure utf8mb4_0900_ai_ci per access insensitive, case insensitive.

MySQL, con la default uft8 collation non distingue tra caratteri normali e varianti punycode. Per esempio, la lettera punycode ḻ viene misinterpretata come la normale lettera l, e questo non va bene per la sicurezza. Per esempio supponiamo che un utente si sia registrato con l’indirizzo email [email protected]. Un attacker potrebbe provare a fare il password reset con l’indirizzo vittima@bḻah.com. Se

  1. MySQL ha una normale utf8 collation
  2. Il backend fa un lookup per vedere se l’account con la email normale esiste
  3. Ma usa l’email passata come parametro per inviare l’email
    Il risultato e’ che la email con il link per il password reset (che include un token) viene inviato all’attacker invece che alla vittima. L’attacker puo’ dunque fare password reset e entrare nell’account della vittima.

Per fare questo l’attacker deve semplicemente registrare versioni punycode di domini che altri utenti usano. Per esempio io ho varie varianti di gmail.com, outlook.com, icloud.com e altri.

Una verifica veloce direttamente in MySQL:

select 'ȃ' = 'a';

Se il risultato e’ 1, allora e’ probabile che sei vulnerabile a seconda di come il backend e’ implementato.

5 Likes
10

minchia, bella fogna. Cosa può fare la vittima per difendersi?

11

Io non ho ben capito l’esempio… Il bug non vale solo per i domini IDN con lettere non Ascii? :mumble:

EDIT. Ah ok si capito adesso, è per il vicerversa ‘a’ = ‘ȃ’;

12

ma in teoria chi sviluppa l’app e il frontend dei check di “sanificazioni” o normalizzare/canonizzare dei dati in input che un utente può mettere va fatto, tra l’altro cmq per le versioni recenti di MySQL non dovrebbe esserci questo problema, c’è in quelle più vecchiotte… in quel caso sei stronzo che non aggiorni sta cosa dal 2018 minimo.

13

anche se usi mysql aggiornato e relativi collation potresti esser vittima se il backend non è fatto bene, es. invece di usare la mail che trova nel db poi usa quella passata dall’utente per spedire la mail.

14

Wordpress presumo sia al sicuro?

15

con wordpress tra l’altro devi mettere un append alfanumerico casuale al posto del wp_ davanti al nome delle tabelle se no ti bucano il db di wordpress il giorno dopo :asd: in fase di build del db iniziale

16

La vittima non puo’ fare nulla per questo. Sono le persone che gestiscono il database che devono correggere la configurazione.

Non ne sono sicuro, non tocco WP da molti anni

17

Non credo proprio, ma ok :asd:

18

eh invece si :asd: SQL injection

tra l’altro nel file config hai poi dove dichiarare quel codice al posto del wp_

19

Non lo so, fatto quotidiano e forbes italia stanno con wp_ e ancora successo niente per il momento :asd:

1 Like
20

auguri :sisi:

cmq al limite fai alter table sul db delle tabelle wp_ rinomini, metti quello nelle config di wp e bella.

1200 euro per la consulenza :sisi:

1 Like