un altro metodo potrebbe essere questo: dovendo estarre il record in base ai valori inviati, creo nel db un utente fittizio con id 1 (o comunque il primo in assoluto) così che anche con iniezioni di sql la query restituirebbe il primo dato estratto e cioè quell'utente, che ovviamente, non avrà alcun privilegio.
la query poi andrà modificata aggiungendo:
ORDER BY id ASC LIMIT 1
Beh, se il cracker scopre che tale utente non ha alcun diritto proverà ad aggiungere un AND id != 1 alla query iniettata...Originariamente inviato da meganoide
un altro metodo potrebbe essere questo: dovendo estarre il record in base ai valori inviati, creo nel db un utente fittizio con id 1 (o comunque il primo in assoluto) così che anche con iniezioni di sql la query restituirebbe il primo dato estratto e cioè quell'utente, che ovviamente, non avrà alcun privilegio.
con i se non si fa nulla. La prima regola e' verificare "sempre" il contenuto delle variabili, contenuto e tipo. Altrimenti lasciamo perdere il discorso sicurezza.Originariamente inviato da mark2x
Beh, se il cracker scopre che tale utente non ha alcun diritto proverà ad aggiungere un AND id != 1 alla query iniettata...
I file di sessione per esempio sono leggibili e modificabili da chiunque con un minimo di esperienza. Questa e' la prima ragione per cui viene consigliato di mettere i dati di sessione su db.
Si spendono molti soldi per la sicurezza nelle aziende... se fosse possibile solo una verifica $pippo == TRUE.... saremmo tutti piu' ricchi, (meno i sistemisti).
Il silenzio è spesso la cosa migliore. Pensa ... è gratis.
Sì ma... io ho per l'appunto risposto a meganoide dandogli torto, nel senso che creare un id fittizio non serva a nulla.
Ovvio che sono d'accordo con te.
ok son daccordo con mark2x
soprattutto x il $_request è stata una mia distrazione
ok anche nel controllare pw e login in una sola volta piu veloce
grazie x tutti i conigli ops consigli
ci aggiorniamo
Permessi di invio
Rispondi quotando