Tak for det interessante spørgsmål. Her går du:
Det undslipper farlige karakterer,
Dit koncept er fuldstændig forkert.
Faktisk er "farlige karakterer" en myte, der er ingen. Og mysql_real_escape_string undslipper, men blot en strengafgrænser . Ud fra denne definition kan du konkludere dens begrænsninger - den virker kun for strenge .
det er dog stadig sårbart over for andre angreb, som kan indeholde sikre tegn, men som kan være skadeligt for enten at vise data eller i nogle tilfælde ændre eller slette data på en ondsindet måde.
Du blander alt her.
Apropos database,
- for strengene er den IKKE sårbar. Så længe dine strenge bliver citeret og undslippet, kan de ikke "ændre eller slette data med ondsindethed".
* - for de andre datatypedata - ja, det er ubrugeligt . Men ikke fordi det er noget "usikkert", men blot på grund af forkert brug.
Hvad angår visning af data, formoder jeg, at det er offtopic i det PDO-relaterede spørgsmål, da PDO heller ikke har noget at gøre med visning af data.
undgå brugerinput
^^^ Endnu en vrangforestilling skal bemærkes!
-
et brugerinput har absolut intet at gøre med escape . Som du kan lære af den tidligere definition, skal du undslippe strenge, ikke uanset "brugerinput". Så igen:
- du har escape-strenge, uanset deres kilde
- det er nytteløst at undslippe andre typer data, uanset kilden.
Forstår du pointen?
Nu håber jeg, du forstår begrænsningerne ved at undslippe såvel som misforståelsen af "farlige karakterer".
Det er efter min forståelse, at brug af PDO/forberedte erklæringer er meget sikrere
Egentlig ikke.
Faktisk er der fire forskellige forespørgselsdele, som vi kan tilføje til det dynamisk:
- en streng
- et tal
- en identifikator
- et syntakssøgeord.
så du kan se, at escape kun dækker ét problem. (men selvfølgelig, hvis du behandler tal som strenge (sætter dem i anførselstegn), hvis det er relevant , du kan også gøre dem sikre)
mens udarbejdede udsagn dækker - ugh - hele 2 spørgsmål! En stor ting;-)
For de andre 2 problemer se mit tidligere svar, I PHP, når jeg sender strenge til databasen, skal jeg passe på ulovlige tegn ved hjælp af htmlspecialchars() eller bruge et regulært udtryk?
Nu er funktionsnavne forskellige, så min mysql_query, mysql_fetch_array, mysql_num_rows osv. fungerer ikke længere.
Det er endnu en alvorlig vrangforestilling hos PHP brugere , en naturkatastrofe, en katastrofe:
Selv når man bruger gammel mysql-driver, bør man aldrig bruge bare API-funktioner i deres kode! Man er nødt til at sætte dem i en eller anden biblioteksfunktion til hverdagsbrug! (Ikke som en magisk ritual, men bare for at gøre koden kortere, mindre gentagen, fejlsikker, mere konsistent og læsbar).
Det samme gælder for PDO'en!
Nu med dit spørgsmål igen.
men ved at bruge dem eliminerer dette behovet for at bruge noget som mysql_real_escape_string?
JA.
Men jeg tror, at dette groft sagt er ideen om, hvad der skal gøres for at hente en bruger fra en database
Ikke for at hente, men for at tilføje en hvilken som helst data til forespørgslen !
du skal angive en længde efter PDO:PARAM_STR, hvis jeg ikke tager fejl
Du kan, men du behøver ikke.
Nu, er det hele sikkert?
Med hensyn til databasesikkerhed er der bare ingen svage punkter i denne kode. Intet at sikre her.
for at vise sikkerhed - søg bare på dette websted efter XSS søgeord.
Håber jeg kaster lidt lys over sagen.
BTW, til de lange inserts kan du gøre lidt brug af den funktion, jeg skrev en dag, Indsæt/opdater hjælpefunktion ved hjælp af PDO
Jeg bruger dog ikke forberedte udsagn i øjeblikket, da jeg foretrækker mine hjemmebryggede pladsholdere frem for dem ved at bruge et bibliotek Jeg nævnte ovenfor. Så for at imødegå koden, der er postet af riha nedenfor, ville den være så kort som disse 2 linjer:
$sql = 'SELECT * FROM `users` WHERE `name`=?s AND `type`=?s AND `active`=?i';
$data = $db->getRow($sql,$_GET['name'],'admin',1);
Men du kan selvfølgelig også have den samme kode ved at bruge forberedte udsagn.
* (yes I am aware of the Schiflett's scaring tales)