forum.opennet.ru - "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." (97)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."

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

"Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
Сообщение от opennews (??) on 17-Июн-10, 00:40
Ден Каминский (Dan Kaminsky (http://en.wikipedia.org/wiki/Dan_Kaminsky)), получивший известность обнаружением фундаментальной уязвимости в DNS, представил (http://recursion.com/interpolique.html) универсальную технику защиты от "SQL Injection" (подстановка SQL-запросов) и XSS (межсайтовый скриптинг) атак. Суть техники защиты от подстановки SQL-запросов в том, что при работе с пользовательскими данными в запросе к СУБД фигурируют не открытые данные, а строка в base64-представлении, в которой изначально отсутствуют спецсимволы. В отличие от традиционной практики анализа вводимых пользователем данных и экранирования опасных символов перед формированием запроса, метод Каминского по своей сути исключает человеческий фактор и возможность недосмотра при проверке. Для наглядности рассмотрим пример. Допустим в программе имеется строка <font color="#461b7e"> $conn->query("select * from table where fname=$fname;");</font> в случае отсутствия должных проверок в переменной $fname мо... URL: http://www.darkreading.com/database_security/security/app-se... Новость: https://www.opennet.ru/opennews/art.shtml?num=26997
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 00:40 , 17-Июн-10, (1) –8

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., XoRe, 00:49 , 17-Июн-10, (3) +2
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 21:26 , 18-Июн-10, (98) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Kibab, 09:34 , 21-Июн-10, (102)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., XoRe, 00:42 , 17-Июн-10, (2) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., _Vitaly_, 01:14 , 17-Июн-10, (7) +4

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 04:23 , 17-Июн-10, (19) +2

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., zazik, 10:30 , 17-Июн-10, (41)
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., _Vitaly_, 12:19 , 17-Июн-10, (56) +3

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., XoRe, 11:24 , 18-Июн-10, (91) +4

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., _Vitaly_, 00:15 , 20-Июн-10, (100)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ffsdmad, 01:00 , 17-Июн-10, (4) –1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Alex, 01:16 , 17-Июн-10, (8) –1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ffsdmad, 01:20 , 17-Июн-10, (10) –2

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ffsdmad, 01:22 , 17-Июн-10, (11) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 05:15 , 17-Июн-10, (24) +3

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 04:27 , 17-Июн-10, (20) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ссс, 01:03 , 17-Июн-10, (5) –1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ffsdmad, 01:04 , 17-Июн-10, (6)
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., аноним, 01:43 , 17-Июн-10, (12) +2
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 04:32 , 17-Июн-10, (22) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., vvvua, 01:18 , 17-Июн-10, (9) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., аноним, 01:44 , 17-Июн-10, (13) –1
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 01:57 , 17-Июн-10, (15)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 04:34 , 17-Июн-10, (23)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., pento, 02:01 , 17-Июн-10, (17)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Gambler, 03:02 , 17-Июн-10, (18) +1
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., vvvua, 14:55 , 17-Июн-10, (72)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., pento, 15:52 , 17-Июн-10, (74)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., vvvua, 16:02 , 18-Июн-10, (96)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., аноним, 06:39 , 17-Июн-10, (25) –5
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., FractalizeR, 10:26 , 17-Июн-10, (39) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., vvvua, 14:48 , 17-Июн-10, (71) –1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., FractalizeR, 14:57 , 17-Июн-10, (73) +1

bind, tonnzor, 01:45 , 17-Июн-10, (14) +5

bind, filosofem, 01:59 , 17-Июн-10, (16)

bind, Sabitov, 06:51 , 17-Июн-10, (27) +3

bind, filosofem, 08:22 , 17-Июн-10, (29)
bind, Pashugan, 13:07 , 17-Июн-10, (61) +1

bind, аноним, 17:19 , 17-Июн-10, (80) –1

bind, Ivan1986, 20:35 , 17-Июн-10, (86) +1

bind, onk, 11:44 , 18-Июн-10, (92) +1

bind, Pashugan, 14:52 , 18-Июн-10, (94)

bind, Pashugan, 14:39 , 18-Июн-10, (93)

bind, tupka, 19:34 , 18-Июн-10, (97) +1

bind, Ivan1986, 09:08 , 17-Июн-10, (30) +1

bind, Lain_13, 09:44 , 17-Июн-10, (33)

bind, ivan1986, 10:06 , 17-Июн-10, (37) +1

bind, аноним, 17:24 , 17-Июн-10, (81) +1

bind, filosofem, 11:17 , 17-Июн-10, (43)

bind, ivan1986, 11:25 , 17-Июн-10, (44)

bind, Аноним, 11:33 , 17-Июн-10, (46)

bind, ivan1986, 11:44 , 17-Июн-10, (48)

bind, Аноним, 11:49 , 17-Июн-10, (50)

bind, ivan1986, 11:59 , 17-Июн-10, (52) +1

bind, Аноним, 12:17 , 17-Июн-10, (55) +1

bind, ivan1986, 12:34 , 17-Июн-10, (57)

bind, Аноним, 13:11 , 17-Июн-10, (63)
bind, ivan1986, 13:22 , 17-Июн-10, (65)
bind, Аноним, 14:15 , 17-Июн-10, (70)

bind, Sw00p aka Jerom, 20:48 , 17-Июн-10, (87)

bind, Аноним, 13:47 , 17-Июн-10, (67)

bind, Cobold, 16:13 , 17-Июн-10, (75)

bind, ivan1986, 16:42 , 17-Июн-10, (79)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 06:39 , 17-Июн-10, (26) +1
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., anthonio, 09:24 , 17-Июн-10, (31)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 09:52 , 17-Июн-10, (35)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., anthonio, 10:01 , 17-Июн-10, (36)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., FractalizeR, 10:27 , 17-Июн-10, (40) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 10:20 , 17-Июн-10, (38) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 11:25 , 17-Июн-10, (45)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 11:47 , 17-Июн-10, (49)
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 11:53 , 17-Июн-10, (51)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Slautin, 09:27 , 17-Июн-10, (32) +1

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Cobold, 12:15 , 17-Июн-10, (54)
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Pashugan, 13:11 , 17-Июн-10, (62)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Slautin, 09:22 , 18-Июн-10, (90)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Pashugan, 15:35 , 18-Июн-10, (95)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ixti, 11:15 , 17-Июн-10, (42)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Gambler, 04:21 , 18-Июн-10, (89)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., zuborg, 11:34 , 17-Июн-10, (47)
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Cobold, 12:06 , 17-Июн-10, (53) +1
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., terr0rist, 12:42 , 17-Июн-10, (58)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 12:53 , 17-Июн-10, (59)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Cobold, 13:17 , 17-Июн-10, (64)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 13:25 , 17-Июн-10, (66)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Cobold, 13:05 , 17-Июн-10, (60) +1
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., noname, 22:13 , 21-Июн-10, (103)
Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Kibab, 19:49 , 22-Июн-10, (104)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Аноним, 14:02 , 17-Июн-10, (69)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 16:38 , 17-Июн-10, (78)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., Aleksey, 16:24 , 17-Июн-10, (76)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., ivan1986, 16:34 , 17-Июн-10, (77)

Очень старый ::, anonymous, 18:38 , 17-Июн-10, (83)

Очень старый ::, anonymous, 18:40 , 17-Июн-10, (84)

Кардинальный метод защиты от XSS и атак по подстановке SQL-з..., StrangeAttractor, 21:27 , 18-Июн-10, (99)
Здесь Дэн облажался, RinNas, 12:48 , 30-Июл-10, (105)

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

1. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –8 +/–

Сообщение от Аноним (??) on 17-Июн-10, 00:40

Зачем это?
А внешних кавычек ($conn->query("select * from table where fname=\"$fname\";");) и isset($fname) недостаточно?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +2 +/–

Сообщение от XoRe (ok) on 17-Июн-10, 00:49

>А внешних кавычек ($conn->query("select * from table where fname=\"$fname\";");) и isset($fname) недостаточно?
$fname = 'xxx"; delete from table; select "goodbye';
$conn->query("select * from table where fname=\"$fname\";");
Подставьте вместо table - название имеющейся таблицы и запустите у себя в базе данных.
Хотя, не знаю, выполнит ли он все три запроса - это уже зависит от языка, интерфейса к БД и т.д.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

98. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от Аноним (??) on 18-Июн-10, 21:26

> Зачем это?
> А внешних кавычек ($conn->query("select * from table where fname=\"$fname\";");) и
> isset($fname) недостаточно?
PHP-программисты такие програссимты...
ясное дело что подставление ковычек -- НЕ запускает процесс экранирования :-D !
в Python DB-API-2.0 -- всё сделано для людей:
c.execute('SELECT * FROM stocks WHERE symbol=?', (symbol,))
вот вам и решение проблемы с безопасностью от инъекций

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

102. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Kibab (ok) on 21-Июн-10, 09:34

В PHP достаточно юзать PDO и bindColumn()-методы для достижения того же самого результата. Сделано для людей (с) Вы.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от XoRe (ok) on 17-Июн-10, 00:42

Очень интересно.
Просто и гениально.
Хотя все сводится к тому, что программисты в обязательном порядке станут писать код для обработки данных в sql запросе.
Пусть даже в автоматическом режиме, благодаря врапперу.
Но идея хороша.
Увеличение размера переменных на 30% - фигня по сравнению с безопасностью.
P.S.
$conn->query("select * from table where fname=$fname;");
А так пишут?
Без парсинга переменной и без кавычек?)
UPD:
По комментарию выше понял, что пишут =)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +4 +/–

Сообщение от _Vitaly_ (ok) on 17-Июн-10, 01:14

По-моему он экранирование переизобрел.
И даже если принять синтаксис ^^, непонятно зачем парсером заворачивать аж в base64 вместо добавления слешей.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +2 +/–

Сообщение от Аноним (??) on 17-Июн-10, 04:23

>По-моему он экранирование переизобрел.
В том-то и дело, что экранировать сплошь и рядом забывают или криво экранируют, поэтому тоннами и всплывают SQL Injection, даже во вполне больших проектах, в которых и разработчики не дураки и аудит проводится.
http://secunia.com/advisories/search/?search=sql+injection

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

41. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от zazik (ok) on 17-Июн-10, 10:30

А ещё можно экранировать при включенном автоэкранировании, тоже весело. Так что единственно верный подход - писать нормальный, безопасный код.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

56. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +3 +/–

Сообщение от _Vitaly_ (ok) on 17-Июн-10, 12:19

Когда разработчики не дураки, обычно запросы идут через прослойку, которая автоматически приведение типов и экранирование выполняет.
И тем не менее, вопрос о необходимости base64 остается открытым. Преимуществ перед слешами я пока не вижу, зато радостей по совместимости и изучению крякозябликов в логах будет вагон.
А сама мысль о выделении переменных ^^ интересная, согласен.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

91. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +4 +/–

Сообщение от XoRe (ok) on 18-Июн-10, 11:24

>Когда разработчики не дураки, обычно запросы идут через прослойку, которая автоматически приведение
>типов и экранирование выполняет.
>
>И тем не менее, вопрос о необходимости base64 остается открытым. Преимуществ перед
>слешами я пока не вижу, зато радостей по совместимости и изучению
>крякозябликов в логах будет вагон.
>
>А сама мысль о выделении переменных ^^ интересная, согласен.
Да суть-то в другом.
Чтобы была схема:
юзер что-то ввел в форму - оно кодируется в base64 (на стороне клиента, а лучше - на стороне сервера) - передается в sql запрос в виде base64 - sql запрос уже сам декодирует и впихивает в поле.
При такой схеме sql-injection не возможен в принципе.
Можно не беспокоиться об экранировании и приведении типов.
Вообще пох, что там введет юзер.
Хоть бинарные данные, символы с ascii номерами 0-31.
Единственное, что нужно проверять - это размер строки.
Но это уже из другой логики - из области переполнения буфера)
Кстати, всякие шеллкоды тоже не смогут пробраться, если на стороне сервера все приходящие переменные сразу кодировать в base64.
Поэтому идея гениальна своей простотой и эффективностью.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

100. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от _Vitaly_ (ok) on 20-Июн-10, 00:15

Теперь просек. Действительно хороший выход для тех, кто без врапперов пишет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –1 +/–

Сообщение от ffsdmad (ok) on 17-Июн-10, 01:00

идея конечно гениальна
НО
если у меня в базе будут base64 закодированные данные, то select * from table where like '%query%' работать просто не будет и мне скажут нах.. зачем нам база без поиска?
а если не хранить в base64 то смысла нет, так как подставить под base64 кавычки или join ни кто не мешает
а для DNS хакера эта идея конечно хороша

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –1 +/–

Сообщение от Alex (??) on 17-Июн-10, 01:16

Base64 передается в только в запросе, завернутый в вызов функции преобразования.
В базе хранится обычный текст, естественно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –2 +/–

Сообщение от ffsdmad (ok) on 17-Июн-10, 01:20

а какой смысл если после декодирования в запросе появится лишняя кавычка или join ?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от ffsdmad (ok) on 17-Июн-10, 01:22

>а какой смысл если после декодирования в запросе появится лишняя кавычка или
>join ?
либо это должно быть встроено в субд, всмысле врапер, чтобы раскодированная строка уже не парсилась

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

24. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +3 +/–

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

само собой, base64 декодируется уже внутри СУБД, средствами субд и представляет из себя только сроку, а не команду.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от Аноним (??) on 17-Июн-10, 04:27

>а если не хранить в base64 то смысла нет, так как подставить
>под base64 кавычки или join ни кто не мешает
base64 всегда буквы и цифры, т.е. чтобы не делал в запросе всегда будут буквы и цифры, никаких кавычек не появятся. Посмотрите пример, к БД всегда уходят запросы типа fname=b64d("abc"), где abc строка в base64 формате, хоть ты туда изначально !@#$%^&* поместишь.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –1 +/–

Сообщение от ссс on 17-Июн-10, 01:03

непонятно, так если я введу например через веб-форму "' or '%" в переменную $fname, он закодирует мою инъекцию, раскодирует и выполнит мой код ВСЁ РАВНО. в чем прикол?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ffsdmad (ok) on 17-Июн-10, 01:04

... получивший известность обнаружением фундаментальной уязвимости в ...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +2 +/–

Сообщение от аноним on 17-Июн-10, 01:43

Не выполнит.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от Аноним (??) on 17-Июн-10, 04:32

>непонятно, так если я введу например через веб-форму "' or '%" в
>переменную $fname, он закодирует мою инъекцию, раскодирует и выполнит мой код
>ВСЁ РАВНО. в чем прикол?
В запросе к базе будет вместо вашего "' or '%" - b64d("DSSDDQEd="), и уже СУБД декодирует DSSDDQEd= и будет воспринимать "' or '%" как константу, а не часть запроса.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от vvvua (ok) on 17-Июн-10, 01:18

А 2 года назад меня пытались заплевать...
http://sql.ru/forum/actualthread.aspx?tid=616602

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –1 +/–

Сообщение от аноним on 17-Июн-10, 01:44

>А 2 года назад меня пытались заплевать...
>http://sql.ru/forum/actualthread.aspx?tid=616602
А тебя и сейчас за это заплюют и правильно сделают.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Аноним (??) on 17-Июн-10, 01:57

Вы предгагаете сделать так:
INSERT INTO table .. VALUES('_base64_enoded_string_');
он предлагает:
INSERT INTO table .. VALUES(base64_decode('_base64_enoded_string_'));
Соответственно в вашем случае хранинся - b64, в его - чистый текст.
Но, да, его вариант решает пробоему SQL-Inj ( по сути - проблему разбора SQL-запросов).
Хотя, ихмо, использование подстановок с один раз написанным и отлаженным экранированием работает не хуже.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Аноним (??) on 17-Июн-10, 04:34

>Но, да, его вариант решает пробоему SQL-Inj ( по сути - проблему
>разбора SQL-запросов).
>Хотя, ихмо, использование подстановок с один раз написанным и отлаженным экранированием работает
>не хуже.
Практика показывает, что экранирование под давлением человеческого фактора совсем не работает, даже в Joomla криво экранируют и mod_security не помогает.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от pento on 17-Июн-10, 02:01

И правильно заплевали.
Ваше решение из разряда защитимся от XSS и для этого всё в базу будем ложить уже с заменой на HTML-мнемоники, тем самым портя данные. Это архитектурная ошибка может вам встать боком в самый неподходящий момент.
Предложение Камински интересно, но не более. Не особо много преимуществ по сравнению с параметризованными запросами, а если у вас используется нормальный ORM, то такой проблемы вообще нет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от Gambler (ok) on 17-Июн-10, 03:02

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

72. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от vvvua (ok) on 17-Июн-10, 14:55

>И правильно заплевали.
>Ваше решение из разряда защитимся от XSS и для этого всё в
>базу будем ложить уже с заменой на HTML-мнемоники, тем самым портя
>данные. Это архитектурная ошибка может вам встать боком в самый неподходящий
>момент.
Вы ошиблись. Я не от XSS защищал, а от SQL injection. Это разные вещи. Кроме того, моё приложение на момент разработки ни имело ни малейшего отношения к HTML.
И замена на HTML мнемоники не равноценна замене на base64, т.к. base64 не нарушает целостность данных.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

74. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от pento (ok) on 17-Июн-10, 15:52

>[оверквотинг удален]
>>Ваше решение из разряда защитимся от XSS и для этого всё в
>>базу будем ложить уже с заменой на HTML-мнемоники, тем самым портя
>>данные. Это архитектурная ошибка может вам встать боком в самый неподходящий
>>момент.
>
>Вы ошиблись. Я не от XSS защищал, а от SQL injection. Это
>разные вещи. Кроме того, моё приложение на момент разработки ни имело
>ни малейшего отношения к HTML.
>И замена на HTML мнемоники не равноценна замене на base64, т.к. base64
>не нарушает целостность данных.
1. Я в курсе того, чем отличаются XSS от SQL-инъекции
2. Про замену на мнемоники..есть некоторые разработчики, которые сразу в базу ложат текст, в котором все HTML-спец.символы заменены на мнемоники. у вас аналогичное решение, только уже с base64.  Просто что ваш, что методы Камински - по сути костыльные решения.
И во многом надуманные. Его аргумент, что программисты только под дулом пистолета могут использовать параметризированные запросы вообще не выдерживает критики.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

96. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от vvvua (ok) on 18-Июн-10, 16:02

На счет костыльного решения - 100%. Что моё, что Камински.
Я не приветствую решения, которые замедляют (читай увеличивают нагрузку на CPU) работу отдельных функций СУБД. Вот если создать работу со специндексами в самой СУБД (например, для полнотекстового поиска в кодировке base64 или подобной), которые будут работать не медленнее существующих - это уже будет не костыль, а фича!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

25. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –5 +/–

Сообщение от аноним on 17-Июн-10, 06:39

Лол! Base64 в целях безопасности, такого еще не было.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

39. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от FractalizeR (ok) on 17-Июн-10, 10:26

Вы предлагали совсем другое. Глупо хранить в базе все строки в base64.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

71. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." –1 +/–

Сообщение от vvvua (ok) on 17-Июн-10, 14:48

>Вы предлагали совсем другое. Глупо хранить в базе все строки в base64.
Как по мне, похожее предложение. Да, другая проверка на соответствие base64.
На счёт глупо или нет - практика показала, что затруднен только полнотекстовый поиск (или частичный, как кому угодно). Всунуть мне левый запрос в принципе невозможно - я проверяю в приложении,которое работает с базой, на base64 соответствие.
Кроме того, я не предлагал ВСЕ текстовые строки хранить в base64. Только те, которые участвуют в запросах из общедоступных приложений или сторонних продуктов, чье качество кодирования проверить затруднительно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

73. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от FractalizeR (ok) on 17-Июн-10, 14:57

>>Вы предлагали совсем другое. Глупо хранить в базе все строки в base64.
>
>Как по мне, похожее предложение. Да, другая проверка на соответствие base64.
Читайте еще раз. Абсолютно не похожее.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "bind" +5 +/–

Сообщение от tonnzor on 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) on 17-Июн-10, 01:59

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "bind" +3 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

29. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

61. "bind" +1 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

80. "bind" –1 +/–

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

86. "bind" +1 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

92. "bind" +1 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

94. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

93. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

97. "bind" +1 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "bind" +1 +/–

Сообщение от Ivan1986 on 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));
После использования такого синтаксиса как раз писать по старому будешь только под дулом пистолета.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

37. "bind" +1 +/–

Сообщение от ivan1986 on 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 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

43. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

44. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

46. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

48. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

50. "bind" +/–

Сообщение от Аноним (??) on 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 on 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 +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

57. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

63. "bind" +/–

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

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

65. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

70. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

87. "bind" +/–

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

Release Date        2006-06-02

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

67. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

75. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

79. "bind" +/–

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

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от Аноним (??) on 17-Июн-10, 06:39

Вот в Постгрес есть такая тема, можно задавать любые ограничители типа $something$
тоесть писать запросы типа select * from users where name=$pipiska$Вася$pipiska$;
В похапе во входящих на всякий случай заменяем $pipiska$ на SpipiskaS и вставляем. Чем не метод?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от anthonio (ok) on 17-Июн-10, 09:24

Это всё конечно интересно, да вот только ПМСМ нормальные программеры итак заботятся о безопасности и проверяют входные данные. Кто будет пользоваться этим методом, вас много наберётся?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

35. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Аноним (??) on 17-Июн-10, 09:52

>Это всё конечно интересно, да вот только ПМСМ нормальные программеры итак заботятся
>о безопасности и проверяют входные данные. Кто будет пользоваться этим методом,
>вас много наберётся?
Только нормальный программеров раз-два и обчелся, или их код обязательно будет разбавлен кодом "ненормальных". По вашему Drupal, Typo3, phpbb, Joomla и почти любой другой крупный проект на PHP пишется спустя рукава ? Тем не менее в них регулярно находят SQL Injection и баги, связанные с отсутствием экранирования/проверки пользовательского ввода. Казалось бы получил одну такую дыру, провел аудит кода и живи спокойно, но грабли продолжают лежать, а разработчики продолжают на них наступать. Так что не все так просто как кажется, нужна именно панацея, подобная описанной в новости. Дополнительные решения типа mod_security часто остаются бесполезными или в них самих дыры всплывают.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

36. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

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

>По вашему Drupal, Typo3, phpbb, Joomla и почти любой
>другой крупный проект на PHP пишется спустя рукава ? Тем не
>менее в них регулярно находят SQL Injection и баги, связанные с
>отсутствием экранирования/проверки пользовательского ввода.
Значит пишут спустя рукава. Или это PHP виноват? :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

40. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от FractalizeR (ok) on 17-Июн-10, 10:27

>>По вашему Drupal, Typo3, phpbb, Joomla и почти любой
>>другой крупный проект на PHP пишется спустя рукава ? Тем не
>>менее в них регулярно находят SQL Injection и баги, связанные с
>>отсутствием экранирования/проверки пользовательского ввода.
>
>Значит пишут спустя рукава. Или это PHP виноват? :)
А кто мешает писать спустя рукава с использованием именно этого метода? :) Разве мало мест где багов и дыр можно навешать, кроме этой, которую заткнете?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

38. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от ivan1986 on 17-Июн-10, 10:20

Вы считаете что у друпала или у джумлы хороший код?
Блин, да достаточно посмотреть на их либы для работы с базами данных и уже понятно какие там "специалисты" сидят.
Джумла вообще такое чувство что на коленке собрана, имел счастье копаться в ее коде...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

45. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

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

>Вы считаете что у друпала или у джумлы хороший код?
>Блин, да достаточно посмотреть на их либы для работы с базами данных
>и уже понятно какие там "специалисты" сидят.
>Джумла вообще такое чувство что на коленке собрана, имел счастье копаться в
>ее коде...
Давайте пойдем от обратного, можете привести пример качественного PHP-проекта, который более-менее распространен в сети ?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

49. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ivan1986 on 17-Июн-10, 11:47

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

51. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ivan1986 on 17-Июн-10, 11:53

Вообще по части библиотеки доступа к базе данных - если при запросе к базе данных есть код вида
$var = $db->escape($var);
$db->query("..$var..");
(тоесть можно передать неэкранированные данные просто забыв их экранировать)
то это индикатор, что библиотека доступа к базе данных...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

Сообщение от Slautin on 17-Июн-10, 09:27

Безумие какое-то... workaround для безграмотности.
BTW - параметризованные запросы не просто делают код читабельным и избавляют от проблемы sql injection, но в разы (иногда в десятки раз) улучшают производительность запросов (парсинг sql, построение плана запроса...).
"о сколько нам открытий чудных готовит просвященья дух...." ((c) А.Пушкин)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

54. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Cobold (??) on 17-Июн-10, 12:15

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

62. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Pashugan on 17-Июн-10, 13:11

>BTW - параметризованные запросы не просто делают код читабельным и избавляют от
>проблемы sql injection, но в разы (иногда в десятки раз) улучшают
>производительность запросов (парсинг sql, построение плана запроса...).
>
>"о сколько нам открытий чудных готовит просвященья дух...." ((c) А.Пушкин)
Иногда да, иногда нет. :) См. комментарий #61.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

90. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Slautin on 18-Июн-10, 09:22

> Иногда да, иногда нет. :) См. комментарий #61
"нет", на мой взгляд, справедливо для очень узкого круга задач, обычно очень простых, для которых, действительно, не важна ни производительнсоть (и безопасность) ни здравый смысл.
Но задача в пределах request-а обратиться одинаковым запросом минимум дважды - типовая и характерна для сколь нибудь существенных приложений, даже не очень сложных.
ЗЫ: drupal, например, очень активно переходят на параметризованные запросы.
Видимо, стало стыдно :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

95. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Pashugan on 18-Июн-10, 15:35

:) Я как раз говорил, что в типичном скриптовом веб-приложении скорее всего будет "нет", и обращение к одному sql-запросу будет единожды. Потому что типичный http-запрос должен отработать на сервере по принципу "сделать как можно меньше и как можно быстрее умереть". Другое дело, что производительности можно достичь другими способами, а вот безопасность никогда не бывает лишней.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

42. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

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

ИМХО автор просто подошёл к проблеме интересным образом. Я не говорю, что он решил проблему в корне или что он изобрёл что-то гениальное. Просто действительно интересный вариант. И всё. Не думаю, что этот способ начнёт массово применяться в продакшене ;)) тем не менее значение его больше "а ещё это можно сделать так..."
"...It's actually a model of the prison on Robin Island where Nelson Mandela was held 27 years ... Yeah. A lot of people don't realize this, but you can put your weed in there." (c) The Hot Chick

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

89. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Gambler (ok) on 18-Июн-10, 04:21

Верно, решение интересное. Возможно, что в каких-то других областях программирования его даже применят с пользой. Но как серьезное "улучшение" защиты от SQL инжекшенов это рассматривать нельзя.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

47. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от zuborg on 17-Июн-10, 11:34

На самом деле действительно гениально и просто.
Я бы, по крайней мере, до такого точно не додумался бы, поскольку пользуюсь prepare/bind/execute.
Интересно, знает ли сам автор про биндинг переменных.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

53. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

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

совсем крыша поехала, вставлять eval и рассуждать о безопасности? Кроме того эта байда в такой форме работать не будет, надо бы на b() ещё и сами параметры передать.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

58. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от terr0rist (ok) on 17-Июн-10, 12:42

1. нифига этот метод не универсальный: а если запрос
$conn->query("select * from $table where fname=XXX;");
$table не получится base64-декодить =)
2. Если есть такие товарищи, кто пишет where fname=$fname и register_globals=on - то им уже base64 не поможет, а поможет только кастрация мозга.
3. В пхп вообще очень много универсальных решений для предотвращения sql-injection. Один magic_quotes_gpc чего стоит.
4. Выше было замечено, что даже друпал и жумла пишутся "спустя рукава". Ну а что можно написать на пхп не спустя рукава? Какой нормальный программист будет использовать эту поделку, в которой какие-то переменные конфига меняют всю суть "языка", синтаксис понадёрган из 30 разных языков и то возможности, которые были изначально в других давно существующих языках, появляются только в версии 5.3, а ещё (при программистской лени) нужно зачем-то везде ставить эти $, ->, array() и прочие идиотские излишества. Код на пхп убог по сути пхп. И единственное универсальное средство против sql-injection для пхп - это отказ от пхп.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

59. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ivan1986 on 17-Июн-10, 12:53

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

64. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

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

>[оверквотинг удален]
>не будет вам в открытый доступ выкладывать хороший код - по
>крайне мере очень редко.
>А если пишется в соответствии с идеологией олпенсорса - каждый прикрутит маленькую
>фигню, то и получается такой отстой как джумла или друпал.
>
>Фраза "даже друпал и жумла" некорректна - слово даже тут нельзя применять,
>это два примера феерически раскрученного отстоя.
>
>А язык хороший, не надо, просто на нем просто сделать криво, но
>это не значит что так нужно делать.
Зря Вы так про опенсорс, просто бывают разные модели разработки. Бывает например разработка преимущественно силами комьюнити, там действительно так и получается, а бывает часто что фирма преимущественно или полностью своими силами разрабатывает, но выкладывает в открытый доступ потому что это сегодня выгодно во многих отношениях. Или даже некоммерческие проекты, но где одна более-менее постоянная комманда и один лидер тон задаёт. Загляните в код sugarcrm, рекомендую :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

66. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ivan1986 on 17-Июн-10, 13:25

Я так не про олпенсорс вообще, а про разработку силами комьюнити.
Вот если разрабатывает одна фирма или команда получается как раз нормально.
А когда приходит "комьюнити", то получается фигня.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

60. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +1 +/–

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

как-то довелось делать аудит для чужого проекта с тремя тысячами запросами по коду, чуть не каждый третий дырявый. Так вот главный программер с этой фирмочки уверял что у него magic_quotes_gpc включен и всё защищает. Про такие вещи как "select name from user where id=$id" он не подумал, что туда можно банально подзапрос в скобках вставить :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

103. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от noname (??) on 21-Июн-10, 22:13

>4. Выше было замечено, что даже друпал и жумла пишутся "спустя рукава". Ну а что можно написать на пхп не спустя рукава? Какой нормальный программист будет использовать эту поделку, в которой какие-то переменные конфига меняют всю суть "языка", синтаксис понадёрган из 30 разных языков и то возможности, которые были изначально в других давно существующих языках, появляются только в версии 5.3, а ещё (при программистской лени) нужно зачем-то везде ставить эти $, ->, array() и прочие идиотские излишества. Код на пхп убог по сути пхп. И единственное универсальное средство против sql-injection для пхп - это отказ от пхп.
А что бы вместо пхп предпочли вы?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

104. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Kibab (ok) on 22-Июн-10, 19:49

В то время, как такие, как Вы, орут об убогости пхп на форумах, нормальные разработчики зарабатывают деньги на написанных на пхп проектах :-)
"Ах, Моська, знать, она сильна, что лает на слона..."

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

69. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

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

Ну, и ещё раз о главном (хоть, это возможно просто пример):
За $conn->query("...fname=$fname...") надо больно бить по йайцам. Хотя бы, но не ограничиваясь (!) $conn->query("...where fname=".$fname."..."). Так переменную хоть заметней.
на самом деле, это защита от неопытного/не очень грамотного кодера. Для больших проектов подойдёт.
Хорошо бы без eval'ов и чтобы (без wrapper'а не срабатывало|wrapper применялся неявно). Но, в таком случае приходим как раз к bind'у.
Короче - проект - не панацея. Тем более с eval'ами. )

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

78. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ivan1986 on 17-Июн-10, 16:38

ха-ха-ха!
За второй вариант по яйцам бить нужно так-же больно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

76. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от Aleksey (??) on 17-Июн-10, 16:24

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

77. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от ivan1986 on 17-Июн-10, 16:34

не смешно

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

83. "Очень старый ::" +/–

Сообщение от anonymous (??) on 17-Июн-10, 18:38

Способ конечно неплохой, но не всегда удобный.
Кроме того, есть ещё такая вещь как "prepared statement".

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

84. "Очень старый ::" +/–

Сообщение от anonymous (??) on 17-Июн-10, 18:40

Я хотел сказать: очень старый баян :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

99. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..." +/–

Сообщение от StrangeAttractor (ok) on 18-Июн-10, 21:27

Проблема в том, что base64 - по природе своей костыль. Если подумать, "экранировка", в общем-то, тоже. Надо копать в какую-то другую сторону, imho, отделять мух от котлет более радикально.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

105. "Здесь Дэн облажался" +/–

Сообщение от RinNas on 30-Июл-10, 12:48

base64() ничем не лучше встроенных в БД методов квотирования, а минусы есть -- декодирование для БД не родное. Здесь Дэн облажался.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

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

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

1. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	–8 +/–
Сообщение от Аноним (??) on 17-Июн-10, 00:40
Зачем это? А внешних кавычек ($conn->query("select * from table where fname=\"$fname\";");) и isset($fname) недостаточно?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+2 +/–
	Сообщение от XoRe (ok) on 17-Июн-10, 00:49
	>А внешних кавычек ($conn->query("select * from table where fname=\"$fname\";");) и isset($fname) недостаточно? $fname = 'xxx"; delete from table; select "goodbye'; $conn->query("select * from table where fname=\"$fname\";"); Подставьте вместо table - название имеющейся таблицы и запустите у себя в базе данных. Хотя, не знаю, выполнит ли он все три запроса - это уже зависит от языка, интерфейса к БД и т.д.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	98. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
	Сообщение от Аноним (??) on 18-Июн-10, 21:26
	> Зачем это? > А внешних кавычек ($conn->query("select * from table where fname=\"$fname\";");) и > isset($fname) недостаточно? PHP-программисты такие програссимты... ясное дело что подставление ковычек -- НЕ запускает процесс экранирования :-D ! в Python DB-API-2.0 -- всё сделано для людей: c.execute('SELECT * FROM stocks WHERE symbol=?', (symbol,)) вот вам и решение проблемы с безопасностью от инъекций
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	102. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от Kibab (ok) on 21-Июн-10, 09:34
	В PHP достаточно юзать PDO и bindColumn()-методы для достижения того же самого результата. Сделано для людей (с) Вы.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

2. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
Сообщение от XoRe (ok) on 17-Июн-10, 00:42
Очень интересно. Просто и гениально. Хотя все сводится к тому, что программисты в обязательном порядке станут писать код для обработки данных в sql запросе. Пусть даже в автоматическом режиме, благодаря врапперу. Но идея хороша. Увеличение размера переменных на 30% - фигня по сравнению с безопасностью. P.S. $conn->query("select * from table where fname=$fname;"); А так пишут? Без парсинга переменной и без кавычек?) UPD: По комментарию выше понял, что пишут =)
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+4 +/–
	Сообщение от _Vitaly_ (ok) on 17-Июн-10, 01:14
	По-моему он экранирование переизобрел. И даже если принять синтаксис ^^, непонятно зачем парсером заворачивать аж в base64 вместо добавления слешей.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	19. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+2 +/–
	Сообщение от Аноним (??) on 17-Июн-10, 04:23
	>По-моему он экранирование переизобрел. В том-то и дело, что экранировать сплошь и рядом забывают или криво экранируют, поэтому тоннами и всплывают SQL Injection, даже во вполне больших проектах, в которых и разработчики не дураки и аудит проводится. http://secunia.com/advisories/search/?search=sql+injection
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	41. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от zazik (ok) on 17-Июн-10, 10:30
	А ещё можно экранировать при включенном автоэкранировании, тоже весело. Так что единственно верный подход - писать нормальный, безопасный код.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	56. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+3 +/–
	Сообщение от _Vitaly_ (ok) on 17-Июн-10, 12:19
	Когда разработчики не дураки, обычно запросы идут через прослойку, которая автоматически приведение типов и экранирование выполняет. И тем не менее, вопрос о необходимости base64 остается открытым. Преимуществ перед слешами я пока не вижу, зато радостей по совместимости и изучению крякозябликов в логах будет вагон. А сама мысль о выделении переменных ^^ интересная, согласен.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	91. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+4 +/–
	Сообщение от XoRe (ok) on 18-Июн-10, 11:24
	>Когда разработчики не дураки, обычно запросы идут через прослойку, которая автоматически приведение >типов и экранирование выполняет. > >И тем не менее, вопрос о необходимости base64 остается открытым. Преимуществ перед >слешами я пока не вижу, зато радостей по совместимости и изучению >крякозябликов в логах будет вагон. > >А сама мысль о выделении переменных ^^ интересная, согласен. Да суть-то в другом. Чтобы была схема: юзер что-то ввел в форму - оно кодируется в base64 (на стороне клиента, а лучше - на стороне сервера) - передается в sql запрос в виде base64 - sql запрос уже сам декодирует и впихивает в поле. При такой схеме sql-injection не возможен в принципе. Можно не беспокоиться об экранировании и приведении типов. Вообще пох, что там введет юзер. Хоть бинарные данные, символы с ascii номерами 0-31. Единственное, что нужно проверять - это размер строки. Но это уже из другой логики - из области переполнения буфера) Кстати, всякие шеллкоды тоже не смогут пробраться, если на стороне сервера все приходящие переменные сразу кодировать в base64. Поэтому идея гениальна своей простотой и эффективностью.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	100. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от _Vitaly_ (ok) on 20-Июн-10, 00:15
	Теперь просек. Действительно хороший выход для тех, кто без врапперов пишет.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

4. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	–1 +/–
Сообщение от ffsdmad (ok) on 17-Июн-10, 01:00
идея конечно гениальна НО если у меня в базе будут base64 закодированные данные, то select * from table where like '%query%' работать просто не будет и мне скажут нах.. зачем нам база без поиска? а если не хранить в base64 то смысла нет, так как подставить под base64 кавычки или join ни кто не мешает а для DNS хакера эта идея конечно хороша
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	8. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	–1 +/–
	Сообщение от Alex (??) on 17-Июн-10, 01:16
	Base64 передается в только в запросе, завернутый в вызов функции преобразования. В базе хранится обычный текст, естественно.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	10. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	–2 +/–
	Сообщение от ffsdmad (ok) on 17-Июн-10, 01:20
	а какой смысл если после декодирования в запросе появится лишняя кавычка или join ?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	11. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
	Сообщение от ffsdmad (ok) on 17-Июн-10, 01:22
	>а какой смысл если после декодирования в запросе появится лишняя кавычка или >join ? либо это должно быть встроено в субд, всмысле врапер, чтобы раскодированная строка уже не парсилась
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	24. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+3 +/–
	Сообщение от Аноним (??) on 17-Июн-10, 05:15
	само собой, base64 декодируется уже внутри СУБД, средствами субд и представляет из себя только сроку, а не команду.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	20. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
	Сообщение от Аноним (??) on 17-Июн-10, 04:27
	>а если не хранить в base64 то смысла нет, так как подставить >под base64 кавычки или join ни кто не мешает base64 всегда буквы и цифры, т.е. чтобы не делал в запросе всегда будут буквы и цифры, никаких кавычек не появятся. Посмотрите пример, к БД всегда уходят запросы типа fname=b64d("abc"), где abc строка в base64 формате, хоть ты туда изначально !@#$%^&* поместишь.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

5. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	–1 +/–
Сообщение от ссс on 17-Июн-10, 01:03
непонятно, так если я введу например через веб-форму "' or '%" в переменную $fname, он закодирует мою инъекцию, раскодирует и выполнит мой код ВСЁ РАВНО. в чем прикол?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от ffsdmad (ok) on 17-Июн-10, 01:04
	... получивший известность обнаружением фундаментальной уязвимости в ...
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	12. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+2 +/–
	Сообщение от аноним on 17-Июн-10, 01:43
	Не выполнит.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	22. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
	Сообщение от Аноним (??) on 17-Июн-10, 04:32
	>непонятно, так если я введу например через веб-форму "' or '%" в >переменную $fname, он закодирует мою инъекцию, раскодирует и выполнит мой код >ВСЁ РАВНО. в чем прикол? В запросе к базе будет вместо вашего "' or '%" - b64d("DSSDDQEd="), и уже СУБД декодирует DSSDDQEd= и будет воспринимать "' or '%" как константу, а не часть запроса.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

9. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
Сообщение от vvvua (ok) on 17-Июн-10, 01:18
А 2 года назад меня пытались заплевать... http://sql.ru/forum/actualthread.aspx?tid=616602
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	13. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	–1 +/–
	Сообщение от аноним on 17-Июн-10, 01:44
	>А 2 года назад меня пытались заплевать... >http://sql.ru/forum/actualthread.aspx?tid=616602 А тебя и сейчас за это заплюют и правильно сделают.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	15. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от Аноним (??) on 17-Июн-10, 01:57
	Вы предгагаете сделать так: INSERT INTO table .. VALUES('_base64_enoded_string_'); он предлагает: INSERT INTO table .. VALUES(base64_decode('_base64_enoded_string_')); Соответственно в вашем случае хранинся - b64, в его - чистый текст. Но, да, его вариант решает пробоему SQL-Inj ( по сути - проблему разбора SQL-запросов). Хотя, ихмо, использование подстановок с один раз написанным и отлаженным экранированием работает не хуже.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	23. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от Аноним (??) on 17-Июн-10, 04:34
	>Но, да, его вариант решает пробоему SQL-Inj ( по сути - проблему >разбора SQL-запросов). >Хотя, ихмо, использование подстановок с один раз написанным и отлаженным экранированием работает >не хуже. Практика показывает, что экранирование под давлением человеческого фактора совсем не работает, даже в Joomla криво экранируют и mod_security не помогает.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	17. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от pento on 17-Июн-10, 02:01
	И правильно заплевали. Ваше решение из разряда защитимся от XSS и для этого всё в базу будем ложить уже с заменой на HTML-мнемоники, тем самым портя данные. Это архитектурная ошибка может вам встать боком в самый неподходящий момент. Предложение Камински интересно, но не более. Не особо много преимуществ по сравнению с параметризованными запросами, а если у вас используется нормальный ORM, то такой проблемы вообще нет.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	18. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+1 +/–
	Сообщение от Gambler (ok) on 17-Июн-10, 03:02
	Верно сказано. Чем эти методы лучше использования, скажем, PDO с параметрами и нормального эскейпера для вводимых пользователями данных? Хуже они тем, что усложнят запросы, раздуют размер передаваемых данных, а так же усложнят отладку. А передавать с вебсайты блоки данных, которые потом JavaScript будет декодировать и распихивать по тегами - вообще редкостное извращение. А если пользователям надо, скажем, запостить блок текста с жирным текстом и курсивом?
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	72. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от vvvua (ok) on 17-Июн-10, 14:55
	>И правильно заплевали. >Ваше решение из разряда защитимся от XSS и для этого всё в >базу будем ложить уже с заменой на HTML-мнемоники, тем самым портя >данные. Это архитектурная ошибка может вам встать боком в самый неподходящий >момент. Вы ошиблись. Я не от XSS защищал, а от SQL injection. Это разные вещи. Кроме того, моё приложение на момент разработки ни имело ни малейшего отношения к HTML. И замена на HTML мнемоники не равноценна замене на base64, т.к. base64 не нарушает целостность данных.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	74. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от pento (ok) on 17-Июн-10, 15:52
	>[оверквотинг удален] >>Ваше решение из разряда защитимся от XSS и для этого всё в >>базу будем ложить уже с заменой на HTML-мнемоники, тем самым портя >>данные. Это архитектурная ошибка может вам встать боком в самый неподходящий >>момент. > >Вы ошиблись. Я не от XSS защищал, а от SQL injection. Это >разные вещи. Кроме того, моё приложение на момент разработки ни имело >ни малейшего отношения к HTML. >И замена на HTML мнемоники не равноценна замене на base64, т.к. base64 >не нарушает целостность данных. 1. Я в курсе того, чем отличаются XSS от SQL-инъекции 2. Про замену на мнемоники..есть некоторые разработчики, которые сразу в базу ложат текст, в котором все HTML-спец.символы заменены на мнемоники. у вас аналогичное решение, только уже с base64. Просто что ваш, что методы Камински - по сути костыльные решения. И во многом надуманные. Его аргумент, что программисты только под дулом пистолета могут использовать параметризированные запросы вообще не выдерживает критики.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	96. "Кардинальный метод защиты от XSS и атак по подстановке SQL-з..."	+/–
	Сообщение от vvvua (ok) on 18-Июн-10, 16:02
	На счет костыльного решения - 100%. Что моё, что Камински. Я не приветствую решения, которые замедляют (читай увеличивают нагрузку на CPU) работу отдельных функций СУБД. Вот если создать работу со специндексами в самой СУБД (например, для полнотекстового поиска в кодировке base64 или подобной), которые будут работать не медленнее существующих - это уже будет не костыль, а фича!
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору