Сайт GNU Savannah был взломан

да не оправдывает это их...лулзы..чсв...срок должен быть наградой

Google будет вознаграждать пользователей за нахождение ошибок сразу в нескольких своих веб-сервисах. Пока перечислены только google.com, YouTube, Orkut, Blogger, Google Docs и Gmail. Награда не предусмотрена за нахождение ошибок в программах, работающих на Android, а также в Picasa и Sketchup. Позднее эти и другие программы и сервисы возможно также будут включены. После нахождения серьезной ошибки пользователь может рассчитывать на вознаграждение в размере, как минимум - $500, в зависимоти от уязвимости сумма будет увеличиваться до $1000, $1337 или $3133, что немного больше, чем у Mozilla.

Насчет «приличного» я, конечно, поторопился :) Хотя, если бы сдали уязвимость, через которую их можно поиметь, то заплатили бы побольше, я думаю. С другой стороны, конкуренты заплатили бы на порядок больше, мне кажется :)

Может, пояснишь, зачем использовать ORM, который так делает, и где такой найти?

Речь не о об этом. А о том, что использование ORM - это не гарантия безопасности от подобных дыр. Гарантия - это использование безопасных методов при работе с БД. В частности - использование bind variables вместо формирования полного текста SQL команды.

Т.е. ты настаиваешь, что ORM, использующие query parameters, а не string concatenation - не гарантия отсутствия sql injection? Может, пояснишь, каким образом при использовании нормального ORM произойдёт sql injection?

А то логика в стиле

Я: Использование безопасного инструмента предотвращает угрозу.
Ты: Нет, потому что есть и небезопасные инструменты.

просто потрясает.

> В результате были скомпроментированы зашифрованные пароли

Не так. «В результате безопасность паролей была дискредитирована». Учите английский язык. В частности, значение слова compromised.

модно != правильно

> К слову сказать, грамотно написанное на ASP.NET/ADO.NET(Entity Framework) по определению исключает SQL Injection. Да! Теперь на Mono.

Любый грамотный framework исключает SQL Injection. Хилый вброс вендофанатика.

Не в данном случае.

Т.е. ты настаиваешь, что ORM, использующие query parameters, а не string

concatenation - не гарантия отсутствия sql injection? Может, пояснишь, каким образом при использовании нормального ORM произойдёт sql injection?

Попробую еще раз.
ORM - это метод преобразования данных между двумя разными моделями или типами, использование ORM - не критерий наличия / отсутствия потенциальных уязвимостей. Критерием является правильный подход к программированию работы с БД, вне зависимости от языка и использования ORM.
Так понятнее?

>Хилый вброс вендофанатика.
Скажите, какой фреймворк объективно лучше?

> Ну раз им не важно чтобы было просто и понятно, то тогда гудбай, google code ждет...

Просто и понятно это не по-хакерски.

http://blog.andrewmin.com/2008/12/13/the-reasons-to-avoid-google-code-a-respo...

> Не «уроды», а молодцы, без них эту дыру не нашли бы

Чем молодцы, что данные попортили? Если бы просто нашли тогда другое дело.

Я говорил про наличие / отсутствие потенциальных уязвимостей? Нет. Я говорил совершенно определённо только про sql injection. ORM избавляет от этой уязвимости? Да. За исключением мифических ORM, в которых не используют query parameters, но примеры таких ORM ты так и не привёл.

Речь идёт _только_ об sql injection. Собственно, речь шла только об отсутствии необходимости писать «свои безопасные select/insert», т.к. они уже написаны и называются ORM. Именно на это ты и ответил комментарием что «ORM тоже небезопасны». Да ради бога, кто спорит, но только не в контексте sql injection.

При чём тут небезопасность ORM «вообще» - не понятно. Т.е. я согласен, что «вообще» и ORM небезопасны, только мне не понятно, какое это отношение изначально имеет к тому, о чём я говорю.

Ну а о тех, кто на Savannah трудились, ты, как всегда, не подумал.

Я еще раз попробую, но если снова будет непонятно, то я сдаюсь )

речь шла только об отсутствии необходимости писать «свои безопасные select/insert», т.к. они уже написаны и называются ORM.

«Уже написанные select/insert» называются _реализацией_ ORM.

В первом сообщении фраза «Запросы к базе в текстовом виде и SQL в частности сами по себе небезопасны. » - неверна. Использование SQL в текстовом виде с подстановками (bind variables) решают проблему раз и навсегда. Хоть с ORM хоть без неё. И наоборот, неиспользование bind variables в SQL - потенциальная дыра, вне зависимости от того что навернуто сверху.

При чём тут небезопасность ORM «вообще» - не понятно.

ORM к безопасности (или к опасности) отношения не имеет, ORM это просто способ представления объекта в виде таблицы. И использование этого способа само по себе не делает программу опаснее или безопаснее.

> В частности - использование bind variables вместо формирования полного текста SQL команды.

о, а подкинь плз ссылок где можно про это почитать.

scott_tiger> В частности - использование bind variables вместо формирования полного текста SQL команды.

/me побежал юзать bind variables. Зато полный SQL не надо писать!

> «Уже написанные select/insert» называются _реализацией_ ORM.

Уговорил, везде буду писать «проект использует _реализацию_ ORM hibernate». Ведь это важно.

Я смотрю, ты теоретик. У тебя ORM это просто способ представления и его использование не делает программу безопаснее. А у меня - в любом современном ORM опасности sql injection _уже_ нет, и поэтому его использование обезопасивает программу от sql injection. При чём тут «что такое ORM» мне непонятно. Теоретический ORM не поможет, да. Реальные, фактические ORM (пардон - реализации ORM) это делают, уже давно.

Вот есть sql injection. Вот мы используем ORM. Всё - проблемы нет. Ты можешь писать свои велосипеды с помощью bind variables - тоже решение. Но использование ORM _тоже_ решает проблему. И оно уже готово. Поэтому лучше, чем самому писать select/update, с помощью bind variables или без.

И наоборот, неиспользование bind variables в SQL - потенциальная дыра, вне зависимости от того что навернуто сверху.

Ты любишь говорить о чём-то своём, по-моему. Теоретически о том, что если кто-то что-то не использует... Любой нормальный ORM _уже_ использует и твои любимые bind variables, и множество других правильных техник. Уже.

Ждем письмо от Столлмана, с признанием в горячности и снятием рут-полномочий.

> Использование bind variables в принципе исключает возможность подобных атак.

Плюсую. Вот только, вероятно, не все СУБД такое поддерживают напрямую?.. ;)

Я не спец конечно, всего лишь небольшое двигало на PHP для себя наваял, когда PHP5 изучал. Но несколько вещей я запомнил быстро. Про то, что надо отделять PHP от HTML шаблонизатором. И про то, что данные от клиента к серверу и обратно надо гонять в сериализованном в XML/JSON, или ещё каком виде. Но нельзя, что-бы пользователи даже подозревали, не то что видели, как устроенны запросы к базе. У Python программистов всё ещё строже. Django, да и Pylons четко учат организации кода по паттерну MVC. Когда же писалось это двигало? Ещё до появления Smalltalk MVC, что-ли? Идея же проста до безобразия. Кода больше, зато надёжность повышается. Да и NOSQL базы для хостинга проектов лучшее решение, зачем там SQL?

>Но нельзя, что-бы пользователи даже подозревали, не то что видели, как устроенны запросы к базе.

Это называется безопасностью через сокрытие. Такая безопасность порочна в принципе. Настоящая безопасность тут достигалась бы в том случае, если бы пользователи даже зная как устроены запросы к базе, не смогли бы сделать ничего сверх предусмотренного запросом.

уроды

нашли бы, сказали, починили

ломали то зачем ? при этом ломали общественный сервер и после этого - не уроды ?

Уговорил, везде буду писать «проект использует _реализацию_ ORM hibernate». Ведь это важно.

Вот есть sql injection. Вот мы используем ORM. Всё - проблемы нет.

Это не тот Hibernate про который тут http://cwe.mitre.org/data/definitions/564.html написано CWE-564: SQL Injection: Hibernate (Related Attack Patterns: Object Relational Mapping Injection) ?
Description Summary
Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
«А мужики-то не знают.» :)

Любой нормальный ORM

Определение «нормального ORM», пожалуйста.

Вот есть sql injection. Вот мы используем ORM. Всё - проблемы нет.

Вот тебе еще пример, мистер практик.
http://docs.djangoproject.com/en/dev/topics/db/sql/

Warning

Do not use string formatting on raw queries!
Using the params list completely protects you from SQL injection attacks, ... If you use string interpolation, sooner or later you'll fall victim to SQL injection.

Т.е. ORM - это еще не защита от SQL injection, нужно уметь его правильно использовать.

Или Django - тоже «неномальный ORM». Озвучь сколько нибудь нормальных.

Специально искал? Этот не баг, это типичное проявление string concatenation. Проявляется, если юзать HQL (т.е. текстовый язык запроса) и не юзать там :параметры, а вручную строки объединять. В ORM можно и sql напрямую выполнить, это тоже баг?

В том же NHibernate вместо этого есть criteria api или linq, где никто строки самому объединять не даст.

Скажем так. Я согласен, _вообще_ использование ORM не даёт гарантии безопасности. Я, кстати, это и не отрицал, см. выше про индуса, который любой ORM обойдёт.

Остановимся на том, что, тем не менее, ORM даёт возможность вообще исключить вероятность sql injection. Т.е. даже при ошибке программиста. Если юзать тот интерфейс (linq например), который не позволяет передавать куски строк.

Фактически, когда я говорил «ORM исключает sql injection», имел в виду тот факт, что ORM предоставляет высокоуровневый query language, который весь user input передаёт исключительно через параметры (твои bind variables). Это и есть критерий «нормального ORM».

Фактически мы спорим, считать ли наличие более низкоуровневых средств, допускающих sql injection, в ORM - фактом, не позволяющим говорить «ORM исключает возможность sql injection».

Поэтому скажем так.

«В нормальных ORM уже есть средства, не допускающие sql injection. Соответственно, их использование предотвращает подобные баги».

>«В нормальных ORM уже есть средства, не допускающие sql injection. Соответственно, их использование предотвращает подобные баги».

ты так и не понял, о чем тебе scott_tiger говорил? ORM здесь не при чем. Совсем.

Специально искал?

Да. В секретном поисковике Google по строке Hibernate SQL Injection.

Остановимся на том, что, тем не менее, ORM даёт возможность вообще исключить вероятность sql injection.

Да. PHP/perl/java/python/etc тоже дает такую возможность. Что не исключает SQL injection в программах, на них написанных.

ORM предоставляет высокоуровневый query language, который весь user input передаёт исключительно через параметры (твои bind variables)

Нет, мистер практик, bind variables предоставляет (или не предоставляет) реализаця SQL для конкретной СУБД. Беотносительно ORM. Если СУБД не поддерживает bind variables, то никакие «высокоуровневые» навороты не помогут.

Поэтому скажем так.

«В нормальных ORM уже есть средства, не допускающие sql injection. Соответственно, их использование предотвращает подобные баги».

Такие возможности есть в языках программирования, на которых реализованы эти ORM. Которые, в свою очередь используют механизмы parse/prepare/bind, предоставляемые СУБД. Именно поэтому соответствующие возможности есть в ORM. А не наоборот.

Поэтому скажем так-же как и раньше - использование ORM не дает гарантию безопасности от SQL injection.

Наверное, не понял. Попробуй ты объясни.

Моё понимание:
scott_tiger: «Дело не в ОРМ, а в bind variables, сами по себе ORM могут тоже строки объединять»
я: «ага, но bind variables надо помнить использовать, а нормальные ORM их уже использует и заставляет это делать, т.е. то, что предлагал Sadler - 'дабы с пользовательского уровня никаких инъекций произвести нельзя было физически'».

См. мой комментарий выше. Суть не в наличии средств, а в том, чтобы невозможно было их не использовать. Чтобы можно было к базе достучаться только через интерфейс ORM, который внутри использует безопасные средства.

Именно поэтому соответствующие возможности есть в ORM. А не наоборот.

А я типа что-то обратное утверждал. Я вообще не понимаю, о чём и зачем ты споришь. Всё, что я говорю - ORM _заставляет_ использовать эти соответствующие возможности. «дабы с пользовательского уровня никаких инъекций произвести нельзя было физически» (c) Sadler.

>Наверное, не понял. Попробуй ты объясни.

ORM — не инструмент обеспечения безопсности, «это просто способ представления объекта в виде таблицы».

Сам по себе факт его использования не исключает проблем («В ORM можно и sql напрямую выполнить"queen3 (02.12.2010 12:42:42))

Также, неиспользование ORM не означает небезопасную реализацию интерфейса к СУБД.

>Всё, что я говорю - ORM _заставляет_ использовать эти соответствующие возможности.

Заставляет? А это что?

В ORM можно и sql напрямую выполнить

queen3 (02.12.2010 12:42:42)

Ты либо очень глупый, либо очень толстый.

Это - вынужденная мера с связи с несовершенством нашего мира.

Нет, я умный и тонкий, это хорошо видно на аватаре.

Всё, что я говорю - ORM _заставляет_ использовать эти соответствующие возможности.

Это не так (см. например ссылки из гугла приведенные ранее). Но я сдаюсь :)

Ну тогда скажем так - делает правильное использование лёгким, а неправильное - сложным. Кстати, основной признак хорошего фреймворка. Идеал, естественно, недостижим, ибо легаси и реальный мир.

>Это - вынужденная мера с связи с несовершенством нашего мира.

ну так как же «ORM _заставляет_ использовать эти соответствующие возможности», фактически не заставляя?

Разве слово «заставляет» означает полное отсутствие альтернативных путей? «делать так, чтобы кому-либо стало необходимым совершить какое-либо действие» (с) http://ru.wiktionary.org/wiki/%D0%B7%D0%B0%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D1%8...

Потом, можно пересобрать тот же (n)hibernate и отключить в нём hql/sql. И всё, просто-таки физически заставит.

Так это что, и emacs теперь скачать нельзя?

>Разве слово «заставляет» означает полное отсутствие альтернативных путей?

да, если верить:

«делать так, чтобы кому-либо стало необходимым совершить какое-либо действие» (с) http://ru.wiktionary.org/wiki/%D0%B7%D0%B0%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D1%8...

«необходимо» == «нельзя обойти» — означает полное отсутствие обходных (альтернативных) путей. Как вариант — полное отсутствие возможности использования этих путей.

Необходимо != нельзя обойти.

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

>Необходимо != нельзя обойти.

Ты ссылку-то свою читал? Там есть раздел «Этимология», где сказано, что ты снова неправ.

Можно цитату, а то я опять не понял, где в этимологии это сказано? Может вот это: «польск. stawić, в.-луж. stawić, н.-луж. stawiś»?

Ты ссылку-то свою читал?

Ты впустую теряешь время :)
Сначала произошла смена позиции :
«когда я говорил ... (то) имел в виду ...», теперь - смена предмета (вы спорите о происхождении и значении слов). Методов еще много (например, http://mitya.pp.ru/woman.htm). Сдавайся! :)

>Можно цитату, а то я опять не понял, где в этимологии это сказано?

Ты опять не понял? И почему я не удивлен?

вот тебе цитата, читай до просветления:

«Образовано из за- + ставить, далее от праслав. формы, от которой в числе прочего произошли: др.-русск. ставити, ст.-слав. ставити, ставлѭ (др.-греч. ἱστάναι, κωλύειν, στέλλειν), русск. ставить, укр. ста́вити, болг. ста́вя, сербохорв. ста̏вити, ста̏ви̑м, словенск. stáviti, stȃvim, чешск. staviti, словацк. stаvit᾽, польск. stawić, в.-луж. stawić, н.-луж. stawiś. Родственно русск. став, далее — лит. stovė́ti, stóviu «стоять», латышск. stãve^t, готск. stojan «направлять», англос. stówian «удерживать», ср.-нж.-нем. stouwen, нов.-в.-нем. stauen «запруживать, задерживать», греч. στύ̄ω «поднимаю вверх». Сюда же лат. restaurāre «восстанавливать», īnstaurāre «возобновлять», греч. σταυρός «кол». Далее от стать, от праслав. формы, от которой в числе прочего произошли: др.-русск. стати, стану, ст.-слав. стати, станѫ (др.-греч. ἵστασθαι, γίγνεσθαι), русск. стать, стану, укр. ста́ти, ста́ну, сербохорв. ста̏ти, ста̏нем, словенск. státi, stȃnem «стать, стоить», чешск. stát sе «произойти, стать», словацк. stаť. »

какое слово тебе непонятно?

>Ты впустую теряешь время :)

ты меня раскусил :)

Сначала произошла смена позиции ... теперь - смена предмета

ну так, надо же окончательно и доказательно убедиться в диагнозе.

Сдавайся! :)

ты адекват, с тобой скучно :)

Непонятно мне тут много слов, в основном нерусских, а вот какое из них утверждает, что «Необходимо == нельзя обойти», в упор не вижу. Может, выделишь болдом? Ты бы ещё всю страницу целиком процитировал.

Ну невозможно говорить с современной молодёжью, всё они читали, везде они бывали. Вот в наше время...

>Непонятно мне тут много слов, в основном нерусских, а вот какое из них утверждает, что «Необходимо == нельзя обойти». Может, выделишь болдом?

как печально...

Необходимо

Слово «необходимо» отсутствует в цитате. Кроме того, мне сложно понять, как отдельная часть утверждения может доказывать его целиком.