In english Хотелка Об авторе

Разное-админское

  • Чтобы proftpd обслуживал только виртуальных пользователей, например из некой таблицы в базе MySQL с помощью mod_sql, и не использовал PAM, в том числе /etc/passwd, AuthPAM Off недостаточно, этот параметр уже deprecated. Настоящие мужчины пишут в конфиге

AuthOrder mod_sql.c

  • Некоторые фичи Invision Power Board не работают с mod_security. Например, гламурно-ajax'вая правка сообщений или shoutbox. Дело видимо в кривой реализации аякса (хотя могу ошибаться, исходики не смотрел) или банальном отсутствии enctype у форм: не эскейпятся должным образом данные, передаваемые методом POST. Вместо того, чтобы исправить скрипты, их поддержка рекомендует выключить проверку корректности запросов:

SecFilterCheckURLEncoding Off

Два клиента за три дня попросили отключить.

Top

Категория: работа Слова: proftpd, mod_security, apache, IPB
@lj

Комментарии Отключены

ZYV

Я писал для IPB 2.x такой патч и некоторое кол-во человек потом его даже купило :) По-моему, всё же дело не в эскейпинге, а в кривом правиле из набора SNORT или откуда-то ещё :) В общем если % заменять на какую-то другую последовательность символов, то всё прокатывает. Я думал, что, видимо, тем, кто писал это правило, не приходило в голову, что по какой-то причине могут передаваться юникодные данные в виде эскейп-кодов.

А какой правильный формат должен ожидаться, в таком случае?!

17.02.2008 // 22:19 [ ссылка ]

Ответ от Автора

Правильный формат – тот, что получается, если приментить rawurlencode (http://www.faqs.org/rfcs/rfc1738) или urlencode. А IPB делает как-то иначе (сейчас точно не скажу, но мне оказалось проще отключить mod_security для пары клиентов, чем разбираться, что там не так), и mod_security такие запросы зарезает, хотя в его отсутствие работает всё нормально.

17.02.2008 // 23:38 [ ссылка ]

ZYV

Хмм... Наконец-то у меня сложилась более ли менее полная картина.

Вообще, отталкиваться надо от [ ссылка ] Далее мы узнаем, что формат POST подразумевает rawurlencode("control1=value1&control2=value2") (по RFC-1738) при использовании application/x-www-form-urlencoded. При использовании multipart/form-data всё сложнее.

IPB использует:

url = url.replace(regcheck[i], '%u00' + (regcheck[i].charCodeAt(0) & 0xFF).toString(16).toUpperCase());

Мой патч убирает %, заменяя его другим символом (*@*, скажем), что, в принципе, решает проблему, но только если этот символ живет в нижнее 0xFF по Юникоду, u и HEX-коды - как раз тот случай.

Остаётся один вопрос - с какого перепоя Матт Мешам выбрал такое кодирование? Моё предположение - он обкурился [ ссылка ] и решил, что раз все пользуются escape(), оно есть замена RFC-1738, а последней утонул где-то в Лете.

Итог такой: очевидно, что RFC-1738 подустарел, т.к. такое кодирование не позволяет закодировать всю таблицу Юникода. Но и поступать так, как поступил Матт не этично - всё же он в силе. Значит надо либо поступать так, как я (= придумать своё, но обратно совместимое кодирование), либо делать что-то в стиле rawurlencode(utf8_encode()) на JS и, потом на server-side обратную операцию и не иметь проблем. Что более геморройно.

Ура!

P.S. Я, кстати, не разобравшись с проблемой заменял на *$*, и mod_security это съедал, что говорит о том, что полной ясности в уме Ивана Рустика, не наблюдается, так же, как не наблюдалось у меня. А может он боялся, что слишком много сразу сломает, потому, что итак сейчас кодируют кто во что горазд, особенно если посмотреть на реализацию WAP в телефонах (и их поведение при использовании UTF-8/UTF-16).

18.02.2008 // 01:42 [ ссылка ]