The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..., opennews (??), 30-Июл-11, (0) [смотреть все]

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


23. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (-), 30-Июл-11, 17:42 
> этого риска нет в любом случае, если у программиста руки не из Ж растут

Он всегда есть, потому что параметры передаются вместе с самим запросом, юзер на них может воздействовать, а соревнование кто кого перехитрит и обойдет на повороте (юзер программера или программер юзера) - практически бесконечное.

> -- он ЧЁТКО пониает границы за которые могут выходить "A" "B" "C" ...

При чем тут вообще границы? Проблема скуля в том что он часто работает с внешними не доверяемыми  данными. При том он не делает особых различий между операцией и данными для нее, и позволяет несколько операций в одном запросе. Поэтому без спецмер со стороны программера select из таблицы пользователей легко превращается в например ее дроп или произвольный вызов функционала БД, путем указания имени юзера в стиле того комикса про "little Jonny the tables we call him" ;). Понятно что можно програмера построить, заставить проверять что там ему юзер подсунул и прочая. Тут начинается густое костылирование всякими эскейпами (которые порой мешают жить в легитимных случаях и сажают скорость работы) и соревнование - нащупает ли хакер слабину или нет.

> -- ДОЛЖНА БЫТЬ ПЕРЕДАНА В СООТВЕТСТВУЮЩЕМ ВИДЕ, А НЕ ПУТЁМ ПРОСТОЙ
> ПОДСТАНОВКИ"

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

> # p.s.: я НЕ имею ввиду что программисту нужно *вручную* каждый раз
> формировать "A + B + C".. но понимать как оно формируется
> -- он просто обязан

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

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

80. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Aleks Revoemail (?), 31-Июл-11, 21:36 
Если Вы не знаете, что такое "границы", их проверка и подготовка значений - не делайте голословных заявлений о рисках ;-)

В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими escape-функциями, позволяющими программисту тонко контролировать процесс.

Если у Вас база получает непроверенные данные - это таки Ваши проблемы, а не проблемы базы.

Если программера нужно "строить" чтобы он выполнял свою работу, то не пошёл ли такой программер лесом в известном направлении?

> В key-value базу можно и путем простой подстановки пхать.

Интересно увидеть пример такой простой подстановки, если типичный интерфейс передачи параметров подобен prepareStatement.

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

86. "Создатели CouchDB и SQLite представили UnQL, аналог SQL для ..."  +/
Сообщение от Аноним (-), 04-Авг-11, 19:33 
> В случае скуля не приходится ровным счётом ничего "вручную костылить". Начиная от
> prepared statements, реализуемых драйвером автоматически, заканчивая соответствующими
> escape-функциями, позволяющими программисту тонко контролировать процесс.

Автоматизация костылестроения и тюнинг костылей. Шедеврально.

А в базах ключ-значение в выражении вида value = get(key) вообще облажаться негде. Юзер может пхать как key все что хочет даже. Но это мало ему поможет. И не надо никакого эскейпинга, prepare statement и прочих костылей. Можно влобешник имя пользователя отдать как key без особых рисков. Стоит ли говорить что базы key-value сами по себе просто убойно быстрые, да еще и дополнительно тормозить эскейпингами и prepare statements не надо.

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру