forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., opennews (??), 17-Июн-10, (0) [смотреть все]

Зачем это А внешних кавычек conn- query select from table where fname fn, Аноним (-), 00:40 , 17-Июн-10, (1) –8 //

fname xxx delete from table select goodbye conn- query select from , XoRe (ok), 00:49 , 17-Июн-10, (3) +2
PHP-программисты такие програссимты ясное дело что подставление ковычек -- НЕ , Аноним (-), 21:26 , 18-Июн-10, (98) +1 //

В PHP достаточно юзать PDO и bindColumn -методы для достижения того же самого р, Kibab (ok), 09:34 , 21-Июн-10, (102)

Очень интересно Просто и гениально Хотя все сводится к тому, что программисты в , XoRe (ok), 00:42 , 17-Июн-10, (2) +1 //

По-моему он экранирование переизобрел И даже если принять синтаксис , непонятн, _Vitaly_ (ok), 01:14 , 17-Июн-10, (7) +4 //

В том-то и дело, что экранировать сплошь и рядом забывают или криво экранируют, , Аноним (-), 04:23 , 17-Июн-10, (19) +2 //

А ещё можно экранировать при включенном автоэкранировании, тоже весело Так что , zazik (ok), 10:30 , 17-Июн-10, (41)
Когда разработчики не дураки, обычно запросы идут через прослойку, которая автом, _Vitaly_ (ok), 12:19 , 17-Июн-10, (56) +3

Да суть-то в другом Чтобы была схема юзер что-то ввел в форму - оно кодируется в, XoRe (ok), 11:24 , 18-Июн-10, (91) +4

Теперь просек Действительно хороший выход для тех, кто без врапперов пишет , _Vitaly_ (ok), 00:15 , 20-Июн-10, (100)

идея конечно гениальнаНОесли у меня в базе будут base64 закодированные данные, т, ffsdmad (ok), 01:00 , 17-Июн-10, (4) –1 //

Base64 передается в только в запросе, завернутый в вызов функции преобразования , Alex (??), 01:16 , 17-Июн-10, (8) –1 //

а какой смысл если после декодирования в запросе появится лишняя кавычка или joi, ffsdmad (ok), 01:20 , 17-Июн-10, (10) –2 //

либо это должно быть встроено в субд, всмысле врапер, чтобы раскодированная стро, ffsdmad (ok), 01:22 , 17-Июн-10, (11) +1

само собой, base64 декодируется уже внутри СУБД, средствами субд и представляет , Аноним (-), 05:15 , 17-Июн-10, (24) +3

base64 всегда буквы и цифры, т е чтобы не делал в запросе всегда будут буквы и , Аноним (-), 04:27 , 17-Июн-10, (20) +1

непонятно, так если я введу например через веб-форму or в переменную fna, ссс (?), 01:03 , 17-Июн-10, (5) –1 //

получивший известность обнаружением фундаментальной уязвимости в , ffsdmad (ok), 01:04 , 17-Июн-10, (6)
Не выполнит , аноним (?), 01:43 , 17-Июн-10, (12) +2
В запросе к базе будет вместо вашего or - b64d DSSDDQEd , и уже СУБД д, Аноним (-), 04:32 , 17-Июн-10, (22) +1

А 2 года назад меня пытались заплевать http sql ru forum actualthread aspx t, vvvua (ok), 01:18 , 17-Июн-10, (9) +1 //

А тебя и сейчас за это заплюют и правильно сделают , аноним (?), 01:44 , 17-Июн-10, (13) –1
Вы предгагаете сделать так INSERT INTO table VALUES _base64_enoded_string_ , Аноним (-), 01:57 , 17-Июн-10, (15) //

Практика показывает, что экранирование под давлением человеческого фактора совсе, Аноним (-), 04:34 , 17-Июн-10, (23)

И правильно заплевали Ваше решение из разряда защитимся от XSS и для этого всё в, pento (?), 02:01 , 17-Июн-10, (17) //

Верно сказано Чем эти методы лучше использования, скажем, PDO с параметрами и н, Gambler (ok), 03:02 , 17-Июн-10, (18) +1
Вы ошиблись Я не от XSS защищал, а от SQL injection Это разные вещи Кроме тог, vvvua (ok), 14:55 , 17-Июн-10, (72) //

gt оверквотинг удален 1 Я в курсе того, чем отличаются XSS от SQL-инъекции2 , pento (ok), 15:52 , 17-Июн-10, (74)

На счет костыльного решения - 100 Что моё, что Камински Я не приветствую решен, vvvua (ok), 16:02 , 18-Июн-10, (96)

Лол Base64 в целях безопасности, такого еще не было , аноним (?), 06:39 , 17-Июн-10, (25) –5
Вы предлагали совсем другое Глупо хранить в базе все строки в base64 , FractalizeR (ok), 10:26 , 17-Июн-10, (39) +1 //

Как по мне, похожее предложение Да, другая проверка на соответствие base64 На , vvvua (ok), 14:48 , 17-Июн-10, (71) –1 //

Читайте еще раз Абсолютно не похожее , FractalizeR (ok), 14:57 , 17-Июн-10, (73) +1

Во всех нормальных библиотеках это происходит и так псевдокод query parse , tonnzor (?), 01:45 , 17-Июн-10, (14) +5 //

Автор это объясняет тем, что ни один програмер не пишет параметризированные запр, filosofem (ok), 01:59 , 17-Июн-10, (16) //

Фигня Параметризованные запросы сильно ускоряют работу при использовании норм, Sabitov (?), 06:51 , 17-Июн-10, (27) +3 //

Зачем mysqli да, если есть выбор пиши под постгрес, не пожалеешь И автора не , filosofem (ok), 08:22 , 17-Июн-10, (29)
Раз уж пошла такая пьянка Есть неочевидный фактор, который заставляет меня ус, Pashugan (?), 13:07 , 17-Июн-10, (61) +1

Ты написал тупость, которая даже в мена костыле MySQL уже не соответствует дейст, аноним (?), 17:19 , 17-Июн-10, (80) –1

Вообще написал он правильно - разница в скорости выполнения минимальна Вызов фун, Ivan1986 (?), 20:35 , 17-Июн-10, (86) +1

Вы в корне не правы или правы в некотором частном случае может быть для MySQL , onk (?), 11:44 , 18-Июн-10, (92) +1

Так ли в корне он неправ Помимо времени на компиляцию запроса есть ещё фактор д, Pashugan (?), 14:52 , 18-Июн-10, (94)

Я знаю, что правильно написал, потому что проверял это реальными тестами mysqli,, Pashugan (?), 14:39 , 18-Июн-10, (93)

Семь раз RTFM, один раз rm -rf D, tupka (?), 19:34 , 18-Июн-10, (97) +1

Полная чушь, если нормально реализовано, то никто просто не захочет писать не па, Ivan1986 (?), 09:08 , 17-Июн-10, (30) +1 //

Вся прелесть параметризованных запросов как-то в миг рушится, когда параметром о, Lain_13 (?), 09:44 , 17-Июн-10, (33)

Сходите по ссылке select from _table - префикс - по сути самый часто использ, ivan1986 (?), 10:06 , 17-Июн-10, (37) +1

Дык кто бы сомневался - творчеВство пехепешников - оно вообще вштыряет не по дет, аноним (?), 17:24 , 17-Июн-10, (81) +1

Что именно чушь Если СУБД не поддерживает параметризированные запросы, то никак, filosofem (ok), 11:17 , 17-Июн-10, (43)

Я ее дописывал, а не только проверял Что может - использует встроенные параметри, ivan1986 (?), 11:25 , 17-Июн-10, (44)

А вам не кажется, что использование черного ящика , который то экранирует то па, Аноним (-), 11:33 , 17-Июн-10, (46)

А вам не кажется, что придумывание своего велосипеда, который хоть и известен до, ivan1986 (?), 11:44 , 17-Июн-10, (48)

Вот видите, вы сами подтвердили мою гипотезу о том, что не стоит доверять внешни, Аноним (-), 11:49 , 17-Июн-10, (50)

Вы только что доказали, что вы Аналитик с лора Тоесть вы предлагаете экранирова, ivan1986 (?), 11:59 , 17-Июн-10, (52) +1

Я предлагаю не испытывать излишнего доверия к черным ящикам , так как в этом ли, Аноним (-), 12:17 , 17-Июн-10, (55) +1

Понятно, позиция называется - пишем на ассемблере все Вы сейчас несете чушь - ис, ivan1986 (?), 12:34 , 17-Июн-10, (57)

Стоп, это же именно вы предлагайте использовать левую нестандартную библиотеку в, Аноним (-), 13:11 , 17-Июн-10, (63)
Нет, я как раз предлагаю использовать стандартные функции - в случае mysql - mys, ivan1986 (?), 13:22 , 17-Июн-10, (65)
Я пробовал принимать в mainstream - , Аноним (-), 14:15 , 17-Июн-10, (70)

Release Date 2006-06-02, Sw00p aka Jerom (?), 20:48 , 17-Июн-10, (87)

Не вижу проблем писать код вида псевдокод conn- query SELECT FROM table WH, Аноним (-), 13:47 , 17-Июн-10, (67) //

вот тут-то как раз собака и порылась - если использовать биндинг то параметры вс, Cobold (??), 16:13 , 17-Июн-10, (75) //

Да, все правильно По сути этоиу правилу удовлетворяет PDO, а симпла, про которую, ivan1986 (?), 16:42 , 17-Июн-10, (79)

Вот в Постгрес есть такая тема, можно задавать любые ограничители типа somethin, Аноним (-), 06:39 , 17-Июн-10, (26) +1
Это всё конечно интересно, да вот только ПМСМ нормальные программеры итак заботя, anthonio (ok), 09:24 , 17-Июн-10, (31) //

Только нормальный программеров раз-два и обчелся, или их код обязательно будет р, Аноним (-), 09:52 , 17-Июн-10, (35) //

Значит пишут спустя рукава Или это PHP виноват , anthonio (ok), 10:01 , 17-Июн-10, (36) //

А кто мешает писать спустя рукава с использованием именно этого метода Разве, FractalizeR (ok), 10:27 , 17-Июн-10, (40) +1

Вы считаете что у друпала или у джумлы хороший код Блин, да достаточно посмотрет, ivan1986 (?), 10:20 , 17-Июн-10, (38) +1 //

Давайте пойдем от обратного, можете привести пример качественного PHP-проекта, к, Аноним (-), 11:25 , 17-Июн-10, (45)

Ну например ZendFramework - довольно хороший код Неплохой в кохане, правда не ос, ivan1986 (?), 11:47 , 17-Июн-10, (49)
Вообще по части библиотеки доступа к базе данных - если при запросе к базе данны, ivan1986 (?), 11:53 , 17-Июн-10, (51)

Безумие какое-то workaround для безграмотности BTW - параметризованные запрос, Slautin (?), 09:27 , 17-Июн-10, (32) +1 //

если учесть сколько народу пишет для mysql, то там нативного биндинга нет и изза, Cobold (??), 12:15 , 17-Июн-10, (54)
Иногда да, иногда нет См комментарий 61 , Pashugan (?), 13:11 , 17-Июн-10, (62) //

нет , на мой взгляд, справедливо для очень узкого круга задач, обычно очень про, Slautin (?), 09:22 , 18-Июн-10, (90) //

Я как раз говорил, что в типичном скриптовом веб-приложении скорее всего буде, Pashugan (?), 15:35 , 18-Июн-10, (95)

ИМХО автор просто подошёл к проблеме интересным образом Я не говорю, что он реш, ixti (ok), 11:15 , 17-Июн-10, (42) //

Верно, решение интересное Возможно, что в каких-то других областях программиров, Gambler (ok), 04:21 , 18-Июн-10, (89)

На самом деле действительно гениально и просто Я бы, по крайней мере, до такого , zuborg (?), 11:34 , 17-Июн-10, (47)
совсем крыша поехала, вставлять eval и рассуждать о безопасности Кроме того эта, Cobold (??), 12:06 , 17-Июн-10, (53) +1
1 нифига этот метод не универсальный а если запрос conn- query select from , terr0rist (ok), 12:42 , 17-Июн-10, (58) //

Последний вывод у вас странный Есть нормальные проекты, просто блин никто в здра, ivan1986 (?), 12:53 , 17-Июн-10, (59) //

gt оверквотинг удален Зря Вы так про опенсорс, просто бывают разные модели раз, Cobold (??), 13:17 , 17-Июн-10, (64) //

Я так не про олпенсорс вообще, а про разработку силами комьюнити Вот если разраб, ivan1986 (?), 13:25 , 17-Июн-10, (66)

как-то довелось делать аудит для чужого проекта с тремя тысячами запросами по ко, Cobold (??), 13:05 , 17-Июн-10, (60) +1
А что бы вместо пхп предпочли вы , noname (??), 22:13 , 21-Июн-10, (103)
В то время, как такие, как Вы, орут об убогости пхп на форумах, нормальные разра, Kibab (ok), 19:49 , 22-Июн-10, (104)

Ну, и ещё раз о главном хоть, это возможно просто пример За conn- query f, Аноним (-), 14:02 , 17-Июн-10, (69) //

ха-ха-ха За второй вариант по яйцам бить нужно так-же больно , ivan1986 (?), 16:38 , 17-Июн-10, (78)

Странно, что устроили такой холивар на пустом месте Никто не заставляет вас исп, Aleksey (??), 16:24 , 17-Июн-10, (76) //

не смешно, ivan1986 (?), 16:34 , 17-Июн-10, (77)

Способ конечно неплохой, но не всегда удобный Кроме того, есть ещё такая вещь ка, anonymous (??), 18:38 , 17-Июн-10, (83) //

Я хотел сказать очень старый баян , anonymous (??), 18:40 , 17-Июн-10, (84)

Проблема в том, что base64 - по природе своей костыль Если подумать, экраниров, StrangeAttractor (ok), 21:27 , 18-Июн-10, (99)
base64 ничем не лучше встроенных в БД методов квотирования, а минусы есть -- д, RinNas (?), 12:48 , 30-Июл-10, (105)

Сообщения [Сортировка по времени | RSS]

14. "bind" +5 +/–

Сообщение от tonnzor (?), 17-Июн-10, 01:45

Во всех нормальных библиотеках это происходит и так (псевдокод):
$query = parse("select * from users where id = :users")
$query->bind('users', $users);
$query->execute();
И в MySQL, и в Oracle такое есть.

Ответить | Правка | Наверх | Cообщить модератору

16. "bind" +/–

Сообщение от filosofem (ok), 17-Июн-10, 01:59

Автор это объясняет тем, что ни один програмер не пишет параметризированные запросы, кроме как под дулом пистолета. Якобы это сложнее, чем его костыль.
Не исключено, что в некоторых случаях так и есть. Или например когда сервер достался от некрофилов с каким-нибудь php4.

Ответить | Правка | Наверх | Cообщить модератору

27. "bind" +3 +/–

Сообщение от Sabitov (?), 17-Июн-10, 06:51

Фигня :)
Параметризованные запросы сильно ускоряют работу при использовании нормальных СУБД, даже безотносительно к безопасности. Кодеры, которые не используют таких запросов, должны лишаться ЗП в обязательном порядке! :)
К сожалению, пыхпых 5 не умеет их поддерживать, если используется mysql, а не mysqli :( Но это уже другая песня.

Ответить | Правка | Наверх | Cообщить модератору

29. "bind" +/–

Сообщение от filosofem (ok), 17-Июн-10, 08:22

Зачем mysqli да, если есть выбор пиши под постгрес, не пожалеешь. =)
И автора не обижайте, уверен, что он пошутил, насчет "никто не пишет".

Ответить | Правка | Наверх | Cообщить модератору

61. "bind" +1 +/–

Сообщение от Pashugan (?), 17-Июн-10, 13:07

Раз уж пошла такая пьянка... Есть неочевидный фактор, который заставляет меня усомниться в справедливости Вашей зарплаты. ;) Время выполнения запроса к типичному веб-приложению - доли секунды. Если оно реализовано на скриптовых языках по стандартной схеме типа apache+mod_php5, то через эту долю секунды процесс умирает вместе со всеми объектами параметризированных запросов, и они будут создаваться заново при каждом новом запросе. Количество использований каждого из prepared statements (речь ведь идёт о них?) в таком приложении будет скорее всего равно 1. Более того, так и должно быть, мы ведь не делаем селекты в цикле, верно? :) Соответственно, те выгоды, о которых Вы говорите, проявляются лишь в приложениях, которые непрерывно висят в памяти и не собирают контекст на каждый чих, будь то java-сервлеты или скрипты+fastcgi. Я замерял, биндинг mysqli проигрывал примерно на 30% конкатенации+mysql_real_escape_string(), хотя эта цифра может служить для ориентировки.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

80. "bind" –1 +/–

Сообщение от аноним (?), 17-Июн-10, 17:19

>Раз уж пошла такая пьянка... Есть не очевидный фактор, который заставляет меня усомниться в справедливости Вашей зарплаты. ;)
Ты написал тупость, которая даже в мена костыле MySQL уже не соответствует действительности ...
Простой вопрос на засыпку, что происходит (в нормальных DBMS) после того как парсер разобрал параметризованный запрос, но до того как ты забиндил значение и позвал экзекутор?
Подсказка: ну хорошо - позвал ты экзекутор, что происходит дальше?

Вот - вот, семь раз RTFM - один раз ...  :)

Ответить | Правка | Наверх | Cообщить модератору

86. "bind" +1 +/–

Сообщение от Ivan1986 (?), 17-Июн-10, 20:35

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

Ответить | Правка | Наверх | Cообщить модератору

92. "bind" +1 +/–

Сообщение от onk (?), 18-Июн-10, 11:44

Вы в корне не правы (или правы в некотором частном случае)!
может быть для MySQL это и правда, но приличные СУБД (в частности Oracle) _кешируют_ запросы после парсинга. в итоге запрос повторно разбирать не нужно!
собственно число запросов в приложении конечно и при достаточном обьеме кеша у СУБД это неплого ускоряет работу.

Ответить | Правка | Наверх | Cообщить модератору

94. "bind" +/–

Сообщение от Pashugan (?), 18-Июн-10, 14:52

>Вы в корне не правы (или правы в некотором частном случае)!
>может быть для MySQL это и правда, но приличные СУБД (в частности
>Oracle) _кешируют_ запросы после парсинга. в итоге запрос повторно разбирать не
>нужно!
>собственно число запросов в приложении конечно и при достаточном обьеме кеша у
>СУБД это неплого ускоряет работу.
Так ли в корне он неправ? Помимо времени на компиляцию запроса есть ещё фактор двойной передачи данных - запроса и параметров. Скорее всего, вычисление ключа кеша осуществляется на сервере, а значит текст запроса всё равно нужно сначала передать на сервер. Так что продолжать спорить считаю бессмысленным, и если у Вас есть под рукой Oracle с быстрым надёжным каналом до него, буду рад увидеть результаты тестов.

Ответить | Правка | Наверх | Cообщить модератору

93. "bind" +/–

Сообщение от Pashugan (?), 18-Июн-10, 14:39

Я знаю, что правильно написал, потому что проверял это реальными тестами mysqli, а не просто занимался упражнениями в красноречии. :) Также я всегда готов выслушать обоснованные возражения и по-нормальному поспорить, чтобы докопаться до истины, но не вижу смысла отвечать анонимусам, которые готовы только гадить на голову коллег по цеху, но по существу вопроса ничего не пишут. :)

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

97. "bind" +1 +/–

Сообщение от tupka (?), 18-Июн-10, 19:34

>Вот - вот, семь раз RTFM - один раз ...  :)
Семь раз RTFM, один раз rm -rf :D

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

30. "bind" +1 +/–

Сообщение от Ivan1986 (?), 17-Июн-10, 09:08

Полная чушь, если нормально реализовано, то никто просто не захочет писать не параметризованные запросы, так как они сильно упрощают код.
В PDO как раз реализовано не нормально - синтаксис многословный.
Посмотрите как реализовано тут - http://dklab.ru/lib/DbSimple/
$db->select('select * from table where fname=? {AND id IN (?a)}', 'user', array(1,2,3));
После использования такого синтаксиса как раз писать по старому будешь только под дулом пистолета.

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

33. "bind" +/–

Сообщение от Lain_13 (?), 17-Июн-10, 09:44

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

Ответить | Правка | Наверх | Cообщить модератору

37. "bind" +1 +/–

Сообщение от ivan1986 (?), 17-Июн-10, 10:06

Сходите по ссылке
'select * from ?_table' - префикс - по сути самый часто используемый вариант
'select * from ?# where ...', 'tbl' - имя
Вложенные подзапросы тоже есть, плюс в новой версии на форуме есть плейсхолдер подзапроса, можно творить такое, что я уже не знаю что туда можно добавить.
http://forum.dklab.ru/viewtopic.php?p=180253#180253
К сожалению либа была заброшена немного, но сейчас в составе фреймворка развивается
https://sourceforge.net/projects/quickfw/

Ответить | Правка | Наверх | Cообщить модератору

81. "bind" +1 +/–

Сообщение от аноним (?), 17-Июн-10, 17:24

>Сходите по ссылке
>'select * from ?_table' - префикс - по сути самый часто используемый вариант
Дык кто бы сомневался - творчеВство пехепешников - оно вообще вштыряет не по детски.
То что такими гениальными запросами ставится на колени любая субд на любом железе уже "не проблемма кодера" да? :)

Ответить | Правка | Наверх | Cообщить модератору

43. "bind" +/–

Сообщение от filosofem (ok), 17-Июн-10, 11:17

Что именно чушь? Если СУБД не поддерживает параметризированные запросы, то никакой API их не сделает. Как вы собираетесь писать параметризированные запросы к какой-нибудь MSSQL 2k, или как вы будете делать аудит кода на php4, переписывать полностью на php5?
ИМХО чушь это использовать на продакшне непонятные ноунэйм библиотеки. Вы проверяли, что эта DbSimple действительно делает параметризированные запросы? А вы уверены, что она так со всеми запросами будет делать? Или, что в ней нет многолетней дыры, которую просто некому заделывать, потому что никому не надо?
То что в API выглядит запросом с параметрами, к СУБД может идти обычной строкой.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

44. "bind" +/–

Сообщение от ivan1986 (?), 17-Июн-10, 11:25

Я ее дописывал, а не только проверял.
Что может - использует встроенные параметризации, что нет - раскрывает и сама экранирует.
В случае, если параметры не поддерживаются, то конечно идет обычной экранируемой строкой.
Почему-то в PDO нету подстановки в качестве параметров массивов, идентификаторов, и прочих полезных вещей.

Ответить | Правка | Наверх | Cообщить модератору

46. "bind" +/–

Сообщение от Аноним (-), 17-Июн-10, 11:33

>Я ее дописывал, а не только проверял.
>Что может - использует встроенные параметризации, что нет - раскрывает и сама
>экранирует.
>В случае, если параметры не поддерживаются, то конечно идет обычной экранируемой строкой.
>
>Почему-то в PDO нету подстановки в качестве параметров массивов, идентификаторов, и прочих
>полезных вещей.
А вам не кажется, что использование "черного ящика", который то экранирует то параметоризирует, распускает разработчика, который начинает излишне доверять сторонней библиотеки, но по сути курит на бочке с порохом ? Я бы не стал доверять внешнему универсальному коду экранирования, например, дыры с недоэкранированием при передачи битого unicode классический пример, что и на старуху бывает проруха.

Ответить | Правка | Наверх | Cообщить модератору

48. "bind" +/–

Сообщение от ivan1986 (?), 17-Июн-10, 11:44

А вам не кажется, что придумывание своего велосипеда, который хоть и известен до каждого винтика, но как всегда получится с квадратными колесами (доказано огромным количеством примером - столько CMS/форумов/фреймворков приделают в качестве доступа к базе такую фигню, что за голову берешься), взяли бы хоть PDO, и то лучше было бы.
Экранируется кстати стандартными функциями - mysql_real_escape в случае mysql, pdo::quote в случае PDO, и так далее.

Ответить | Правка | Наверх | Cообщить модератору

50. "bind" +/–

Сообщение от Аноним (-), 17-Июн-10, 11:49

>Экранируется кстати стандартными функциями - mysql_real_escape в случае mysql,
Вот видите, вы сами подтвердили мою гипотезу о том, что не стоит доверять внешним универсальным решениям. Я как раз упоминал о хитрых методах обхода экранирование через многобайтовые кодировки, о которых разработчики разных функций проверки не догадывались.
http://secunia.com/advisories/20365/
"The vulnerability is caused due to an error within the server when parsing a query string that is escaped with the "mysql_real_escape_string()" function. This can potentially be exploited in an environment that uses multi-byte character encoding to bypass SQL injection escaping."

Ответить | Правка | Наверх | Cообщить модератору

52. "bind" +1 +/–

Сообщение от ivan1986 (?), 17-Июн-10, 11:59

Вы только что доказали, что вы "Аналитик с лора"
Тоесть вы предлагаете экранировать самому - в результате допустить еще неизвестно какие баги, но жутко бояться уже пофикшенного давным давно бага.
SQL injection vulnerability in MySQL 4.1.x before 4.1.20 and 5.0.x before 5.0.22
Аналитик, такой аналитик.

Ответить | Правка | Наверх | Cообщить модератору

55. "bind" +1 +/–

Сообщение от Аноним (-), 17-Июн-10, 12:17

Я предлагаю не испытывать излишнего доверия к "черным ящикам", так как в этом лишнем звене могут быть дыры. Если пользователи "mysql_real_escape_string()" увидят появление узявимости, то пользователи вашего черного ящика могут догадаться о ней только по косвенным признакам или после аудита кода. И не факт, что дыру в "черном ящике" автор исправит на следующий день, она может годами висеть незамеченной.
PS. Вы скатились до личных оскорблений, не имея аргументов для возражения. Посему считаю дискуссию законченной.

Ответить | Правка | Наверх | Cообщить модератору

57. "bind" +/–

Сообщение от ivan1986 (?), 17-Июн-10, 12:34

Понятно, позиция называется - пишем на ассемблере все.
Вы сейчас несете чушь - использование стандартных функций там, где можно - лучше, чем писать свои, которые реализуют ту-же самую функциональность.
Если исправят баг в основной, то баг исправится и тут, а вот если бы был сделан велосипед, который предложили вы, то он как раз бы и висел бы годами не найденный.
Излишнего доверия к "черным ящикам" никто не испытывает, более того код тут открыт, и даже пару багов было найдено и исправлено.
Стандартный функционал mysql_* функций совершенно не подходит, поэтому и была изначально написана эта библиотека, потом появился php5 с PDO, функциональность которого была лучше, но тоже не совсем устраивала, но для него был написан адаптер, который использует эту функциональность.
Вот если PDO или что-то еще разовьется до того уровня, чтобы предоставить аналогичную функциональность, то тогда эта библиотека будет не нужна, вот только когда это будет, и будет ли вообще :)
Оскорблений не было, это констатация факта :)

Ответить | Правка | Наверх | Cообщить модератору

63. "bind" +/–

Сообщение от Аноним (-), 17-Июн-10, 13:11

>Вы сейчас несете чушь - использование стандартных функций там, где можно -
>лучше, чем писать свои, которые реализуют ту-же самую функциональность.
Стоп, это же именно вы предлагайте использовать левую нестандартную библиотеку вместо стандартных функций экранирования PHP.

>Если исправят баг в основной, то баг исправится и тут,
Если автор левой библиотеки, которой пользуются 10 человек, не забросит свой проект. Посмотрите последние обновления безопасности в RHEL, там поправили дыры годичной давности,
как раз в библиотеках, подобных вашей.
>Стандартный функционал mysql_* функций совершенно не подходит, поэтому и была изначально написана
>эта библиотека, потом появился php5 с PDO, функциональность которого была лучше,
Вот и надо было продвигать идеи в mainstream, а не создавать левый проект, использование которого целесообразно только для людей, принимающих участие в его разработке.

Ответить | Правка | Наверх | Cообщить модератору

65. "bind" +/–

Сообщение от ivan1986 (?), 17-Июн-10, 13:22

Нет, я как раз предлагаю использовать стандартные функции - в случае mysql - mysql_real_escape_string, в случае PDO - PDO::escape, а вы тут ругаетесь на то что раз она бажная, то нужно написать свою обертку.
>Вот и надо было продвигать идеи в mainstream, а не создавать левый проект
Вы пробовали что-то продвинуть в mainstream? У меня есть опыт - и патчи psi+ в psi очень медленно, и в taglib довольно долго патч в пакет добавляется.
А тут вы хотите изменить идеологию работы PDO - подумайте, сколько геморроя это доставит.
Насчет десятка человек - dklab.ru довольно известный сайт среди русских php разработчиков, довольно популярная библиотека.

Ответить | Правка | Наверх | Cообщить модератору

70. "bind" +/–

Сообщение от Аноним (-), 17-Июн-10, 14:15

>Вы пробовали что-то продвинуть в mainstream?
Я пробовал принимать в mainstream :-)

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

87. "bind" +/–

Сообщение от Sw00p aka Jerom (?), 17-Июн-10, 20:48

Release Date        2006-06-02

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

67. "bind" +/–

Сообщение от Аноним (-), 17-Июн-10, 13:47

Не вижу проблем писать код вида (псевдокод):
$conn->query("SELECT * FROM table WHERE fname='".$conn->quote($fname)."'";
Меня ни разу не обламывает экранировать переменные. Хотя, тут больше приходятся полагаться на внимание разработчика. Но, неужели сложно экранировать ВСЕ переменные, если нет уверенности в разработчике? Просто принять это как договорённость при разаработке проекта. А за неэкранированные больно бить по гениталиям.
ИМХО, компактней, чем bind. Но о вкусах не спорят. ) Bind тоже катит. )

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

75. "bind" +/–

Сообщение от Cobold (??), 17-Июн-10, 16:13

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

Ответить | Правка | Наверх | Cообщить модератору

79. "bind" +/–

Сообщение от ivan1986 (?), 17-Июн-10, 16:42

Да, все правильно.
По сути этоиу правилу удовлетворяет PDO, а симпла, про которую я писал выше - это доведенное до нормального интерфейса PDO.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

14. "bind"	+5 +/–
Сообщение от tonnzor (?), 17-Июн-10, 01:45
Во всех нормальных библиотеках это происходит и так (псевдокод): $query = parse("select * from users where id = :users") $query->bind('users', $users); $query->execute(); И в MySQL, и в Oracle такое есть.
Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "bind"	+/–
	Сообщение от filosofem (ok), 17-Июн-10, 01:59
	Автор это объясняет тем, что ни один програмер не пишет параметризированные запросы, кроме как под дулом пистолета. Якобы это сложнее, чем его костыль. Не исключено, что в некоторых случаях так и есть. Или например когда сервер достался от некрофилов с каким-нибудь php4.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "bind"	+3 +/–
	Сообщение от Sabitov (?), 17-Июн-10, 06:51
	Фигня :) Параметризованные запросы сильно ускоряют работу при использовании нормальных СУБД, даже безотносительно к безопасности. Кодеры, которые не используют таких запросов, должны лишаться ЗП в обязательном порядке! :) К сожалению, пыхпых 5 не умеет их поддерживать, если используется mysql, а не mysqli :( Но это уже другая песня.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "bind"	+/–
	Сообщение от filosofem (ok), 17-Июн-10, 08:22
	Зачем mysqli да, если есть выбор пиши под постгрес, не пожалеешь. =) И автора не обижайте, уверен, что он пошутил, насчет "никто не пишет".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "bind"	+1 +/–
	Сообщение от Pashugan (?), 17-Июн-10, 13:07
	Раз уж пошла такая пьянка... Есть неочевидный фактор, который заставляет меня усомниться в справедливости Вашей зарплаты. ;) Время выполнения запроса к типичному веб-приложению - доли секунды. Если оно реализовано на скриптовых языках по стандартной схеме типа apache+mod_php5, то через эту долю секунды процесс умирает вместе со всеми объектами параметризированных запросов, и они будут создаваться заново при каждом новом запросе. Количество использований каждого из prepared statements (речь ведь идёт о них?) в таком приложении будет скорее всего равно 1. Более того, так и должно быть, мы ведь не делаем селекты в цикле, верно? :) Соответственно, те выгоды, о которых Вы говорите, проявляются лишь в приложениях, которые непрерывно висят в памяти и не собирают контекст на каждый чих, будь то java-сервлеты или скрипты+fastcgi. Я замерял, биндинг mysqli проигрывал примерно на 30% конкатенации+mysql_real_escape_string(), хотя эта цифра может служить для ориентировки.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	80. "bind"	–1 +/–
	Сообщение от аноним (?), 17-Июн-10, 17:19
	>Раз уж пошла такая пьянка... Есть не очевидный фактор, который заставляет меня усомниться в справедливости Вашей зарплаты. ;) Ты написал тупость, которая даже в мена костыле MySQL уже не соответствует действительности ... Простой вопрос на засыпку, что происходит (в нормальных DBMS) после того как парсер разобрал параметризованный запрос, но до того как ты забиндил значение и позвал экзекутор? Подсказка: ну хорошо - позвал ты экзекутор, что происходит дальше? Вот - вот, семь раз RTFM - один раз ... :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "bind"	+1 +/–
	Сообщение от Ivan1986 (?), 17-Июн-10, 20:35
	Вообще написал он правильно - разница в скорости выполнения минимальна. Вызов функций биндинга даже чуть подороже, чем склейка строки + эскейпинг. Вобщем мы от этого отказались еще года два назад, когда только написал для симплы драйвер PDO, сначала написал с биндингом параметров, потом поставил опцию раскрытия симплой - получилось быстрее. Разумеется это не относится к циклу одинаковых запросов, но это настолько редкая ситуация, что смысла нету.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	92. "bind"	+1 +/–
	Сообщение от onk (?), 18-Июн-10, 11:44
	Вы в корне не правы (или правы в некотором частном случае)! может быть для MySQL это и правда, но приличные СУБД (в частности Oracle) _кешируют_ запросы после парсинга. в итоге запрос повторно разбирать не нужно! собственно число запросов в приложении конечно и при достаточном обьеме кеша у СУБД это неплого ускоряет работу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	94. "bind"	+/–
	Сообщение от Pashugan (?), 18-Июн-10, 14:52
	>Вы в корне не правы (или правы в некотором частном случае)! >может быть для MySQL это и правда, но приличные СУБД (в частности >Oracle) _кешируют_ запросы после парсинга. в итоге запрос повторно разбирать не >нужно! >собственно число запросов в приложении конечно и при достаточном обьеме кеша у >СУБД это неплого ускоряет работу. Так ли в корне он неправ? Помимо времени на компиляцию запроса есть ещё фактор двойной передачи данных - запроса и параметров. Скорее всего, вычисление ключа кеша осуществляется на сервере, а значит текст запроса всё равно нужно сначала передать на сервер. Так что продолжать спорить считаю бессмысленным, и если у Вас есть под рукой Oracle с быстрым надёжным каналом до него, буду рад увидеть результаты тестов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	93. "bind"	+/–
	Сообщение от Pashugan (?), 18-Июн-10, 14:39
	Я знаю, что правильно написал, потому что проверял это реальными тестами mysqli, а не просто занимался упражнениями в красноречии. :) Также я всегда готов выслушать обоснованные возражения и по-нормальному поспорить, чтобы докопаться до истины, но не вижу смысла отвечать анонимусам, которые готовы только гадить на голову коллег по цеху, но по существу вопроса ничего не пишут. :)
	Ответить \| Правка \| К родителю #86 \| Наверх \| Cообщить модератору


	97. "bind"	+1 +/–
	Сообщение от tupka (?), 18-Июн-10, 19:34
	>Вот - вот, семь раз RTFM - один раз ... :) Семь раз RTFM, один раз rm -rf :D
	Ответить \| Правка \| К родителю #80 \| Наверх \| Cообщить модератору


	30. "bind"	+1 +/–
	Сообщение от Ivan1986 (?), 17-Июн-10, 09:08
	Полная чушь, если нормально реализовано, то никто просто не захочет писать не параметризованные запросы, так как они сильно упрощают код. В PDO как раз реализовано не нормально - синтаксис многословный. Посмотрите как реализовано тут - http://dklab.ru/lib/DbSimple/ $db->select('select * from table where fname=? {AND id IN (?a)}', 'user', array(1,2,3)); После использования такого синтаксиса как раз писать по старому будешь только под дулом пистолета.
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	33. "bind"	+/–
	Сообщение от Lain_13 (?), 17-Июн-10, 09:44
	Вся прелесть параметризованных запросов как-то в миг рушится, когда параметром оказывается часть имени таблицы. Ещё хуже, когда перестраиваются фрагменты запроса и в нём появляются/исчезают вложенные подзапросы и уровни вложенности этих запросов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "bind"	+1 +/–
	Сообщение от ivan1986 (?), 17-Июн-10, 10:06
	Сходите по ссылке 'select * from ?_table' - префикс - по сути самый часто используемый вариант 'select * from ?# where ...', 'tbl' - имя Вложенные подзапросы тоже есть, плюс в новой версии на форуме есть плейсхолдер подзапроса, можно творить такое, что я уже не знаю что туда можно добавить. http://forum.dklab.ru/viewtopic.php?p=180253#180253 К сожалению либа была заброшена немного, но сейчас в составе фреймворка развивается https://sourceforge.net/projects/quickfw/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "bind"	+1 +/–
	Сообщение от аноним (?), 17-Июн-10, 17:24
	>Сходите по ссылке >'select * from ?_table' - префикс - по сути самый часто используемый вариант Дык кто бы сомневался - творчеВство пехепешников - оно вообще вштыряет не по детски. То что такими гениальными запросами ставится на колени любая субд на любом железе уже "не проблемма кодера" да? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "bind"	+/–
	Сообщение от filosofem (ok), 17-Июн-10, 11:17
	Что именно чушь? Если СУБД не поддерживает параметризированные запросы, то никакой API их не сделает. Как вы собираетесь писать параметризированные запросы к какой-нибудь MSSQL 2k, или как вы будете делать аудит кода на php4, переписывать полностью на php5? ИМХО чушь это использовать на продакшне непонятные ноунэйм библиотеки. Вы проверяли, что эта DbSimple действительно делает параметризированные запросы? А вы уверены, что она так со всеми запросами будет делать? Или, что в ней нет многолетней дыры, которую просто некому заделывать, потому что никому не надо? То что в API выглядит запросом с параметрами, к СУБД может идти обычной строкой.
	Ответить \| Правка \| К родителю #30 \| Наверх \| Cообщить модератору


	44. "bind"	+/–
	Сообщение от ivan1986 (?), 17-Июн-10, 11:25
	Я ее дописывал, а не только проверял. Что может - использует встроенные параметризации, что нет - раскрывает и сама экранирует. В случае, если параметры не поддерживаются, то конечно идет обычной экранируемой строкой. Почему-то в PDO нету подстановки в качестве параметров массивов, идентификаторов, и прочих полезных вещей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "bind"	+/–
	Сообщение от Аноним (-), 17-Июн-10, 11:33
	>Я ее дописывал, а не только проверял. >Что может - использует встроенные параметризации, что нет - раскрывает и сама >экранирует. >В случае, если параметры не поддерживаются, то конечно идет обычной экранируемой строкой. > >Почему-то в PDO нету подстановки в качестве параметров массивов, идентификаторов, и прочих >полезных вещей. А вам не кажется, что использование "черного ящика", который то экранирует то параметоризирует, распускает разработчика, который начинает излишне доверять сторонней библиотеки, но по сути курит на бочке с порохом ? Я бы не стал доверять внешнему универсальному коду экранирования, например, дыры с недоэкранированием при передачи битого unicode классический пример, что и на старуху бывает проруха.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "bind"	+/–
	Сообщение от ivan1986 (?), 17-Июн-10, 11:44
	А вам не кажется, что придумывание своего велосипеда, который хоть и известен до каждого винтика, но как всегда получится с квадратными колесами (доказано огромным количеством примером - столько CMS/форумов/фреймворков приделают в качестве доступа к базе такую фигню, что за голову берешься), взяли бы хоть PDO, и то лучше было бы. Экранируется кстати стандартными функциями - mysql_real_escape в случае mysql, pdo::quote в случае PDO, и так далее.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "bind"	+/–
	Сообщение от Аноним (-), 17-Июн-10, 11:49
	>Экранируется кстати стандартными функциями - mysql_real_escape в случае mysql, Вот видите, вы сами подтвердили мою гипотезу о том, что не стоит доверять внешним универсальным решениям. Я как раз упоминал о хитрых методах обхода экранирование через многобайтовые кодировки, о которых разработчики разных функций проверки не догадывались. http://secunia.com/advisories/20365/ "The vulnerability is caused due to an error within the server when parsing a query string that is escaped with the "mysql_real_escape_string()" function. This can potentially be exploited in an environment that uses multi-byte character encoding to bypass SQL injection escaping."
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "bind"	+1 +/–
	Сообщение от ivan1986 (?), 17-Июн-10, 11:59
	Вы только что доказали, что вы "Аналитик с лора" Тоесть вы предлагаете экранировать самому - в результате допустить еще неизвестно какие баги, но жутко бояться уже пофикшенного давным давно бага. SQL injection vulnerability in MySQL 4.1.x before 4.1.20 and 5.0.x before 5.0.22 Аналитик, такой аналитик.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "bind"	+1 +/–
	Сообщение от Аноним (-), 17-Июн-10, 12:17
	Я предлагаю не испытывать излишнего доверия к "черным ящикам", так как в этом лишнем звене могут быть дыры. Если пользователи "mysql_real_escape_string()" увидят появление узявимости, то пользователи вашего черного ящика могут догадаться о ней только по косвенным признакам или после аудита кода. И не факт, что дыру в "черном ящике" автор исправит на следующий день, она может годами висеть незамеченной. PS. Вы скатились до личных оскорблений, не имея аргументов для возражения. Посему считаю дискуссию законченной.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "bind"	+/–
	Сообщение от ivan1986 (?), 17-Июн-10, 12:34
	Понятно, позиция называется - пишем на ассемблере все. Вы сейчас несете чушь - использование стандартных функций там, где можно - лучше, чем писать свои, которые реализуют ту-же самую функциональность. Если исправят баг в основной, то баг исправится и тут, а вот если бы был сделан велосипед, который предложили вы, то он как раз бы и висел бы годами не найденный. Излишнего доверия к "черным ящикам" никто не испытывает, более того код тут открыт, и даже пару багов было найдено и исправлено. Стандартный функционал mysql_* функций совершенно не подходит, поэтому и была изначально написана эта библиотека, потом появился php5 с PDO, функциональность которого была лучше, но тоже не совсем устраивала, но для него был написан адаптер, который использует эту функциональность. Вот если PDO или что-то еще разовьется до того уровня, чтобы предоставить аналогичную функциональность, то тогда эта библиотека будет не нужна, вот только когда это будет, и будет ли вообще :) Оскорблений не было, это констатация факта :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "bind"	+/–
	Сообщение от Аноним (-), 17-Июн-10, 13:11
	>Вы сейчас несете чушь - использование стандартных функций там, где можно - >лучше, чем писать свои, которые реализуют ту-же самую функциональность. Стоп, это же именно вы предлагайте использовать левую нестандартную библиотеку вместо стандартных функций экранирования PHP. >Если исправят баг в основной, то баг исправится и тут, Если автор левой библиотеки, которой пользуются 10 человек, не забросит свой проект. Посмотрите последние обновления безопасности в RHEL, там поправили дыры годичной давности, как раз в библиотеках, подобных вашей. >Стандартный функционал mysql_* функций совершенно не подходит, поэтому и была изначально написана >эта библиотека, потом появился php5 с PDO, функциональность которого была лучше, Вот и надо было продвигать идеи в mainstream, а не создавать левый проект, использование которого целесообразно только для людей, принимающих участие в его разработке.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "bind"	+/–
	Сообщение от ivan1986 (?), 17-Июн-10, 13:22
	Нет, я как раз предлагаю использовать стандартные функции - в случае mysql - mysql_real_escape_string, в случае PDO - PDO::escape, а вы тут ругаетесь на то что раз она бажная, то нужно написать свою обертку. >Вот и надо было продвигать идеи в mainstream, а не создавать левый проект Вы пробовали что-то продвинуть в mainstream? У меня есть опыт - и патчи psi+ в psi очень медленно, и в taglib довольно долго патч в пакет добавляется. А тут вы хотите изменить идеологию работы PDO - подумайте, сколько геморроя это доставит. Насчет десятка человек - dklab.ru довольно известный сайт среди русских php разработчиков, довольно популярная библиотека.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "bind"	+/–
	Сообщение от Аноним (-), 17-Июн-10, 14:15
	>Вы пробовали что-то продвинуть в mainstream? Я пробовал принимать в mainstream :-)
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	87. "bind"	+/–
	Сообщение от Sw00p aka Jerom (?), 17-Июн-10, 20:48
	Release Date 2006-06-02
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	67. "bind"	+/–
	Сообщение от Аноним (-), 17-Июн-10, 13:47
	Не вижу проблем писать код вида (псевдокод): $conn->query("SELECT * FROM table WHERE fname='".$conn->quote($fname)."'"; Меня ни разу не обламывает экранировать переменные. Хотя, тут больше приходятся полагаться на внимание разработчика. Но, неужели сложно экранировать ВСЕ переменные, если нет уверенности в разработчике? Просто принять это как договорённость при разаработке проекта. А за неэкранированные больно бить по гениталиям. ИМХО, компактней, чем bind. Но о вкусах не спорят. ) Bind тоже катит. )
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	75. "bind"	+/–
	Сообщение от Cobold (??), 17-Июн-10, 16:13
	вот тут-то как раз собака и порылась - если использовать биндинг то параметры всегда экранированы, совсем без участия разработчика, а если полагаться на экранирование "по ходу", то разработчик постоянно должен об этом думать (будто ему больше заняться нечем). В проекте с тысячами запросов это просто нереально, будь программисты хоть абсолютные педанты, кто угодно может забыть или просмотреть что-то. И случается это часто как раз в таких местах где визуально не сразу и заметишь, так что полагаться на то что другие коллеги обнаружат тоже нельзя. Поэтому такие дыры лучше ищутся автоматизированно, но тогда это уже аудит называется и стоит отдельно. Или жить с риском что кто-нибудь сделает это за тебя, но только тогда этот кто-то может отверстием сразу и попользоваться. А оно надо, весь этот гемморой?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "bind"	+/–
	Сообщение от ivan1986 (?), 17-Июн-10, 16:42
	Да, все правильно. По сути этоиу правилу удовлетворяет PDO, а симпла, про которую я писал выше - это доведенное до нормального интерфейса PDO.
	Ответить \| Правка \| Наверх \| Cообщить модератору