Не „дезинфекцирайте“ въвеждане като средство за предотвратяване на SQL инжектиране - използвайте заместители (или правилното бягство) , винаги. Да бъда постоянен. Пази се. Проблемът вече е решен.
Този случай ще бъде „безопасен“ поради ограничения домейн на base64_encode функция. Въпреки това...
Това е лоша практика и съхраняването на стойности, кодирани в base64 (така че показаната заявка може да работи) носи няколко отрицателни последици, тъй като промени съхраняваната информация:тя унищожава подреждането на стойностите прави информацията нетривиална за търсене , изисква допълнителен стъпка „кодиране/декодиране“ и дори консумира повече място - ооо!
По този начин, въпреки че може да има специфични случаи за base64-кодиране на данни, този подход не подходящ като средство за смекчаване на SQL инжекция .
Проблемът се дължи на достъпа до SQL чрез текстов протокол където командата/формата на заявката и стойности се смесват. Използването на правилно техники за избягване (напр. mysql_real_escape_string ) коригира това, като гарантира, че информацията е екранирана, така че SQL текстът да се разбира синтактично както е предвидено - обаче, за разлика от стъпка за кодиране на base64, не всъщност променете предоставената информация!
Това е точно какво предоставят заместителите ! Заместителите са the универсално правилен подход и трябва да бъде насърчаван. Заместители позволяват изпращането на заявката и стойностите към базата данни отделно когато се поддържа от библиотеката/базата данни; и се емулират чрез избягване по друг начин. Правилното използване на заместителя елиминира SQL инжекция и необходимостта от потребителски код за смесване на стойности в SQL команден текст, което също може да направи заявките по-лесни за писане и поддръжка.
За да предотвратите "индивидуалните програмисти" да пишат ужасни заявки, решението е предотвратяване ad hoc заявки да не бъдат разпръснати наоколо в кода:събирайте операциите за достъп до данни в слой за достъп до данни ( DAL) (евентуално във връзка с ORM) и излагайте само съответните действия, като гарантирате правилното използване на SQL в рамките на DAL. При по-прости проекти DAL също е подходящо място за централно управление на бизнес правилата за санитария и друга логика за валидиране.
По-точно:
-
Санитизирайте ценности за бизнес правила; това трябва да предотврати „лоша информация“, като например потребителско име, което е твърде кратко, съдържа ограничени знаци или по друг начин не отговаря на бизнес изискванията.
-
Използвайте заместители за предотвратяване на SQL инжекция . Това е строго свързано с прехвърлянето на данните към SQL и няма отношение към информацията в тях.
Докато MySQL 5.6.1 добавя FROM_BASE64 , така че кодирането може просто да се използва в текста на SQL командата, това все пак добавя допълнителна изрична стъпка на декодиране и усложнява заявката при използване на такава схема за кодиране. Този подход base64 просто не е необходимо, тъй като вече има доказани техники за предотвратяване на SQL инжектиране и не беше предложено в първоначалния въпрос.
