Etherpad-lite: Попытки SQL-инъекций убивают Etherpad lite

Это действительно так.
Спасибо за ценную информацию,

Привет, ребята, просто напоминание об ответственном раскрытии информации. Публикация публичных сообщений без возможности выбора может быть довольно опасной.

Привет, ребята, просто напоминание об ответственном раскрытии информации. Публикация публичных сообщений без возможности выбора может быть довольно опасной.

Хм ... на самом деле он уже был раскрыт, потому что его используют какие-то мерзкие парни.

Кроме того, я не знаю, как сообщить об этом закрытым способом. В описании проекта ни в коем случае не упоминается закрытый цикл обратной связи по вопросам безопасности. Как вы думаете, как бы я сообщил об этом?

Afaik, у нас есть политика ответственного раскрытия информации. Я думал, что это на etherpad.org и в readme на github.

От: Франсуа Пулен [email protected]
Отправлено: понедельник, 21 января 2019 г., 11:16
Кому: ether / etherpad-lite
Копия: Джон МакЛир; Комментарий
Тема: Re: [ether / etherpad-lite] Попытки SQL-инъекции убивают Etherpad lite (# 3502)

Привет, ребята, просто напоминание об ответственном раскрытии информации. Публикация публичных сообщений без возможности выбора может быть довольно опасной.

Хм ... на самом деле он уже был раскрыт, потому что его используют какие-то мерзкие парни.

Кроме того, я не знаю, как сообщить об этом закрытым способом. В описании проекта ни в коем случае не упоминается закрытый цикл обратной связи по вопросам безопасности. Как вы думаете, как бы я сообщил об этом?

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/ether/etherpad-lite/issues/3502#issuecomment-456039980 или отключите поток https://github.com/notifications/unsubscribe-auth/ AANewII6dbcPV2hlcP4uA5c4OHESwQJuks5vFaK4gaJpZM4X1_tz .

Было бы неплохо добавить приглашение «обнаружили проблему с безопасностью? Сообщите нам об этом через ...». Прежде чем открыть этот выпуск, я потратил несколько минут на readme на github и на etherpad.org, но не нашел такого приглашения. Кроме того, как иностранный читатель, я мог пропустить хорошие термины, которые нужно было искать.

Принято к сведению. Tnx

От: Франсуа Пулен [email protected]
Отправлено: понедельник, 21 января 2019 г., 14:35
Кому: ether / etherpad-lite
Копия: Джон МакЛир; Комментарий
Тема: Re: [ether / etherpad-lite] Попытки SQL-инъекции убивают Etherpad lite (# 3502)

Было бы неплохо добавить приглашение «обнаружили проблему с безопасностью? Сообщите нам об этом через ...». Прежде чем открыть этот выпуск, я провел несколько минут на github и etherpad.org, но не нашел такого приглашения. Кроме того, как иностранный читатель, я мог пропустить хорошие термины, которые нужно было искать.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/ether/etherpad-lite/issues/3502#issuecomment-456096384 или отключите поток https://github.com/notifications/unsubscribe-auth/ AANewFZlv6xtuszRP2CCBwWoDHGgTrFwks5vFdGEgaJpZM4X1_tz .

Я тоже не смог найти ни одного, но обнаружил, что вы просите PR добавить его https://github.com/ether/etherpad-lite/issues/2499.

Возможно, в качестве быстрого решения можно просто создать https://securitytxt.org/ ?

Оскорбительный код находится где-то здесь: https://github.com/ether/yajsml/blob/master/server.js#L98

Отказ от ответственности: я недостаточно умен, чтобы решить эту проблему. Мне нужен кто-нибудь со знанием дела!

Привет! Немного изучаю это сейчас.

Во-первых: чтобы отразить любые опасения по поводу SQLi: это не имеет ничего общего с SQL-инъекцией, о чем свидетельствует эта альтернативная полезная нагрузка, которая также вызывает такой же сбой:

/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define&footlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootle

Это проблема длины имени файла в промежуточном программном обеспечении кэширования.

В настоящее время ключ кеша генерируется следующим образом:

var cacheKey = Buffer.from(path).toString('base64').replace(/[/+=]/g, '');

Это приводит к тому, что длина ключа кеша контролируется длиной пути.

Это проблема, когда ключ кеша используется в качестве имени файла на диске, поскольку многие файловые системы ограничивают длину имени файла 255 символами. Вот почему в журнале есть ошибка ENAMETOOLONG .

Чтобы исправить это, я предлагаю сделать ключ кеша хешем пути вместо версии в кодировке base64. Это обеспечит имя файла фиксированной длины.

Я отправлю PR, который сделает это в ближайшее время.

Привет, @tomnomnom , это умно. Совершенно очевидно, что ключи кеша имеют фиксированную длину. Таким образом, они остаются зависимыми от контента, при этом риск столкновений практически отсутствует.

Я посмотрю сегодня вечером.
Отличная работа!

Слил пиар, огромное спасибо!

Еще одно замечание об этом: из документации nodejs нам, возможно, придется рассмотреть возможность недоступности модуля crypto :

Node.js может быть собран без поддержки криптографического модуля. В таких случаях вызов require ('crypto') приведет к выдаче ошибки.

Может быть, встроенные платформы могут не иметь его (например, ARM, MIPS, Raspberry PI и т.п.)? Я не знаю. Описание таких сценариев можно найти здесь :

• запуск нестандартного узла в среде с ограниченными ресурсами или безопасностью (см. узел # 5611 для их явной поддержки этого сценария)
• работает в эмулируемой среде (браузер, веб-пакет и т. д.)
• создание узла из источника и исключение openssl / crypto по случайной причине (см. вопрос о StackOverflow или другой пост nodejs )

В любом случае, ребята из TypeScript решили эту же проблему в https://github.com/microsoft/TypeScript/issues/19100 , и они решили ее элегантным способом в https://github.com/microsoft/TypeScript/commit/ 9677b0641cc5ba7d8b701b4f892ed7e54ceaee9a.

Если импортированная криптовалюта терпит неудачу во время выполнения, они заменяют хеш-алгоритм алгоритмом djb2 , который намного слабее, но работает в их случае.

Пример, адаптированный для нашего случая, может быть:

function djb2Hash(data) {
    const chars = data.split("").map(str => str.charCodeAt(0));
    return `${chars.reduce((prev, curr) => ((prev << 5) + prev) + curr, 5381)}`;
}

console.log(Buffer.from(djb2Hash('This is a 😎 test of the djb2 hash function')).toString('hex'));
// prints 36373536373437333033

Я не прошу вас делать это, но история djb2 забавна: см. Здесь и исходное сообщение в списке рассылки Даниэля Бернстайна от 1991 года. Ему тогда было 20 лет .

Дополнительная информация, которая использует djb2 при отсутствии поддержки криптографии: # 3797.