Вот такой вопрос, буду хранить данные в БД в BASE64, но там встреаются символы "=", "+" и "/" , на что их можно заменить чтобы они не влияли на SQL запрос, один символ можно заменить на "_" , а на что остальные два????
тэк. спакойно, товарищ. 1. нафига хранить в базе base64? 2. чтобы помещать данные в БД в любом случае всегда и обязательно использовать экранирование. Оно делается функцией real_escape или одноимённым методом. Экранирование не спасёт от злоумышленника, если не совпадают кодировки БД, таблицы, запроса и соединения с БД. =)
ну для того чтобы обезопасить данные из-вне решил что проще в base64 прогонять весь внешний ввод, всёравно данных не так много, так что можно и так вот "извратится"
ну на самом деле это вообще по сути временная заглушка/отработка технологии, потом все данные будут хранится в зашифрованном виде, и их всёравно придётся совать в BASE64 ибо после того-же блоуфиша там в строке такой "символьный треш" будет что лучше его засунуть в BASE64
можно в блобах хранить бинарные данные, тогда не потребуется конвертить Добавлено спустя 29 секунд: это тип поля такой - BLOB
про блобы уже думал, но хочется и надёжную защиту от внешних данных иметь, а так получается сразу и то и то закрывается
ну общий смысл весь ввод со стороны пользователя уходит в base64, поэтому дюбая sql инъекция невозиожна в принципе
Объясни как, если весь пользовательский ввод проходит преобразование в base64 и только потом с ним работаем
забей ты уже на эту идею. я ж сказал, что надо юзать правильную функцию - она всё обезопасит. ну почти.
офигительное решение. а как потом искать в этих полях? как выбирать по критерию? если все в базе лежит в закодированном виде... и главное зачем? если есть стандартные функции которые безопасно вставляют в бд ЛЮБЫЕ данные. это называестся создали велосипед из граблей.
Ну ладно, уговорил, а вот нафига - непонятно Это не более чем просто свалка в БД получается, выше правильно замечено.
какие например, те что я знаю зависят от кодировки и если предамеренно её исказить то база становится уязвимой для иньекций, я знаю что у этого решения есть минусы, но единственное что я теряю это возможность поиска внутри ячейи БД, но мне это и ненужно, мне нужно просто хранить некий конфиг который надо вставлять в зависимости от некоторых условий, то есть нийти имя ячейки я могу, надо просто перед поиском тоже загнать её в base64, а поиск по части слова как я уже сказал мне ненужен, так что на мой взгляд решение вполне уместное
Установи правильно кодировку. Ты хотя бы заглядывал в код других программистов или в готовые продукты? Считаешь они все уязвимы? Не смеши
Но ведь тот кто посылает может проигнорировать эту установку, мы же говорим о том что это делается намеренно
base64 уязвим , ведь его любой может раскодировать. поэтому только md5, кодирует, да еще компрессия дикая, и НИКТО не сможет раскодировать обратно))
а смысл в том что ты несможешь пепедать в нём никакую комманду SQL, а значит сделать иньекцию невозможно в принципе
можно юзать base64, которая увеличивает объём. можно юзать нормальную специальную функцию родную, которая не трогает объём и содержимое. ну... наверное стоит задуматься, и понять уже, что твоя идея бредом пахнет. =)
Недавно читал статейку где человек описал почему mysqli_real_escape_string не защищает от инекций, он в итоге сделал небольшую библиотеку которая парсила данные более жестоко, дал бы ссулку но закрыл вкладку и пока несмог её найти, но если наду то кину сюда
Теоретическая защита это круто. Но все проверяется практикой. Попробуйте себя похакать сами. Если все правильно настроено, base64-каша, переданная злоумышленником для "обхода" фильтров, принятая скриптом, знающим, что БД работает на UTF-8, что таблица, в которую идет запись на UTF-8 и что для соединения установлено UTF-8, просто будет записана как последовательность UTF-8 символов.