Tack för den intressanta frågan. Varsågod:
Den undkommer farliga karaktärer,
Ditt koncept är helt fel.
Faktum är att "farliga karaktärer" är en myt, det finns inga. Och mysql_real_escape_string som undkommer utan bara en strängavgränsare . Från denna definition kan du dra slutsatsen att dess begränsningar - den fungerar bara för strängar .
det är dock fortfarande sårbart för andra attacker som kan innehålla säkra tecken men kan vara skadligt för att antingen visa data eller i vissa fall modifiera eller radera data på ett skadligt sätt.
Du blandar allt här.
Apropå databas,
- för strängarna är det INTE sårbart. Så länge dina strängar citeras och flyktar, kan de inte "ändra eller ta bort data med skadlig uppsåt".
* - för andra datatypdata - ja, det är onyttigt . Men inte för att det är något "osäkert" utan bara på grund av felaktig användning.
När det gäller visningsdata antar jag att det är offtopic i den PDO-relaterade frågan, eftersom PDO inte heller har något att göra med att visa data.
escapeing user input
^^^ Ännu en villfarelse att notera!
-
en användarinmatning har absolut ingenting att göra med att fly . Som du kan lära dig av den tidigare definitionen måste du undkomma strängar, inte vad som helst "användarinmatning". Så, igen:
- du har escape-strängar, oavsett källa
- det är värdelöst att undkomma andra typer av data, oavsett källa.
Förstår du poängen?
Nu hoppas jag att du förstår begränsningarna med att fly liksom missuppfattningen av "farliga karaktärer".
Det är enligt min uppfattning att det är mycket säkrare att använda PDO/förberedda uttalanden
Inte riktigt.
Det finns faktiskt fyra olika frågedelar som vi kan lägga till dynamiskt:
- en sträng
- ett nummer
- en identifierare
- ett syntaxsökord.
så du kan se att escape endast täcker ett problem. (men självklart, om du behandlar siffror som strängar (sätter dem inom citattecken), när det är tillämpligt , du kan också göra dem säkra)
medan förberedda uttalanden täcker - usch - hela 2 frågor! En stor sak;-)
För de andra 2 frågorna se mitt tidigare svar, Bör jag i PHP när jag skickar strängar till databasen ta hand om olagliga tecken med htmlspecialchars() eller använda ett reguljärt uttryck?
Nu är funktionsnamn olika så inte längre kommer min mysql_query, mysql_fetch_array, mysql_num_rows etc att fungera.
Det är en annan, allvarlig villfarelse hos PHP användare , en naturkatastrof, en katastrof:
Även när man använder gamla mysql-drivrutiner bör man aldrig använda bara API-funktioner i deras kod! Man måste sätta dem i någon biblioteksfunktion för vardagsbruk! (Inte som en magisk rit utan bara för att göra koden kortare, mindre repetitiv, felsäker, mer konsekvent och läsbar).
Detsamma gäller PDO också!
Nu med din fråga igen.
men genom att använda dem eliminerar detta behovet av att använda något som mysql_real_escape_string?
JA.
Men jag tror att det här är ungefär tanken på vad som ska göras för att hämta en användare från en databas
Inte för att hämta, utan för att lägga till vilken data som helst i frågan !
du måste ange en längd efter PDO:PARAM_STR om jag inte har fel
Du kan, men du behöver inte.
Nu, är allt detta säkert?
När det gäller databassäkerhet finns det inga svaga punkter i den här koden. Inget att säkra här.
för att visa säkerhet - sök bara på den här webbplatsen efter XSS nyckelord.
Hoppas jag kastar lite ljus över saken.
BTW, för de långa inläggen kan du använda funktionen jag skrev någon gång, Infoga/uppdatera hjälpfunktion med PDO
Jag använder dock inte förberedda uttalanden för tillfället, eftersom jag föredrar mina hembryggda platshållare framför dem, genom att använda ett bibliotek Jag nämnde ovan. Så för att motverka koden som postats av riha nedan, skulle den vara så kort som dessa två rader:
$sql = 'SELECT * FROM `users` WHERE `name`=?s AND `type`=?s AND `active`=?i';
$data = $db->getRow($sql,$_GET['name'],'admin',1);
Men självklart kan du ha samma kod med förberedda satser också.
* (yes I am aware of the Schiflett's scaring tales)