В сиплюлсплюсном проекте, который переписываю(и слава богу):
"select node_pkey from node where node_pkey = '%s'"
Все это в обвязке, в методе "Get[НеСкажуЧто]", который, вообще говоря, возвращает заполненный резалтсет аут параметром. На сях это выглядит стремно и громоздко.
Но самой пикантноси добавляет то, что sql сервер, к которому идет вызов, по архитектуре проекта крайне редко находится где-то локально, вполне может быть в пару тыщ километров(а то и через окиян) от дислокации текущей ноды. Ну, то есть, вызов далеко не легковесный.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>В сиплюлсплюсном проекте, который переписываю(и слава богу):
E__>
E__>"select node_pkey from node where node_pkey = '%s'"
E__>
Отличный, оригинальный select, сам такой недавно написал и был очень горд, выглядит завораживающе. Смысл действа прямолинеен — есть ли такая запись в DB или нет.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Но самой пикантноси добавляет то, что sql сервер, к которому идет вызов, по архитектуре проекта крайне редко находится где-то локально, вполне может быть в пару тыщ километров(а то и через окиян) от дислокации текущей ноды. Ну, то есть, вызов далеко не легковесный.
Очень легкий вызов. Тем более, что судя по названию полей, выборка идет по первичному ключу. Можно было и select count(*) написать с таким же where. Правда, не зная, что там за сервер, тяжело что-то советовать. Возможно тот select отработает гораздо быстрее. Опять же, если там какой Oracle то там может стоять какой триггер на select который по такому запросу вернет вообще не то, что есть в таблице.
E__>>"select node_pkey from node where node_pkey = '%s'"
E__>>
D>В качестве проверки существования записи — вполне нормальный код.
Хм. Ну если бы метод назывался "isNodeExists" — ну со скрипом бы понял(но тогда какого хрена не count?).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Хм. Ну если бы метод назывался "isNodeExists" — ну со скрипом бы понял(но тогда какого хрена не count?).
Ну если pkey или unique, то count(*) — нормально, а во всех остальных случаях я пишу именно select some_field ... limit 1, чтобы count(*) не сканировал всю таблицу после нахождения первого. Так что и твой пример тоже вполне нормален в том плане, что проще везде делать одинаково — select some_field.
E__>>Но самой пикантноси добавляет то, что sql сервер, к которому идет вызов, по архитектуре проекта крайне редко находится где-то локально, вполне может быть в пару тыщ километров(а то и через окиян) от дислокации текущей ноды. Ну, то есть, вызов далеко не легковесный.
MP>Очень легкий вызов. Тем более, что судя по названию полей, выборка идет по первичному ключу. Можно было и select count(*) написать с таким же where. Правда, не зная, что там за сервер, тяжело что-то советовать. Возможно тот select отработает гораздо быстрее. Опять же, если там какой Oracle то там может стоять какой триггер на select который по такому запросу вернет вообще не то, что есть в таблице.
Еслы вызывающая нода в Австралии, а вызываемый сервер в GB(ситуация реальна), то легким не будет даже вызов "select 0". Если ты не заметил, я не про тяжесть вызова для сервера(хотя с Ораклом ты угадал, а вот триггеров нет), а про время доступа — оно может быть очень грустным. Хотя от системы и не требуется суперскорость, все равно как-то печально.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, kochetkov.vladimir, Вы писали:
E__>>Ну, то есть, вызов далеко не легковесный.
KV>Я так понимаю, что аргумент форматной строки (судя по всему) в теле запроса — вопросов не вызывает?
Кто о чем, а безопасник об уязвимостях .
Там везде так. Уже не вызывает, привык. Хотя в данном конкретном случае это автогенеренный ключ, причем система ручного ввода вообще почти не предполагает. Впрочем я в жаве переписываю все через PreparedStatement — на всякий случай(да и удобнее).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, std.denis, Вы писали:
KV>>Я так понимаю, что аргумент форматной строки (судя по всему) в теле запроса — вопросов не вызывает? SD>пардон, не понял, а что не так?
sql инъекция по всей видимости возможна,
Здравствуйте, johny5, Вы писали:
J>Здравствуйте, Eugeny__, Вы писали:
E__>>В сиплюлсплюсном проекте, который переписываю(и слава богу):
E__>>
E__>>"select node_pkey from node where node_pkey = '%s'"
E__>>
J>Отличный, оригинальный select, сам такой недавно написал и был очень горд, выглядит завораживающе. Смысл действа прямолинеен — есть ли такая запись в DB или нет.
KV>>>Я так понимаю, что аргумент форматной строки (судя по всему) в теле запроса — вопросов не вызывает? SD>>пардон, не понял, а что не так? BS>sql инъекция по всей видимости возможна,
ого. это почему? например, если вызов типа str.printf("select node_pkey from node where node_pkey = '%s'", Sql::FilterValue(somekey))
Здравствуйте, std.denis, Вы писали:
BS>>sql инъекция по всей видимости возможна, SD>ого. это почему? например, если вызов типа str.printf("select node_pkey from node where node_pkey = '%s'", Sql::FilterValue(somekey))
Если вызов типа такого, то строка будет просто выведена на экран
Здравствуйте, kochetkov.vladimir, Вы писали:
SD>>str.printf("select node_pkey from node where node_pkey = '%s'", Sql::FilterValue(somekey)) KV>Ок, что конкретно делает Sql::FilterValue?
SD>>ого. это почему? например, если вызов типа str.printf("select node_pkey from node where node_pkey = '%s'", Sql::FilterValue(somekey)) KV>Если вызов типа такого, то строка будет просто выведена на экран
Нет же. Если приглядеться, то видно, что "printf" метод класса строки
KV>Ок, что конкретно делает Sql::FilterValue?
Не пускает кавычку в результат. Но не суть. Я имел в виду, что по кофейной гуще строке, которой форматируется запрос, неправильно вот так вот сделать вывод, что там потенциальная уязвимость
Здравствуйте, std.denis, Вы писали:
KV>>Ок, что конкретно делает Sql::FilterValue? SD>Не пускает кавычку в результат. Но не суть. Я имел в виду, что по кофейной гуще строке, которой форматируется запрос, неправильно вот так вот сделать вывод, что там потенциальная уязвимость
Неправильно было бы сделать вывод, что там уязвимость фактическая. А потенциальная — есть. При конструировании SQL-запросов конкатенацией строк она всегда есть.
