SQL injection

Torej.. prišel sem do odgovorov da je za sql varnost potrebno uporabljati addslashes() in mysql_escape_string().

Katere so še druge stvari s katerimi lahko zaščitiš napade na sql?

A PHP ne pozna Prepared statementov?

Napadi so lahko tudi brez sql injectiona. Drugače pa ti ni treba uporabljati mysql_escape_string() ampak lahko typecastas vhodno spremenljivko v int, če veš da more biti vnos tipa int (tako kot je Zvonko rekel).

Primer napada brez sql injectiona je naprimer spreminjanje posta v forumu. Pri slabi kodi se ti lahko pojavi prijavljen uporabnik, ki sporoči id posta od drugega uporabnika in spremeni drugemu uporabniku post. Rešitev je čisto enostavno in je "UPDATE ..... WHERE id=$POST['id'] AND Owner=$UserId". Napačna koda pri update sql stavku nima "AND Owner=$UserId".

Malo se poglobi v logične stvari programa in preveri če imaš znotraj sql stavkov v pogoju vse kar je tebi na prvi pogled logično in mora vedno biti.

ADOdb in pear::db lepo poskrbita da so sql stavki ustrezno urejeni ("prepared").

MS SQL server pozna storedProcedures, za mySQL pa ne vem... tam pa ne more prit do SQL injection!

CCFly z MS orodji gre nekako takole :

With sqlCommand

.Connection = sqlConnection
.CommandType = CommandType.StoredProcedure
.CommandText = "spNekaj"

End With

With sqlCommand.Parameters

.Add("@RowGuid", SqlDbType.UniqueIdentifier).Value = newMessage.Guid
.Add("@ParentGuid", SqlDbType.UniqueIdentifier).Value = newMessage.ParentGuid
.Add("@ComposerGuid", SqlDbType.UniqueIdentifier).Value = newMessage.Composer.Guid
.Add("@Requests", SqlDbType.TinyInt).Value = newMessage.Requests

End With

Zdaj pa mi povej kje lahko tu pride do SQL injection !!!

Seveda, takoj ko mi ti najdeš napako v mojem umotvoru:
echo "AndrejS bo še enkrat prebral sporočilo enega od kolegov v debati, kjer sodeluje, in ne bo dodajal nepotrebnih klicajev v svoja sporočila."

SQL injection je pri uporabi stored procedur možen že ko v tej npr. stakneš skupaj dva niza (recimo kakšna implementacija iskanja). Nisem rekel, da se je zato potrebno izogibati stored procedur ali da so te slaba izbira, trdim pa da možnost zlorabe obstaja. Zaradi tega ne vidim razloga, da ne bi ustezno preverili podatkov, še preden izvršiš poizvedbo, že na aplikacijskem nivoju.