форумы  помощь  поиск  регистрация  вход/выход  слежка

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

"Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
Сообщение от opennews (??) on 08-Янв-17, 12:49
В GitHub Enterprise (https://enterprise.github.com/home), варианте GitHub для предприятий, позволяющем развернуть окружение для совместной разработки внутри корпоративной сети на подконтрольном оборудовании, выявлена (http://blog.orange.tw/2017/01/bug-bounty-github-enterprise-s...) уязвимость, позволяющая через отправку специально оформленного запроса выполнить произвольный SQL-код на сервере. В описании уязвимости приводится заслуживающий внимания рассказ об организации работы кода GitHub Enterprise, который во многом пересекается с кодом публичного сервиса GitHub. Пакет поставляется в виде образа виртуальной машины, доступной для бесплатного ознакомительного  использования в течение 45 дней. Исходные тексты скрыты и поставляются в упакованном виде, напоминающем зашифрованный набор данных. Прозрачная распаковка в момент выполнения осуществляется при помощи библиотеки ruby_concealer.so, анализ которой показал для метод упаковки сводится к сжатию кода при помощи Zlib::Inflate::inflate и применению операции XOR с предопределённым ключом. После распаковки было выяснено, что большая часть кода написана на языке Ruby с использованием фреймворков Ruby on Rails и Sinatra, но также применяются компоненты на Python, Bourne Shell, C++ и Java. По мнению исследователя безопасности, код отвечающий за работу web-сервисов основан на реальной кодовой базе github.com, gist.github.com, render.githubusercontent.com и api.github.com.  Получив доступ к коду исследователь, до этого не имевший дело c языком Ruby, потратил всего четыре дня на поиск возможных уязвимостей и выявил проблему в обработчике PreReceiveHookTarget, позволяющую осуществить подстановку SQL-кода через передачу специально оформленных данных через параметр  "sort", отправив запрос к общедоступному Web API.    $ curl -k -H 'Accept:application/vnd.github.eye-scream-preview' \    'https://192.168.187.145/api/v3/organizations/1/pre-receive-h...(select+1+from+information_schema.tables+limit+1,1)'    $ curl -k -H 'Accept:application/vnd.github.eye-scream-preview' \    'https://192.168.187.145/api/v3/organizations/1/pre-receive-h...(user()="github@localhost",sleep(5),user())' GitHub был уведомлен о проблеме в конце декабря и устранил уязвимость в  выпуске GitHub Enterprise 2.8.5. Выявившему уязвимость исследователю выплачено вознаграждение в размере 5 тысяч долларов США. URL: http://blog.orange.tw/2017/01/bug-bounty-github-enterprise-s... Новость: http://www.opennet.me/opennews/art.shtml?num=45825
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+4 +/–
Сообщение от Аноним (??) on 08-Янв-17, 12:49
Хороший способ заработать  5 тыс $ за 4 дня.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Аноним (??) on 08-Янв-17, 18:47
	> исследователю выплачено вознаграждение в размере 5 тысяч долларов США А могли бы исследователю просто дать абонемент на год бесплатного Github Enterprise...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	23. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+1 +/–
	Сообщение от Аноненамус on 08-Янв-17, 19:49
	Но зачем? где он его тратить будет?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	52. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Аноним (??) on 09-Янв-17, 18:29
	это, видимо - отсылка к наградам некоторых компаний
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

2. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+6 +/–
Сообщение от deadfood (ok) on 08-Янв-17, 13:16
>Прозрачная распаковка в момент выполнения осуществляется при помощи библиотеки ruby_concealer.so, анализ которой показал для метод упаковки сводится к сжатию кода при помощи Zlib::Inflate::inflate и применению операции XOR с предопределённым ключом. что на опеннете делает эта гнусная проприетарщина?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Часть нити удалена модератором

	9. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от VANANIMAS on 08-Янв-17, 17:34
	Ноет.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	36. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Аноним (??) on 09-Янв-17, 05:43
	> что на опеннете делает эта гнусная проприетарщина? Кормит троллей лулзами разве что. Для чего-то такого проприетарь и нужна.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
Сообщение от IB on 08-Янв-17, 14:13
Вашу ж мать, когда "ынтырпрайз" научится использовать prepared statements
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–3 +/–
	Сообщение от Ordu (ok) on 08-Янв-17, 14:54
	Это ruby и ActiveRecord. Там это может быть не столь элементарно, чем в случае, когда SQL-запрос собирается вручную при помощи конкатенации строк, типа как в пхп. В том смысле, что ActiveRecord позволяет подставлять SQL-код иногда, для всяких разных целей. И мало просто использовать prepared statements, надо знать где находятся грабли, чтобы на них не наступить. Это, к слову, о безопасности языка или, как в данном случае, библиотеки: было бы полезнее урезать функциональность ActiveRecord, вынудив программиста использовать sql вручную, когда ему не хватает возможностей ActiveRecoed -- было бы больше шансов на то, что программист не наступит на эти грабли. Но -- нет, -- хочется напихать в ActiveRecord максимум функциональности, даже когда выбранные абстракции уже не позволяют это сделать, не подкладывая программисту граблей. Может быть и можно выработать какие-то гайдлайны для программистов, чтобы даже не зная где лежат грабли, можно было бы успешно через них перешагивать -- я не настолько хорошо знаю рельсы, чтобы говорить. Но во всяком случае, тут всё чуть сложнее, чем безрукий "ынтырпрайз": да, кодеру не хватило квалификации, но это задача библиотек и языка делать так, чтобы если кодеру не хватает квалификации, то он бы не мог написать код, не позволяя ему создавать г-нокод, который вроде как даже работает, но требует внимательного чтения и вникания в детали, чтобы найти в нём косяк.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	11. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+3 +/–
	Сообщение от Аноним (??) on 08-Янв-17, 17:46
	Проблема не в ActiveRecord, а в том, что входные данные никто не проверяет как следует. Что до ActiveRecord, то библиотека, видимо, лишь позволяет в качестве order_by использовать всё, что можно написать в SQL-запросе через терминал.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	17. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+3 +/–
	Сообщение от Алексей Морозов (ok) on 08-Янв-17, 18:37
	Оставлять проверку входных данных на прикладного программиста — изощренный способ сделать себе больно в неожиданный момент. Кто-нибудь обязательно облажается, не подумает обо всех corner cases, а ревьюверы кода не заметят, будут заняты другими делами и вообще, режим "давай-давай-быстрее!" никто не отменял. SQL-стейтменты должны формироваться автоматом. Простой, хотя и не гибкий и не всегда применимый способ — prepared statements. Более сложный — DSL, который позволит создавать запросы из кубиков и переиспользовать какие-то стандартные заготовки в разных местах, без опасности того, что злые люди пропихнут injection. Из публично доступных библиотек, реализующих такой DSL, мне известен http://www.querydsl.com/ , хотя мы внутри пользуемся некоторым собственным велосипедом для C++ и Java.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	30. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–1 +/–
	Сообщение от АнониМ (ok) on 08-Янв-17, 23:21
	от prepared statements может просесть производительность. Тот же оракл может очень хорошо оптимизнуть запрос, ежель имеет конкретные значения, а не ps. Так что я б поостерёгся от утверждений "SQL-стейтменты должны формироваться автоматом".
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	34. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–2 +/–
	Сообщение от Анином on 09-Янв-17, 03:18
	>Тот же оракл может очень хорошо оптимизнуть запрос, ежель имеет конкретные значения Ахаха. Тот же оракл  просядет, если его кеш запросов будут забивать запросами с конкретными значениями. А значит все запросы будут парсится по новой и по новой будет строиться план запроса. То есть вместо запроса select * from tbl where fld=:val который один раз распарсится и далее оракл берет уже расперсеный запрос с вместе с планом из кеша, писать запросы так select * from tbl where fld=123 то для разных значений fld запрос для оракла будет буде считаться другим, а в силу большого количества возможных значений fld, старые варианты будут вытесняться из кеша. Как следствие, фактически каждый запрос будет заново парситься и заново строиться план запроса. Хуже того, нормальные пацаны, которые грамотно пишут запросы, тоже пострадают, так как кеш запросов у оракла общий. Такой альтернативно одареный кодер сломает работу на сервере всем. Подозреваю, что это майэскуэльщики перелезли в оракл, т.к. у майскуэля работа организована по другому.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	35. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–2 +/–
	Сообщение от . on 09-Янв-17, 04:18
	>Тот же оракл может очень хорошо оптимизнуть запрос, ежель имеет конкретные значения, а не ps. Ага, расскажи о вкусе ананасов тем кто их и в самом деле ел :-)))) В общем - в сад!
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	51. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от anonymous (??) on 09-Янв-17, 17:44
	> от prepared statements может просесть производительность. Тот же оракл может очень хорошо > оптимизнуть запрос, ежель имеет конкретные значения, а не ps. Так что > я б поостерёгся от утверждений "SQL-стейтменты должны формироваться автоматом". Отпимизация случайного возникшего хорошего случая (не забываем, что речь идет о параметрах, формируемых из пользовательсокого ввода) не стоит возникающих из-за нее хлопот. Отпимизировать имеет смысл плохие и средние случаи
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	58. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от xz (??) on 12-Янв-17, 12:52
	> SQL-стейтменты должны формироваться автоматом. Простой, хотя и не гибкий и не всегда > применимый способ — prepared statements. А какая связь между автоматическим созданием SQL-стейтмента и prepared?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	33. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Ordu (ok) on 09-Янв-17, 02:22
	Конечно же. Сколь бы дурацкий инструмент мы не использовали, если не справляется программист, то он и виноват. Продолжай думать так и дальше. Это несомненно позволит тебе не занимаясь тщательным выбором инструмента поднять свой скилл хождения по граблям до невообразимых высот. Только, тебе не боязно, что другие тем временем найдут более безопасные инструменты и потратят то же самое время на развитие более конструктивных навыков, таким образом подняв свою продуктивность до тех самых высот, на которых будет твоё умение не наступать на разложенные инструментами грабли?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	40. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–1 +/–
	Сообщение от Аноним (??) on 09-Янв-17, 11:23
	клоун: Пока запрос пишется в текстовом виде, будут существовать ошибки подстановки в него "инъекций". Другой инструмент? Сколько тебе лет что ты веришь в священные граали, решающие все проблемы лишь фактом своего существования? Защита? Это как в Java, когда к любой функции нужно дописать "throw IOException|BakaMegaException|NeZnayuChtuException", а затем заимпортить всю эту дребедень лишь чтобы компилятор от тебя отвязался? Мда... Защита во все дыры. Вместо критической ошибки выполнения в одном месте получают логическую ошибку в другом. По твоему это лучше?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	43. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Аноним (??) on 09-Янв-17, 13:27
	Однако ж попробуй заинъектить что-нибудь в простую key-value базу, где ключ и значение произвольные бинарные значения. Если специальной трактовки символов нет то и инъекция не получится.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	44. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–1 +/–
	Сообщение от Аноним (??) on 09-Янв-17, 13:44
	клоун: если программа работает с внешними данными, то можно подобрать такой их набор, который приведёт к нарушению корректной работы. Построчно читается банальный текстовый файл? Сделаем несоответствие размера файла реальным данным, вставим непечатаемые символы, вкл. перевод каретки, сделаем файл гигантского размера, сделаем гигантское количество строк из 1 символа, и т.д. А если это какой-нить XML с валидацией, то загрузить парсер как раз плюнуть. Гарантирую, что можно подобрать вариант, который приведёт как минимум к превышению сроков исполнения, что в сложной, взаимосвязанной и нагруженной системе или само по себе будет сбоем или приведёт к сбою в другом узле. Однажды столкнувшись с проблемой будет поставлена заглушка (ограничение на размер файла, предельное время выполнения операции и т.д.), потом ещё одна, и ещё, и ещё... Потом будет обновление чего-нибудь (БД сбойнёт и развернут новую или напишут новую версию функции) и старые ошибки полезут вновь. Неизбежность.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	54. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Аноним (??) on 09-Янв-17, 20:03
	> клоун: если программа работает с внешними данными, то можно подобрать такой их > набор, который приведёт к нарушению корректной работы. Только если автор - дол... и не понял что извне таки натурально могут приехать ЛЮБЫЕ данные. А если автор программы к этому готов - то, собственно, какие проблемы?! Сейчас вообще мода пошла - fuzz'ить программы. Чтобы проверить что это и правда так. Штуки типа AFL позволяют прицельно кроить структуры, чтобы их не отбил первый же фильтр на входе как явно некорректные и они проехали в более глубокие куски логики. А чтоб посмотреть - не сломается ли что еще и там? > Построчно читается банальный текстовый файл? Сделаем несоответствие > размера файла реальным данным, вставим непечатаемые символы, вкл. перевод каретки, Нормально написанная программа увидит что файл битый. И прекратит разбор или пропустит проблемные строки, в зависимости от того какие требования. Ну это если программу писал вменяемый человек а не сишарпер/вебмакака, над которыми стоял надсмотрщик с плеткой, рычащий что релиз должен был быть еще вчера, как это у вашего мерзкософта бывает. > сделаем файл гигантского размера, Опять же, если програмер не дятел - он должен понимать worst case и убедиться что они или энфорснуты так или иначе, или соизволить быть готовым к парсингу всего терабайта, не пытаясь его целиком загнать в память. А так ты еще блин попробуй высотки строить не имея представления о проектировании и сопромате. Или ракету запили, быстренько наняв пару таджиков умеющих варить трубы. > сделаем гигантское количество строк из 1 символа, и т.д. Даже мои наколенные хреновины для внутренних нужд в таком случае просто скипают строку и не имеют с этого никаких проблем. > А если это какой-нить XML с валидацией, то загрузить парсер как раз плюнуть. Опять же, во первых нефиг дурные форматы использовать, а во вторых - требования надо ставить нормально. И имплеменить потом нормально. А если ты нанял пару таджиков варить тебе ракету - знаешь что, а проводи-ка ты огневые испытания своей куеты где-нибудь в пустыне, от меня подальше! > исполнения, что в сложной, взаимосвязанной и нагруженной системе или само по > себе будет сбоем или приведёт к сбою в другом узле. Если эту сложную систему писали люди у которых непечатные символы или строка из одного символа вызывает проблемы - несомненно. Таким людям не стоит писать такие системы. Точно так же как таджикам с тремя классами образования не следует доверять постройку ракет. > Однажды столкнувшись с проблемой будет поставлена заглушка (ограничение на размер файла, Минимально вменяемый програмер это сделает извините еще в черновой реализации. А так - давайте вы лучше будете дома строить? Не забудьте свой офис в ваше замечательное строение перенести, главное. > Неизбежность. Если у вас вместо програмеров обезьяна с гранатой - результат неизбежен, спору нет.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	45. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+1 +/–
	Сообщение от Ordu (ok) on 09-Янв-17, 14:02
	> Пока запрос пишется в текстовом виде, будут существовать ошибки подстановки в него "инъекций". Бла-бла-бла... Ещё какой всемирный закон ты открыл? > Сколько тебе лет что ты веришь в священные граали, решающие все проблемы лишь фактом своего существования? Сколько _тебе_ лет, что ты никак не можешь излечиться от юношеского максимализма? Если священного грааля не существует, значит не надо, создавая API, думать о том, как бы поменьше граблей туда напихать?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	46. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–1 +/–
	Сообщение от Аноним (??) on 09-Янв-17, 14:18
	клоун: Ты в суть проблемы то вник? Они неверно экранировали входные данные. Какие ещё грабли? Грабли - это о другом. Напр в php есть уже 3 функции экранирования (экранирование при выводе в HTML, экранирование для SQL, улучшенное экранирование для SQL). Последнее - как раз те самые грабли. "Руководство по собиранию парашюта. Версия вторая. Исправленная". Мало того что они накосячили при первой реализации экранирования, так они ещё оставили обе функции. Более того: они использовали пересекающуюся терминологию (слово "экранирование" в обоих случаях) чтобы накосячил прикладной программист. Вот это грабли как они есть.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	50. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Ordu (ok) on 09-Янв-17, 17:40
	Ты с ActiveRecord знаком, деточка? ActiveRecord занимается сборкой текстового sql-запроса, и в частности экранированием. Задумка, примерно как в cl-sql: создать язык изоморфный SQL внутри языка общего назначения, чтобы функция query принимала бы запрос не как текстовую строку, а как более сложную структуру данных, которая бы позволяла библиотечному коду знать где строки которые надо подставить в запрос, а где ключевые слова SQL. И там, и там это достигается тем, что ключевые слова SQL передаются в библиотечный код не как строки, а иным путём. Всё же, что не ключевые слова, рассматривается библиотечным кодом как потенциально вредоносные строки, которые экранируются. Но если лисп позволяет такие извращения в любых масштабах, благодаря тому, что для лиспа код и данные -- это одна фигня, в лисповский синтаксис можно уложить SQL, и написать код, который будет этот SQL компилировать в строку, то ruby -- хоть и довольно мощный язык, но всё же слабоват для подобного. В результате, не любое SQL-выражение можно записать на том языке описания запросов, который предлагает ActiveRecord. Поэтому в некоторых ситуациях ActiveRecord всовывает строки от программиста в текстовое представление SQL-запроса "as is". И программист должен знать и помнить все такие ситуации наперечёт, чтобы если не дай бог он ввалится в такую ситуацию, он бы не забыл экранировать. И это называется "грабли". То есть эдакая хрень, которая совершенно внезапно выскакивает из-за угла, и с воплем "you are not prepared" даёт по лбу. Адекватный API, при попытке программиста наступить на грабли, должен выкидывать исключения, ещё лучше делать код некомпилируемым, включать сирену и бить окна. Но хотя бы, вот как минимум, этот код должен просто ронять всё приложение посредством вызова функции panic, или die, или exit, или terminate, или, на крайняк, если такой функции не нашлось, то выполнить *(int*)0 = 0. И да, не надо мне приводить в пример php -- в php вообще уродский подход, где программист составляет sql запросы конкатенируя строки. Конкатенируя, строки! В XXI веке, Карл!
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	12. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–7 +/–
	Сообщение от Kodir (ok) on 08-Янв-17, 17:48
	AR вообще тут не причём! Какой бы ни был ORM, программист просто не имеет права брать "абстрактный шмот символов" и тут же совать на исполнение! Правильно люди сказали - обязан быть хардкоженый SQL оператор + параметр, принимающий строку извне. Эксплойт лишний раз доказывает, насколько раздута слава git/github безо всякого анализа качества - а хомячки и рады прыгать "это написал наш великий Линус!". Mercurial - наше всё. :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	13. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+6 +/–
	Сообщение от Аноним (??) on 08-Янв-17, 17:55
	> Уязвимость, позволяющая осуществить подстановку SQL-кода в GitHub Enterprise > Эксплойт лишний раз доказывает, насколько раздута слава git > GitHub Enterprise > git > GitHub Enterprise > git > GitHub Enterprise > это написал наш великий Линус! > GitHub Enterprise > это написал наш великий Линус! Слишком толсто, попробуйте потоньше.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	37. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+1 +/–
	Сообщение от Аноним (??) on 09-Янв-17, 05:45
	> Mercurial - наше всё. :) Угу, ваше. "Ну тогда и т...ся сам с собой!" (c) анекдот.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–6 +/–
	Сообщение от Crazy Alex (ok) on 08-Янв-17, 17:57
	Гитхаб с руби - это так себе энтерпрайз. Со джавой/спрингом я подобных уязвимостей особо не помню, допустим (хотя могу не знать). Но вообще если исключить криворукость (которой гораздо меньше, чем было) основная причина - это совершенно убогие возможности SQL в этом плане - потому что prepared statements, собственно, никогда и не задумывались как механизм обеспечения безопасности - а только как оптимизация. В результате там можно гораздо меньше, чем надо для ORM и прочих динамически формируемых запросов, и часто тупая генерация строки оказывается гораздо более общим и предсказуемым методом. По идее, давно пора добавить ещё уровень - где динамическим было бы всё, от имён таблиц и полей до ключей запроса. Сделать это, в принципе, не так сложно - как минимум просто гнать набор токенов с явным указанием ожидаемого типа токена, как максимум - сразу синтаксическое дерево (которое один хрен строят ORMы, потом сериализуют, а потом база это дело парсит).
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	18. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–5 +/–
	Сообщение от Лютый жабист__ on 08-Янв-17, 18:41
	Prepared statements на любом языке это кал. Приходится писать их 100500 однотипных. Вообще sql устарел, вот в монге всё гуд и без ps.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	19. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Алексей Морозов (ok) on 08-Янв-17, 18:41
	> По идее, давно пора добавить ещё уровень - где динамическим было бы > всё, от имён таблиц и полей до ключей запроса. Известный мне open source пример — querydsl: http://www.querydsl.com/static/querydsl/latest/reference/htm... Однако, я не уверен, что querydsl равномощен SQL'ю, т.к. мы пользуемся самописным велосипедом, который позволяет сгенерировать любой требуемый SQL, с расширениями типа postgis'а.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	31. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Crazy Alex (ok) on 08-Янв-17, 23:48
	Это вообще не то. Во-первых, я говорил о том, что подобная штука должна быть чем-то стандартным и разбираться в базе. А здесь - опять просто надстройка, генерирующая SQL. Во-вторых, она не решает те проблемы, из-за которых обычно начинают руками генерировать SQL. Например, "сунуть в SELECT список полей из конфига".
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	49. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–1 +/–
	Сообщение от Алексей Морозов (ok) on 09-Янв-17, 16:28
	> Во-первых, я говорил о том, что подобная штука должна быть чем-то стандартным и разбираться в базе Реальность, данная нам в ощущениях, явственно говорит, что в существующие SQL RDBMS запросы всовываются в текстовом виде. Да, я знаю, что у многих из таких RDBMS есть альтернативные способы формирования запросов, более структурированные. Однако, речь идет именно об SQL, он ровно такой, какой есть. > Во-вторых, она не решает те проблемы, из-за которых обычно начинают руками генерировать SQL Ещё как решает. Если в объекте, отвечающем за таблицу, есть фиксированный набор методов/пропертей, описывающих манипуляции с полями, то и в формируемый SQL-запрос можно будет затолкать ровно эти поля. > Например, "сунуть в SELECT список полей из конфига". В этом случае прикладной программист будет, по первости чертыхаясь и жалуясь на непроизводительную трату времени, писать явный разбор входных данных и явный маппинг токенов в разобранном тексте на вызовы DSL'я. Собственно, прямо буквально за соседним столом такой человек сидит. Но, нужно отметить, после новостей об очередной SQL-инъекции жалоб "а нафига здесь париться, если можно просто склеить несколько строк" становится существенно меньше :)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от angra (ok) on 09-Янв-17, 13:04
	> Вашу ж мать, когда "ынтырпрайз" научится использовать prepared statements Когда уже невежды узнают про ограниченность возможностей prepared statements и перестанут вещать про них во всех новостях про SQL injection? В данном случае никакой prepared statement помочь в принципе не мог.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	47. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+1 +/–
	Сообщение от mimocrocodile on 09-Янв-17, 15:12
	И тут ты такой приводишь пример использования prepared statements с задаваемой пользователем сортировкой
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

32. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	–1 +/–
Сообщение от Вы забыли заполнить поле Name on 09-Янв-17, 01:55
> анализ которой показал, что метод упаковки сводится к сжатию кода при помощи Zlib::Inflate::inflate и применению операции XOR с предопределённым ключом. > после распаковки было выяснено, что большая часть кода написана на языке Ruby Я правильно понял, что выявивший уязвимость определил ключ и получил код? > По мнению исследователя безопасности, код, отвечающий за работу web-сервисов, основан на реальной кодовой базе github.com, gist.github.com, render.githubusercontent.com и api.github.com. Как он это понял, если код перечисленных сервисов закрыт?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Уязвимость, позволяющая осуществить подстановку SQL-кода в G..."	+/–
	Сообщение от Аноним (??) on 09-Янв-17, 05:49
	> Как он это понял, если код перечисленных сервисов закрыт? Правильно, определять надо путем drop table students без лишних церемоний, это научит вебмакак валидировать ввод :)
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

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

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