Секьюрность некриптованного rsync-а.

[vitus_wagner]

Вот представьте себе, что есть сайт. Файлы на этот сайт выкладываются с помощью rsync, причем не с -e ssh, а с двумя двоеточиями после hostname. Кто не понял, зачем там два двоеточия, прекращает читать этот пост, читает man rsync, и возвращается сюда просветленный

Comments

[_slw]

инжекции боимся?
в html тоже можно какой js инжектнуть, после которого и репутация сайта пострадает и вообще заблокировать могут

[qkowlew]

Полагаю - всё-таки в данном случае речь о том, что "подслушают" и смогут ли использовать.

[alll]

> файлы паролей для Basic Auth там внутри дерева не лежат

Это они сейчас не лежат. А через год-два-пять - кто знает.

[vitus_wagner]

Для файлов паролей есть другое место в файловой системе. Куда, конечно, можно открыть rsync, но вот туда уже - только по VPN. Хотя удобнее будет докрутить web-ui к неим(который по https), чтобы позволял добавлять-удалять юзеров, а не только менять пароль текущему юзеру.

[qkowlew]

Если ВСЯ информация, передаваемая по открытому протоколу - в конечном итоге доступна по открытому же протоколу http на страницах сайта - да, ничего страшного.

Да, если есть хотя бы один php или иной исполняемый скрипт, содержимое которого может стать известно злоумышленнику (подчеркну - не перезаписано злоумышленником, а просто известно) - то резко повышается опасность раскапывания его с целью применения его для XSS-атаки. Что тоже следует учитывать.

Я вот на одном сайте у себя на хостинге долго возился чтобы устранить XSS уязвимость. :(
После чего в собственный код умудрился посадить таковую. :)

[amarao_san]

Если на сайте есть хоть какая-то авторизация, доступная JS'у (или динамические данные), то могут утырить, подсунув js для XSS mitm'ом.

[qkowlew]

js читается и прямо с http сайта. Не аргумент.

[amarao_san]

Я говорю про модификацию трафика, то есть "записать свой js" на сайт.

[vitus_wagner]

В смысле, есть известные способы обойти защиту от модификации, встроенную в протокол rsync?

[qkowlew]

Ага. Нашёл живой пример со своего хостинга.
Имеем SSI код вида:

имеем структуру каталогов

domain.com/html/ - корень сайта
domain.com/cgi-bin/ - выполняемое cgi (специально разведено в сторону от корня)

Информация о том, какой тут есть исполняемый ibanner с параметрами - достаточно интересная для XSS и похожих по смыслу атак на сайт.

[vitus_wagner]

Ну это типичный случай как бы php - исполняемого на сервере кода, встроенного в html.

[qkowlew]

"Более чистый пример" из и так анализируемого многими ботами-коллекторами - HTML FORM и ссылка в ней.

Короче - я со своим опытом хостингосерверного строения не могу найти действительно сильного аргумента за обязательное шифрование трафика в рамках поставленной задачи. Если так построивший сайт человек ДОСТАТОЧНО ДИСЦИПЛИНИРОВАН и не нарушает условий (например - ни разу не промахнулся с тем, куда положить .htpasswd файл

[vitus_wagner]

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

В общем, получилось, при условии, что все юзеры используют внешнюю по отношению к данному сайту (например OpenID) аутентификацию, либо мы готовы пойти на то, чтобы связаться со всеми юзерами, которые имели локальую аутентификацию, по имеющимся в открытом доступе контактам и сообщить им что "на клоне у вас пароль такой-то".