слегка хакерский вопрос
 

Допустим на сайте я использую кодировку виндовс 1251.
соответственно в полях типа инпут текстэрия будет использоваться эта кодировка..
ну и непосредственно сам вопрос-есть ли возможность подменить кодировку во время(до) после передачи данных на сервер на сайте-тоесть страница использует 1251 а передать в утф 8?
вариант изменения исходного кода страницы на клиенте вручную а потом посылки запроса из изменённой(как раньше проходило в контакте тож рассматриваю.и интересно какие есть варианты защиты от этого
понимаю что это прозвучит вообще тупо-теоретически можно ли задать части символов строки передаваемой любым из методов post \get свою кодировку? да и без передачи возможно ли это для части строки?интересует клиентская сторона.
слепить строку из двух строк в разных с разными кодировками возможно?

зачем?
какова конечная цель, чтобы мог понадобится такой хак?

цель проста. если это невозможно в принципе то возможно сделать защиту от инъекций абсолютно другого уровня чем те что сейчас используются и широко известны.какой всёравно есть sql инекции (вне зависимостиот их рода)в передаваемых данных.

хм.
и как же вы собираетесь защищаться, на основании этого факта?
Если со страницы могут прийти данные только в CPxxxx (в которой находится страница), то что пользователь, что скрипт будет с нее отправлять данные именно в этой кодировке.
а если вы про то, в какой кодировке будет скрипт сположен через уязвимость в сайт, то это также без разницы.
латницы, цифр, и узкого набора спецсиволов вполне достаточно, чтобы сгенерить любой код, в любой кодировке.

PS исходный вопрос мне кажется возможным.
То есть, можно отправить данные в проивзольной кодировке
но проводить полномасштабное исследование по этому поводу мне немного лень.

Gvozd,
тоже ничего не нашел по этому поводу.но нашел только что всё в юникоде отправляется.по ходу в любом случае при отправке всё перекодируется в юникод.момент не в найти уязвимости сайта а в защите баз от инъекций
как? скажу. сейчас защита от иньекций базируеться на проверке типа данных да экранировании кавычек в основном.
но чтобы инъекция не сработала-достаточно в полученных данных заменить все пробелы и кавычки-на какие нибудь ничего не значащие последовательности символов. соответственно-эти данные будут без вопросов заноситься в базу(если типы для данных в таблице будут выставлены соответствующие). ну а при выборке их из базы их соответственно менять на те что были до замены и передавать на клиент.
да таблицы при этом получаются более громоздкие-но и полностью защищённые
ну а если склепать строку нельзя из строк с разными кодировками-то проверить кодировку строки на предмет попыток завязать лишнее труда не составит-да и смысла нет никакого в этом если есть юникод.

А зачем таки эти надмозги? Экранирование ещё никого не подводило.

Aetae,
не спорю. но тем не менее-средняя защита это порядка 10-15 строк.
эта занимает-4 при при записи и 4 при извлечении из бд.
да и те кто пропагандирует экранирование+доп защиту-всёравно делают упор на то что универсальной защиты нет.
в этой я пока минусов не вижу кроме размера б.д

фигня какая-то.
где вы собираетесь заменять кавычки и пробелы на "особые символы"?
на клиенте? легко подделать.
на сервере? чем это отличается от обычного экранирования кавычек?
*Пожалуйста очень хочу увидеть ответы на эти вопросы, для лучшего понимания вашей мысли

В поддержание этой не сильно нормальной идеи:
вы спокойно можете перекодировать вашу строку в любой кодировке в base64, к примеру. в нем не бывает кавычек и прочего.
Но, и это ничем по сути не отличается от обычной защиты
вы вызываете функцию, которая приводит данные к нужному безопасному типу

на сервере
в принципе да,но здесь вопрос что больше сервер загрузит перекодировка в base64 или подобная замена?
а если в передаваемой информации есть и кавычки и слова такиеже как опраторы mysql и последовательность кавычек важна также как и их количество ?
экранирование кавычек применяется совместно с другими методами.
одно экранирование не спасает от инъекций
для чего?чем больше вариантов защит в природе тем меньше вероятность что сломают.
аналогия -все замки выполняют одну и туже функцию. но подо все замки разные ключи и различные варианты замков есть-а не один вид

да и экранирование в моём случае только во вред

\вы вызываете функцию, которая приводит данные к нужному безопасному типу\ согласен полностью-но в тех вариантах защит что встречал,использование их грозило потерей части данных
изза чего это-задача информация должна быть удобочитаема как с базы так и с панели управления

ну а так (как я вижу) вероятность взлома инъекциями минимальная-точнее полное отсутствие таковой. сохраняется последовательность кавычек и их количество. в отличие от кодирования в base64 информация из в базе остаётся удобночитаемая
создал тему -интересовало можно ли принудительно заставить видеть часть строки в одной кодировке часть в другой

Сам факт того что при выводе надо делать доп. преобразования сразу отправляет идею в утиль.(не говоря об общей бредовости концепции)
Ибо данные в вебе в основном добавляются один раз, а читается миллионы.

а ты на клиенте будто бы видишь в каком виде данные храняться в базе на сервере?ты видишь лишь то что сгенерированно средствами рнр(если он используеться). и глядя на информацию у себя на мониторе ты будешь видеть данные в нормальном виде.
один раз-смотря на каких сайтах.
как раз javascript это не затрагивает. или ты данные в базу данных добавляешь и извлекаешь средствами javascript?)

да, пользователь увидит нормальные данные.
но на это будет потрачено дополнительное время сервером(на перевод между форматами).
Это означает:
1) больше время загрузки страницы у пользователя. или вам пофиг на конечного пользователя?
2) больше процессорных ресурсов на расшифровку. Или вы платите за хостинг не из своего кармана?
Если оба момента не важны для вашего конкретного проекта, то это не значит, что так стоит делать всегда.
Обычно данные помешенные в БД, просматриваются после этого не менее одного раза.
А в большинстве случаев, и во-много раз больше.
Как итог, в первую очередь надо оптимизировать вывод записи, а не ее занесение.

минутку, надо для начала увидеть строку, которую не сможет защитить mysql_real_escape_string (или о какой функции мы говорим?). Без этого не имеет смысла продолжать

для чисел: filter_var($id, FILTER_SANITIZE_NUMBER_INT), для строк: mysql_real_escape_string. При такой защите есть потеря данных?

это точно :yes:

Внимание, вопрос: "А зачем"? Бинды отменили, чтоли?

e1f,
а можете дать более подробную ссылку по информации?
Интересует именно в контексте MySQL, либо чистого SQL

а чем бинды отличаются от экранирования в данном контексте?

http://www.google.com.ua/search?q=php+mysqli+bind_param

Экранирование -- это "давайте будем сами делать то, что уже реализовано в db-интерфейсах. мы же умные, черт побери".

дело в том что информация во многих полях будет меняться чуть ли не ежедневнодело в том что экранирование в моём случае не совсем уместно,точнее совсем не уместно. в данных какие будут храниться-в любом развале изначально будут присутствовать кавычки. и они будут в любом месте хранимой строки. при выводе необходимо сохранить изначальное их количество и порядок следования. да это можно сделать вставив перед изначальными какие то флаги указывающие на то что они изначальные+экранирование сделать,но этот вариант по ресам займёт больше чем изначальная замена их спец символами.
и именно важно местоположение их-поскольку документооборот идёт именно в том виде в каком они в оригинале. любое искажение данных-кавычка не в том месте где была изначально или изменение их колва -приравнивается к потере данных...
Вопрос остаётся-можно ли к часть строки записать в одной кодировке а другую в другой и прямо указать для обработчиков(стандартных функций рнр)-на это?

по моему у него в видеокурсе я встречал пример где одно экранирование не спасало-точнее в том запросе оно было как мёртвому припарка. было нечего экранировать.
jolly-wind.ru

неправильное какое-то определение. В db-интерфейсах реализовано и экринирование, и binding. Скорее "давайте ограничим пользователя в том, куда и что можно вставлять, в надежде, что он на этом и остановится"

это еще надо доказать

mysql_real_escape_string ничего не искажает

у кого? Да и мало ли почему jolly-wind.ru могло не спасать одно экранирование

Экранирование реализовано средствами самого php, так? Мы экранируем данные, запихиваем их в запрос, отдаем библиотеке для работы с БД. В то время как
prepared statements - фича базы данных.

в этиом варианте может исказить-поскольку применяются все символы и экранирование невозможно будет отличить от реально введённых пользователем данных
ну вот пришли к тому что экранирование одно может не помочь ограничить инъекции. а ограничить тип данных я не могу- в силу специфики данных

ты ошибаешься. Ты, наверное, имел в виду get_magic_quotes_gpc() и addslashes/stripslashes

и тем не менее ему как-то удается

<?
mysql_connect('localhost', <login>, <passwd>) or die(mysql_error());
mysql_query('SET NAMES cp1251') or die(mysql_error());
mysql_select_db(<db>) or die(mysql_error());
mysql_query('DROP TABLE IF EXISTS t1') or die(mysql_error());
mysql_query('CREATE TABLE t1 (f1 TEXT CHARACTER SET cp1251)') or die(mysql_error());
$s = '';
for( $i=0; $i<256; $i++ )
    $s .= chr($i);
$_s = mysql_real_escape_string($s);
mysql_query("INSERT INTO t1 VALUES ('$_s')") or die(mysql_error());
$r = mysql_query('SELECT * FROM t1') or die(mysql_error());
$r = mysql_result($r, 0, 0);
if( $s != $r )
    die('mysql_real_escape_string sucks!!!');

и по поводу этого:

я не умею решать несуществующие проблемы. Если у них что-то не получилось, надо разобраться, что именно и почему. А не сразу делать вывод, что экранирование не работает

приведённый пример-это общий случай. в частном не пройдёт-вероятность возникновения частного минимальна конечно но всёже.
и всё равно эта полемика интересна-но меня интересует всего один вопрос(точнее группа вопросов)-заданный в начале этого топика
1 возможно ли слепить строку из строк с разными кодировками?-на клиенте
2 возможно ли сменить тип кодировки во время прередачи данных,или всёт аки передастся в той кодировке что указанна в странице?(одно упоминание я нашел что при гет и посте данные передаются в юникоде)-на клиенте
3. если всётаки можно изменить кодировку-можно ли скрипту рнр дать инструкции в этой строке указывающие на тип кодировки?
P.S никто не говорил что оно не работает-было сказано что оно не помагает в некоторых случаях инъекций.и то что в некоторых ситуациях оно может изменить исходную строку-что не желательно

в каких?

в каких?

повторюсь, я не умею решать проблему, не видя в чем она состоит. Но ты можешь подождать, пока кто-то другой ответит на твои вопросы

x-yuri,
дак я проблему не создавал и обход этой проблемы я знаю, но-меня интересовали ответы на эти вопросы и всё.-чтобы определиться по какому варианту реализовывать -по классическому с экранированием,проверкой на некоторые символы,вылавливанием "частного случая",приведением типа- либо с этим-где мне нужно только сделать замену.
а тему развили участники этой темы)
но насколько я понимаю -эти вопросы настолько специфические ,что навряд ли гдето массово обсуждались или поднимались.

Да, это и имел в виду. Просто мне метод prepare-bind-execute кажется более правильным, нежели do.

правильность - это не аргумент