В СУБД SQLite выявлена (https://blog.talosintelligence.com/2019/05/vulnerability-spo...) уязвимость (https://www.talosintelligence.com/vulnerability_reports/TALO...) (CVE-2019-5018), позволяющая выполнить свой код в системе при наличии возможности выполнения SQL-запроса, подготовленного злоумышленником. Проблема вызвана ошибкой в реализации оконных функций и проявляется начиная с ветки SQLite 3.26 (https://www.opennet.ru/opennews/art.shtml?num=49282). Уязвимость устранена (https://www.sqlite.org/src/info/884b4b7e502b4e99) в апрельском выпуске SQLite 3.28 (https://sqlite.org/releaselog/3_28_0.html) без явного упоминания об исправлении проблем с безопасностью.
Специально оформленный SQL-запрос SELECT может привести к обращению к уже освобождённой области памяти (use-after-free), что может потенциально быть использовано для создания эксплоита для выполнения своего кода в контексте приложения, использующего SQLite. Уязвимость может быть эксплуатирована в случае если приложение допускает передачу в SQLite SQL-конструкций, поступающих извне.
Например, потенциально атака может быть совершена на браузер Chrome и приложения, использующие движок Chromium, так как API WebSQL реализован поверх SQLite и обращается к данной СУБД для обработки SQL-запросов из web-приложений. Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium.URL: https://blog.talosintelligence.com/2019/05/vulnerability-spo...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50658
DROP Chromium WHERE WebSQL NOT NULL;
COMMIT;
ну и зачем ты все испортил? Я ж уже 2 монеры намайнил!
Не поможет. Drop удаляет объект безусловно и коммит не нужен. И IS not null
Ну тогда мы нашли еще один баг, потому какSELECT 'true' WHERE 1 NOT NULL;
вернет 'true' без ошибок ;)
это не баг, это фича simplified syntax, кажется, даже где-то описанная.а вот комит после дропа не нужен, да и синтаксически неверно, наверное, имелось в виду delete.
Да блин, вы правда не понимаете что должно было бы стоять вместо COMMIT если бы не модерация?
ArticFox; -- так пойдет ?
Весьма типичная проблема устаревших языков, к сожалению.
весьма типичный комментарий юных падаванов
Анонимное комментирование и отсутствие бан-листа - зло и неудобство.
Надо опеннету подтягиваться к тренду.
Да, надо как в Белоруссии. Ишь, воду баламутят.
Беларусь, Беларуси.
SQL тебя переживет еще
> Например, потенциально атака может быть совершена на браузер Chrome и приложения, использующие движок ChromiumFirefox тоже активнео использует SQLIte. Кто скажет, там это воспроизводится?
там понадобится вторая уязвимость, которую тебе, о йуный друг, еще предстоит найти.
потому что в отличие от гуглоподелки, sqlite там используется, а не использует твой компьютер по желанию вебмакаки.но это, конечно, ненадолго - только пока ютруп, факбук и гитхап не перешли на новый стандарт.
>новый стандарт.Точно новый?
>W3C Working Group Note 18 November 2010
>Beware. This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further.
>>новый стандарт.
> Точно новый?
>>W3C Working Group Note 18 November 2010В старом, догугловском стандарте его так и нет. А новый стандарт - это Гугл, если что. В ФФ, старом Edge и так далее, этот websql так и не появился.
Так что все правильно.
Проще сказать где SQLite не используется. Он везде. От телефонов до ПК
> Специально оформленный SQL-запрос SELECT может привести к обращению к уже освобождённой области памятиЭто в принципе нетипичная ситуация, когда сторонний `исследователь безопасности` получает контроль над БД. Так как самое важное обычно хранится в БД и если БД слита, то всё остальное уже как-то без разницы. Я к тому, что для получения контроля над БД в приложении должна быть ещё одна критическая уязвимость
В Chromium любой сайт может выполнять запросы к его внутренней SQLite DB.
В поисках пруфов нарвался на игрушку https://github.com/kripken/sql.jshint: ещё пару лет назад sqlite в chromium была задепрекейчена. У меня большие сомнения, что оно работает, поэтому было бы неплохо привести пруф
> hint: ещё пару лет назад sqlite в chromium была задепрекейчена. У меня
> большие сомнения, что оно работает, поэтому было бы неплохо привести пруфhttps://caniuse.com/sql-storage
Подойдет?
Получается, что и всякое УГ на Электроне, тоже в зоне риска.
Net.
> Получается, что и всякое УГ на Электроне, тоже в зоне риска.это приложение на электрона должно обрабатывать внешний сторонний "sql-запрос", а это таки редкость
>> Получается, что и всякое УГ на Электроне, тоже в зоне риска.
> это приложение на электрона должно обрабатывать внешний сторонний "sql-запрос"в том и дело что нет, не должно - достаточно неудачно обработать внешний сторонний js код, а запросов он тебе сам понаделает.
насколько это вот редкость - вопрос отдельно интересный. чота мне кажется, что если бы не нахрен ненужность неуловимых джо на эшелоне, такого бы нашли тыщи.но пока явно надо бояцца не этого, а в интернетиках непосредственно браузером что-нить не побраузить с прекрасным и полезным апи.
"Например, потенциально атака может быть совершена на браузер Chrome и приложения, использующие движок Chromium, так как API WebSQL реализован поверх SQLite и обращается к данной СУБД для обработки SQL-запросов из web-приложений. Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium."
Тот самый WebSQL который не был признан никем кроме Хрома, исключен из стандартов и не поддерживается нигде больше? Тот самый который Гугл почему-то упорно не убирает и который уже не первый раз бьет их по макушке?
Странный Гугл...
> Тот самый WebSQL который не был признан никем кроме Хрома, исключен из
> стандартов и не поддерживается нигде больше? Тот самый который Гугл почему-то
> упорно не убирает и который уже не первый раз бьет их
> по макушке?вообщето если быть обьективным то WebSQL самый удобный по сравнению с LocalStorage & IndexedDB, нормальный гибкий SQL язык позволяющий сложную бизнес логику и простоту использования в JS.
А на счет баги в SQLite, так не ошибается только тот, кто ничего не делает. Код там очень даже профессиональный.Винить надо рукожопых JS-девелоперов позволяющих использовать даные от юзера без валидации:
>"Уязвимость может быть эксплуатирована в случае если __приложение__
> допускает передачу в SQLite SQL-конструкций, поступающих извне. "а это относится к любым ЯП
> Винить надо рукожопых JS-девелоперов позволяющих использовать даные от юзера без валидации:
>>"Уязвимость может быть эксплуатирована в случае если __приложение__
>> допускает передачу в SQLite SQL-конструкций, поступающих извне. "
> а это относится к любым ЯПЭта процитированная часть относится к приложениям, использующим SQLite.
Например, в том числе и Chrome, в котором есть WebSQL, принимающий SQL-конструкции извне .
> Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium.
>> Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium.То, что баг может использоваться специально, - это понятно что не есть хорошо. Я отвечал по поводу WebSQL технологии в принципе.
"Для атаки достаточно создать страницу с вредоносным JavaScript-кодом и добиться чтобы пользователь открыл её в браузере на базе движка Chromium."С учетмо нынешней доли Хрома и ему подобных среди браузеров можно сказать что достаточно открыть её у почти любого пользователя.
а для извращенцев предусмотреть огромный баннер "этот сайт работает только в хроме, хроме и хроме последней версии". Сами и запустят что надо.