https://www.opennet.ru/openforum/vsluhforumID3/110116.html В GitHub Enterprise (https://enterprise.github.com/home), варианте GitHub для предприятий, позволяющем развернуть окружение для совместной разработки внутри корпоративной сети на подконтрольном оборудовании, выявлена (http://blog.orange.tw/2017/01/bug-bounty-github-enterprise-sql-injection.html) уязвимость, позволяющая через отправку специально оформленного запроса выполнить произвольный SQL-код на сервере. <br><br><br>В описании уязвимости приводится заслуживающий внимания рассказ об организации работы кода GitHub Enterprise, который во многом пересекается с кодом публичного сервиса GitHub. Пакет поставляется в виде образа виртуальной машины, доступной для бесплатного ознакомительного использования в течение 45 дней. Исходные тексты скрыты и поставляются в упакованном виде, напоминающем зашифрованный набор данных. Прозрачная распаковка в момент выполнения осуществляется при помощи библиотеки ruby_concealer.so, анализ которой показал для метод упаковки сводится к сжатию кода при помощи Zlib::Inflate::inflate и прим https://www.opennet.ru/openforum/vsluhforumID3/110116.html#58 Thu, 12 Jan 2017 09:52:35 GMT &gt; SQL-стейтменты должны формироваться автоматом. Простой, хотя и не гибкий и не всегда <br>&gt; применимый способ &#8212; prepared statements.<br><br>А какая связь между автоматическим созданием SQL-стейтмента и prepared?<br> https://www.opennet.ru/openforum/vsluhforumID3/110116.html#54 Mon, 09 Jan 2017 17:03:17 GMT &gt; клоун: если программа работает с внешними данными, то можно подобрать такой их <br>&gt; набор, который приведёт к нарушению корректной работы.<br><br>Только если автор - дол... и не понял что извне таки натурально могут приехать ЛЮБЫЕ данные. А если автор программы к этому готов - то, собственно, какие проблемы?!<br><br>Сейчас вообще мода пошла - fuzz'ить программы. Чтобы проверить что это и правда так. Штуки типа AFL позволяют прицельно кроить структуры, чтобы их не отбил первый же фильтр на входе как явно некорректные и они проехали в более глубокие куски логики. А чтоб посмотреть - не сломается ли что еще и там?<br><br>&gt; Построчно читается банальный текстовый файл? Сделаем несоответствие<br>&gt; размера файла реальным данным, вставим непечатаемые символы, вкл. перевод каретки,<br><br>Нормально написанная программа увидит что файл битый. И прекратит разбор или пропустит проблемные строки, в зависимости от того какие требования. Ну это если программу писал вменяемый человек а не сишарпер/вебмакака, над которыми стоял надсмотрщик с пл https://www.opennet.ru/openforum/vsluhforumID3/110116.html#52 Mon, 09 Jan 2017 15:29:35 GMT это, видимо - отсылка к наградам некоторых компаний<br> https://www.opennet.ru/openforum/vsluhforumID3/110116.html#51 Mon, 09 Jan 2017 14:44:00 GMT &gt; от prepared statements может просесть производительность. Тот же оракл может очень хорошо <br>&gt; оптимизнуть запрос, ежель имеет конкретные значения, а не ps. Так что <br>&gt; я б поостерёгся от утверждений "SQL-стейтменты должны формироваться автоматом".<br><br>Отпимизация случайного возникшего хорошего случая (не забываем, что речь идет о параметрах, формируемых из пользовательсокого ввода) не стоит возникающих из-за нее хлопот. Отпимизировать имеет смысл плохие и средние случаи<br> https://www.opennet.ru/openforum/vsluhforumID3/110116.html#50 Mon, 09 Jan 2017 14:40:01 GMT Ты с ActiveRecord знаком, деточка? ActiveRecord занимается сборкой текстового sql-запроса, и в частности экранированием. Задумка, примерно как в cl-sql: создать язык изоморфный SQL внутри языка общего назначения, чтобы функция query принимала бы запрос не как текстовую строку, а как более сложную структуру данных, которая бы позволяла библиотечному коду знать где строки которые надо подставить в запрос, а где ключевые слова SQL. И там, и там это достигается тем, что ключевые слова SQL передаются в библиотечный код не как строки, а иным путём. Всё же, что не ключевые слова, рассматривается библиотечным кодом как потенциально вредоносные строки, которые экранируются.<br><br>Но если лисп позволяет такие извращения в любых масштабах, благодаря тому, что для лиспа код и данные -- это одна фигня, в лисповский синтаксис можно уложить SQL, и написать код, который будет этот SQL компилировать в строку, то ruby -- хоть и довольно мощный язык, но всё же слабоват для подобного. В результате, не любое SQL-выражение можно запи https://www.opennet.ru/openforum/vsluhforumID3/110116.html#49 Mon, 09 Jan 2017 13:28:08 GMT &gt; Во-первых, я говорил о том, что подобная штука должна быть чем-то стандартным и разбираться в базе<br><br>Реальность, данная нам в ощущениях, явственно говорит, что в существующие SQL RDBMS запросы всовываются в текстовом виде. Да, я знаю, что у многих из таких RDBMS есть альтернативные способы формирования запросов, более структурированные. Однако, речь идет именно об SQL, он ровно такой, какой есть.<br><br>&gt; Во-вторых, она не решает те проблемы, из-за которых обычно начинают руками генерировать SQL<br><br>Ещё как решает. Если в объекте, отвечающем за таблицу, есть фиксированный набор методов/пропертей, описывающих манипуляции с полями, то и в формируемый SQL-запрос можно будет затолкать ровно эти поля.<br><br>&gt; Например, "сунуть в SELECT список полей из конфига".<br><br>В этом случае прикладной программист будет, по первости чертыхаясь и жалуясь на непроизводительную трату времени, писать явный разбор входных данных и явный маппинг токенов в разобранном тексте на вызовы DSL'я.<br><br>Собственно, прямо буквально за соседним столом т https://www.opennet.ru/openforum/vsluhforumID3/110116.html#47 Mon, 09 Jan 2017 12:12:35 GMT И тут ты такой приводишь пример использования prepared statements с задаваемой пользователем сортировкой<br> https://www.opennet.ru/openforum/vsluhforumID3/110116.html#46 Mon, 09 Jan 2017 11:18:10 GMT клоун: Ты в суть проблемы то вник? Они неверно экранировали входные данные. Какие ещё грабли?<br><br>Грабли - это о другом. Напр в php есть уже 3 функции экранирования (экранирование при выводе в HTML, экранирование для SQL, улучшенное экранирование для SQL). Последнее - как раз те самые грабли. "Руководство по собиранию парашюта. Версия вторая. Исправленная". Мало того что они накосячили при первой реализации экранирования, так они ещё оставили обе функции. Более того: они использовали пересекающуюся терминологию (слово "экранирование" в обоих случаях) чтобы накосячил прикладной программист. Вот это грабли как они есть.<br> https://www.opennet.ru/openforum/vsluhforumID3/110116.html#45 Mon, 09 Jan 2017 11:02:15 GMT &gt; Пока запрос пишется в текстовом виде, будут существовать ошибки подстановки в него "инъекций".<br><br>Бла-бла-бла... Ещё какой всемирный закон ты открыл?<br><br>&gt; Сколько тебе лет что ты веришь в священные граали, решающие все проблемы лишь фактом своего существования?<br><br>Сколько _тебе_ лет, что ты никак не можешь излечиться от юношеского максимализма? Если священного грааля не существует, значит не надо, создавая API, думать о том, как бы поменьше граблей туда напихать?<br>