Bedankt voor de interessante vraag. Hier ga je:
Het ontsnapt aan gevaarlijke karakters,
Uw concept is volkomen fout.
In feite is "gevaarlijke tekens" een mythe, die zijn er niet. En mysql_real_escape_string ontsnapt maar slechts een tekenreeksscheidingstekens . Uit deze definitie kun je de beperkingen afleiden - het werkt alleen voor strings .
het is echter nog steeds kwetsbaar voor andere aanvallen die veilige tekens kunnen bevatten, maar schadelijk kunnen zijn voor de weergave van gegevens of in sommige gevallen voor het kwaadwillig wijzigen of verwijderen van gegevens.
Je mixt hier alles.
Over database gesproken,
- voor de snaren is het NIET kwetsbaar. Zolang uw strings worden geciteerd en ontsnapt, kunnen ze niet "gegevens kwaadwillig wijzigen of verwijderen".
* - voor de andere gegevenstypegegevens - ja, het is nutteloos . Maar niet omdat het enigszins "onveilig" is, maar gewoon vanwege oneigenlijk gebruik.
Wat betreft het weergeven van gegevens, ik veronderstel dat het offtopic is in de PDO-gerelateerde vraag, aangezien PDO ook niets te maken heeft met het weergeven van gegevens.
gebruikersinvoer ontsnappen
^^^ Nog een waanidee die moet worden opgemerkt!
-
een gebruikersinvoer heeft absoluut niets te maken met ontsnappen . Zoals je kunt leren van de vorige definitie, moet je strings escapen, niet wat voor "gebruikersinvoer" dan ook. Dus nogmaals:
- je hebt escape-strings, ongeacht hun bron
- het heeft geen zin om aan andere soorten gegevens te ontsnappen, ongeacht de bron.
Begrijp je wat je bedoelt?
Nu hoop ik dat je de beperkingen van ontsnappen en de misvatting over 'gevaarlijke personages' begrijpt.
Ik heb begrepen dat het gebruik van BOB/opgemaakte verklaringen een veel veiligere is
Niet echt.
In feite zijn er vier verschillende query-onderdelen die we er dynamisch aan kunnen toevoegen:
- een tekenreeks
- een nummer
- een ID
- een syntaxiszoekwoord.
dus je kunt zien dat ontsnappen slechts één probleem dekt. (maar natuurlijk, als je getallen als tekenreeksen behandelt (door ze tussen aanhalingstekens te zetten), indien van toepassing , je kunt ze ook veilig maken)
terwijl voorbereide verklaringen dekken - ugh - hele 2 isues! Een groot probleem;-)
Zie voor de andere 2 problemen mijn eerdere antwoord, Moet ik in PHP bij het indienen van strings naar de database zorgen voor illegale tekens met htmlspecialchars() of een reguliere expressie gebruiken?
Nu zijn de functienamen anders, dus mijn mysql_query, mysql_fetch_array, mysql_num_rows enz. werken niet langer.
Dat is een andere, ernstige waanvoorstelling van PHP gebruikers , een natuurramp, een catastrofe:
Zelfs als je een oude mysql-driver gebruikt, mag men nooit kale API-functies gebruiken in hun code! Je moet ze in een bibliotheekfunctie plaatsen voor dagelijks gebruik! (Niet als een magische rite, maar alleen om de code korter, minder repetitief, foutbestendig, consistenter en leesbaarder te maken).
Hetzelfde geldt ook voor de BOB!
Nu weer verder met je vraag.
maar door ze te gebruiken, elimineert dit de noodzaak om iets als mysql_real_escape_string te gebruiken?
JA.
Maar ik denk dat dit ongeveer het idee is van wat er moet gebeuren om een gebruiker uit een database te halen
Niet om op te halen, maar om wat voor gegevens dan ook aan de zoekopdracht toe te voegen !
je moet een lengte geven na PDO:PARAM_STR als ik me niet vergis
Dat kan, maar het hoeft niet.
Is dit allemaal veilig?
Op het gebied van databaseveiligheid zijn er gewoon geen zwakke plekken in deze code. Hier valt niets te beveiligen.
voor de weergavebeveiliging - zoek gewoon op deze site naar de XSS zoekwoord.
Ik hoop dat ik wat licht op de zaak werp.
Trouwens, voor de lange inserts kun je enig gebruik maken van de functie die ik ooit heb geschreven, Helperfunctie invoegen/bijwerken met PDO
Ik gebruik op dit moment echter geen voorbereide verklaringen, omdat ik de voorkeur geef aan mijn zelfgemaakte tijdelijke aanduidingen boven hen, met behulp van een bibliotheek Ik noemde hierboven. Dus, om de code die door de riha hieronder is gepost tegen te gaan, zou het zo kort zijn als deze 2 regels:
$sql = 'SELECT * FROM `users` WHERE `name`=?s AND `type`=?s AND `active`=?i';
$data = $db->getRow($sql,$_GET['name'],'admin',1);
Maar u kunt dezelfde code natuurlijk ook gebruiken met voorbereide instructies.
* (yes I am aware of the Schiflett's scaring tales)