Работа хостинга свободных проектов savannah.gnu.org (http://savannah.gnu.org/), в рамках которого развиваются многие GNU-инструменты, временно приостановлена. Судя по опубликованному на сайте сообщению, сервер был взломан через подстановку SQL-запроса в web-сервисе Savane2, в результате чего злоумышленнику удалось получить доступ к базе аккаунтов, содержащей шифрованные пароли всех пользователей хостинга. Используя данную базу, злоумышленнику удалось подобрать некоторые пароли и использовать из для доступа к размещенным на хостинге проектам.В настоящее время ведется работа по восстановлению содержимого сервера из резервной копии, созданной 23 ноября. Все изменения, добавленные в репозитории исходных текстов после 23 ноября потребуют ручного восстановления. Статус восстановления можно посмотреть в микроблоге fsfstatus (http://identi.ca/group/fsfstatus).
Одновременно неудача постигла сервер lists.gnu.org, на котором в RAID-массиве оказались (http://identi.ca/notice/59494378...
URL: http://lwn.net/Articles/417709/rss
Новость: http://www.opennet.me/opennews/art.shtml?num=28836
SQL инжект - да неужели?! Я думал, что уж в 21м то веке народ уже не позволяет себе столь откровенных глупостей в дизайне.. :-/
Если язык это позволяет, то рано или поздно проверка на инжект будет забыта. Человеческий фактор однака )))
> Если язык это позволяет, то рано или поздно проверка на инжект будет забыта
>>>проверка на инжект<<<
>>>>проверка<<<<o_0!!!
какая нафиг проверка? вы что с луны свалились?! :-D
...никакие проверки на инжект никогда не делаются, а просто навсего происходит разделение SQL-кода-выражения на две части -- на само константное-выражение и на аргументы к нему
(в результате чего SQL-константное-выражение остаётся как есть, а аргументы _автоматически_ ЭКРАНИРУЮТСЯ)
и забыть (человеческий фактор) такое сделать -- попросту НЕВОЗМОЖНО :-) :-)
вот объясни -- как можно ПОСЛУЧАЙНОСТИ ЗАБЫТЬ сделать экранизацию в выражении cursor.execute(...) ???, где:
import MySQLdb
conn = MySQLdb.connect(host = "localhost",
user = "testuser",
passwd = "testpass",
db = "test")
cursor = conn.cursor()
animal = 'snake'
name = 'turtle'
cursor.execute("""
UPDATE animal SET name = %s
WHERE name = %s
""", (animal, name))
>>вот объясни -- как можно ПОСЛУЧАЙНОСТИ ЗАБЫТЬ сделать экранизацию в выражении cursor.execute(...) ???, где:пхп открой уважаемый
если ты знаешь что такое SQl injection это не означает что все знают
пс: все уязвимости появились после появления этого долбанного пхп )))
Само собой, виноват именно php))) В убожестве ВАЗ тоже виноваты станки, а не кривые руки производителей.
виноваты кривые руки не производителей ВАЗа а производителей станков
Вообще-то у ВАЗа был свой крупный завод станков.
> пхп открой уважаемый
> если ты знаешь что такое SQl injection это не означает что все
> знают
> пс: все уязвимости появились после появления этого долбанного пхп )))В PHP сто лет в обед как есть PDO с вменяемой поддержкой prepared statements. Точно так же как в Perl есть DBI или в Ruby или Python свои аналогичные обвязки. Если кто-то их не использует - это уже сугубо его личные сексуальные трудности и язык здесь бессилен. Любой.
>> пхп открой уважаемый
>> если ты знаешь что такое SQl injection это не означает что все
>> знают
>> пс: все уязвимости появились после появления этого долбанного пхп )))
> В PHP сто лет в обед как есть PDO с вменяемой поддержкой
> prepared statements. Точно так же как в Perl есть DBI или
> в Ruby или Python свои аналогичные обвязки. Если кто-то их не
> использует - это уже сугубо его личные сексуальные трудности и язык
> здесь бессилен. Любой.пр препейред слышали проценты - ибо пхпешники такой тип прогеров (в основном начинающих) которым - лиш бы работало
и плюс виноваты разработчики субд - нахрена допустим в sql разрешать не закрытый многострочный комент ? или ваще нахрена они там сдались коментарии ?
виноваты разработчики API к субд - нахрена создавать небезопасные функции ?
пс: о да о безопасности должен думать проггер бля - а шо человек пишуший API к субд не проггер ? и кто виноват ?
> пс: о да о безопасности должен думать проггер бля - а шо человек пишуший API к субд не проггер ? и кто виноват ?В реальности же виноват лишь один дурак, которому указали Путь, следуя которым он избавится от указанных проблем как класса. Тогда как он вместо того, чтобы заняться делом, все продолжает с маниакальной настойчивостью искать виноватых. 'Ищите ищите - должон быть' (c) фильм.
> вот объясни -- как можно ПОСЛУЧАЙНОСТИ ЗАБЫТЬ сделать экранизацию в выражении cursor.execute(...) ???, где:Все зависит от того, что в конечном итоге вызывает этот cursor.execute(sql). Если он транслируется скажем в prepared statement то тут при всем желании инжекта не будет, чтобы не задавалось в animal и name. Просто по-определению. Если же он сам конструирует конечное SQL выражение из шаблона и аргументов, которое потом передает на исполнение - то тут уже it depends. При кривых ручках можно получить все, что угодно, и никакие враперы не помогут.
> SQL инжект - да неужели?! Я думал, что уж в 21м то
> веке народ уже не позволяет себе столь откровенных глупостей в дизайне.. :-/Ну, кому там не нравились переполнения буфера? Хавайте теперь скуль-иньекции, вполне себе вариант :)
SQL - вообще для блонидинок, но "переполнение буфера" - это не к ним, а к архитектуре процессора
>"переполнение буфера" - это не к ним, а к архитектуре процессораНет, это чаще всего к Деннису Ричи.
>>"переполнение буфера" - это не к ним, а к архитектуре процессора
> Нет, это чаще всего к Деннису Ричи.а причём тут Ричи ? то что у вас башка не варит за это надо Ричи винить ?
а то что вы даже понятия не имеете как устроена память - что за это Ричи надо винить ?
>а то что вы даже понятия не имеете как устроена память - что за это Ричи надо винить ?Да ну? Просветите меня, профессор, почему же это переполнение буфера вообще невозможно отследить без специальной аппаратной поддержки, если программа написана на высокоуровневом языке программирования? А то мы, печники, по-своему мыслим.
Большинство прикладных программ на низком уровне с памятью не работают. Переполнение буфера чаще всего возникает из-за отсутствия проверки границ массивов, которая могла бы быть реализована на уровне компилятора, но ее не реализовали в C для выигрыша в производительности. Арифметика указателей осложняет проверку, но можно было бы, например, усложнить указатели, сделав их не обычными числами, а специальными конструкциями, чтобы указывать компилятору, в каких пределах они могут изменяться. Всего этого в языке C нет, даже опционально (как в Фортране, например), и, скорее всего, никогда не будет.
А поскольку большинство программ написано на C, мы с этим будем еще долго жить.
Вы можете предложить что-то лучше?
что-то GNU не везет.. Хотя может это просто кара ?
А я то думаю, чего я не могу бинарники linphone для win скачать с понедельника с этого сервера ;))...
Интересно. Тоже думал, что в 21-м веке такого не бывает.
Пытался проделать такое с Web-сервисом Java EE приложения на GlassFish-е.
К моему великому сожалению - это оказалось невозможным. Хотя допускаю, что в некоторых jdbc драйверах могут быть дыры, но это маловероятно. Я пробовал jTDS и MS SQl. Всё преобразуется (если не изменяет память) в хранимые процедуры с параметрами, которые создаются непосредственно перед извлечением данных, а потом сразу же выполняются с подстановкой параметра, но все опасные символы автоматически экранированы.
При желании даже JDBC позволяет выполнять SQL запрос, который можно перед этим выстроить без параметров в строке :)
Так что тут тоже всё возможно.
Конечно :-) Кривыми руками везде можно накосячить.
Это позволяет любое средство обращения к БД через SQL.Я просто хотел сказать, что строить запрос в коде руками плохо :-) И есть куча средств, чтобы этого не делать. И это вроде всем понятно и известно. Всегда будут находится недокументированные возможности.
То-то у меня кое-какие пакеты с savannah.gnu.org с первого раза не скачались!