В сиплюлсплюсном проекте, который переписываю(и слава богу):
"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-запросов конкатенацией строк она всегда есть.
Здравствуйте, std.denis, Вы писали:
KV>>Ок, что конкретно делает Sql::FilterValue? SD>Не пускает кавычку в результат. Но не суть.
Суть. Потому что, как минимум:
а) пускает обратный слеш — здравствуй фрагментированная SQLi
б) пускает *, % и т.п. (зависит от DBMS) — здравствуйте DoS-условия
Разумеется, и это можно фильтровать. Но зачем все эти навороты и усложнения, если можно воспользоваться параметрами?
SD>Я имел в виду, что по кофейной гуще строке, которой форматируется запрос, неправильно вот так вот сделать вывод, что там потенциальная уязвимость
Ну ты же сам правильно и сформулировал. Неправильно делать вывод о том, что там есть уязвимость. Однако, при проведении ревью, наличие конкатенации в том или ином виде при подготовке выражения запроса куда-либо, это однозначный повод рассматривать это как потенциально-уязвимое место и внимательнее изучить относящиеся к нему фрагменты кода.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, std.denis, Вы писали:
KV>>>Ок, что конкретно делает Sql::FilterValue? SD>>Не пускает кавычку в результат. Но не суть.
KV>Суть. Потому что, как минимум:
KV>а) пускает обратный слеш — здравствуй фрагментированная SQLi KV>б) пускает *, % и т.п. (зависит от DBMS) — здравствуйте DoS-условия
Не, ну тут ты загнул.
а) Обратный слэш нормальная экранирующая функция (тот же mysql_escape_string) не пустит. Она чётко приведёт значение строки к виду, пригодному для вставки в SQL.
б) * и % работают только в сочетании с LIKE, т.е. там где они явно ожидаются. Ну, тут можно конечно, если постараться, придумать дыру, но на практике LIKE используется настолько редко, что отнестись к каждому использованию внимательно — не проблема.
Здравствуйте, dimgel, Вы писали:
D>а) Обратный слэш нормальная экранирующая функция (тот же mysql_escape_string) не пустит. Она чётко приведёт значение строки к виду, пригодному для вставки в SQL.
А разве у нас есть предпосылки к тому, что Sql::FilterValue — нормальная экранирующая функция?
D>б) * и % работают только в сочетании с LIKE, т.е. там где они явно ожидаются.
Я совершенно точно сталкивался с ORM (по-моему, в составе какого web-framework'а), в которой, при рукопашном создании запросов, можно было указать подстановочные символы в обычном выражении, а ORM уже сама превращала это дело в LIKE. Но это уже как-то далеко от сабжевой строчки кода
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А разве у нас есть предпосылки к тому, что Sql::FilterValue — нормальная экранирующая функция?
Предпосылки-то? Гы, ну надо верить в лучшее. Предпосылки есть, безусловно. Эдак ты можешь заодно и спросить, есть ли у нас предпосылки к тому, что PreparedStatement.setParameter() тоже без дыр. Или что math.random возвращает числа в диапазоне [0,1] и никогда за него не вылезает.
KV>Я совершенно точно сталкивался с ORM (по-моему, в составе какого web-framework'а), в которой, при рукопашном создании запросов, можно было указать подстановочные символы в обычном выражении, а ORM уже сама превращала это дело в LIKE. Но это уже как-то далеко от сабжевой строчки кода
Хм. А ведь действительно можешь... Господи, это ж как тебе должно быть тяжело жить. Ни одного оператора ж не написать без уверенности, что он будет работать так, как заявлено! (Гы, а уж если с макросами... )
Здравствуйте, dimgel, Вы писали: D>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А разве у нас есть предпосылки к тому, что Sql::FilterValue — нормальная экранирующая функция? D>Предпосылки-то? Гы, ну надо верить в лучшее.
Почему?
D>Предпосылки есть, безусловно.
И? Где хоть одна?
D>Эдак ты можешь заодно и спросить, есть ли у нас предпосылки к тому, что PreparedStatement.setParameter() тоже без дыр. Или что math.random возвращает числа в диапазоне [0,1] и никогда за него не вылезает.
Если PreparedStatement.setParameter() реализован на коленках, т.е. в рамках этого же проекта — спрошу обязательно. Точнее, сам посмотрю. А math.Random, пока не используется рядом с криптографией, у меня вопросов не вызовет
KV>>Я совершенно точно сталкивался с ORM (по-моему, в составе какого web-framework'а), в которой, при рукопашном создании запросов, можно было указать подстановочные символы в обычном выражении, а ORM уже сама превращала это дело в LIKE. Но это уже как-то далеко от сабжевой строчки кода
D>Хм. А ведь действительно можешь... Господи, это ж как тебе должно быть тяжело жить. Ни одного оператора ж не написать без уверенности, что он будет работать так, как заявлено!
Дык я не пишу операторы, я их читаю. А вот тому, кто их пишет — после этого тяжело да
D>(Гы, а уж если с макросами... )
Здравствуйте, kochetkov.vladimir, Вы писали:
D>>Предпосылки есть, безусловно. KV>И? Где хоть одна?
Эм... ну я под предпосылками понимаю потенциальную возможность того, что кодер, реализовавший эту функцию, окажется достаточно квалифицированным. Мне из твоих ответов показалось, что раз самопальная, то значит по определению гарантированно кривая.
D>>(Гы, а уж если с макросами... ) KV>А я работу и личную жизнь не смешиваю
Здравствуйте, dimgel, Вы писали:
D>Эм... ну я под предпосылками понимаю потенциальную возможность того, что кодер, реализовавший эту функцию, окажется достаточно квалифицированным. Мне из твоих ответов показалось, что раз самопальная, то значит по определению гарантированно кривая.
Да ладно, я просто издеваюсь, пытаясь понять глубину имеющего место мнения, что все безопасники параноики
D>>>(Гы, а уж если с макросами... ) KV>>А я работу и личную жизнь не смешиваю D>
proof-of-concept Nemerle-проекта для VS, который при открытии его в студии (не при билде, а просто при открытии sln-файла) выполнял произвольный код на машине разработчика (кстати, работает с минимальными изменениями и по сей день во всех трех студиях ).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Да ладно, я просто издеваюсь, пытаясь понять глубину имеющего место мнения, что все безопасники параноики
proof-of-concept Nemerle-проекта для VS, который при открытии его в студии (не при билде, а просто при открытии sln-файла) выполнял произвольный код на машине разработчика (кстати, работает с минимальными изменениями и по сей день во всех трех студиях ).
Здравствуйте, dimgel, Вы писали: D>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Да ладно, я просто издеваюсь, пытаясь понять глубину имеющего место мнения, что все безопасники параноики D>Гы, а разве нет?
Разница между больным паранойей и профессиональным параноиком в том, что второй умеет ей управлять
KV>>Кстати говоря, я бы не очень шутил по поводу макросов. Еще полтора года назад, я показал http://rsdn.ru/forum/nemerle/4046518.aspx
proof-of-concept Nemerle-проекта для VS, который при открытии его в студии (не при билде, а просто при открытии sln-файла) выполнял произвольный код на машине разработчика (кстати, работает с минимальными изменениями и по сей день во всех трех студиях ). D>Хе. Ожидаемо. И каковы пути затыкания дыры?
Вот поэтому я и стараюсь не смешивать личную жизнь с работой
Здравствуйте, Eugeny__, Вы писали:
E__>Еслы вызывающая нода в Австралии, а вызываемый сервер в GB(ситуация реальна), то легким не будет даже вызов "select 0". Если ты не заметил, я не про тяжесть вызова для сервера(хотя с Ораклом ты угадал, а вот триггеров нет), а про время доступа — оно может быть очень грустным. Хотя от системы и не требуется суперскорость, все равно как-то печально.
