Вопросы безопасности удаленной загрузки касс : ФинСофт:КупецЪ

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

Олег, не совсем понял, что значит "проверит"?

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

Ммм... У этого сервиса есть только копирование файлов и вызов некоторых функций, зашитых в специально прилагаемой dll. Копирует прикладное приложение через специальную библиотеку. Формат обмена не стандартный. Настройка каталогов обмена на сервере с ограниченными правами.

Я сейчас попробовал ради интереса в системные каталоги удаленно записать файлики, винда блокирует. Да нет, там все так построено, что что-то сломать (не говоря уж о взломать) настолько маловероятно, что можно принебречь.

Вот мы так навскидку и блокирует, а кто-то посидит, подумает, и "ой"... Смотри сам, конечно... Я всегда исхожу из того, что если есть подозрение на дырку, то надо подлатать...

Копирование файлов в данном случае функция системной библиотеки. Я и при желании не могу передавать ей что-то, кроме имени файла.

Чтобы запустить процесс копирования, надо специфическими знаниями обладать. Это не стандартная утилита с известными ключиками, типа curl. Копирование инициируется прикладной системой и закрыто от конечного пользователя.

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

Нет, это разработка одной забугорной конторы, которая использует напрямую сокеты (win api).

Ты хочешь сказать, что можно чем-то перехватить передаваемые сообщения и имитировать их каким-то внешнем софтом? Теоретически это возможно, но опять таки, настолько маловероятно... Я когда-то пробовал обмениваться с этим удаленным сервисом в обход библиотеки (читая порт из php), потом забил. Там не просто строки передаются, а какой-то специфичный формат со служебными символами.

В принципе, там еще можно штатно openSSL задействовать. Или фильтрацию по ip адресам на роутере. Или vpn. Или сильно зажать права доступа на удаленном компе. Если по безопасности очень заморачиваться. Но это уже не мои вопросы.

да, просто подключить ту же библиотеку, что и ты. и openssl тут не спасет. фильтрация по адресам и прочее подразумевает достаточно грамотных спецов на месте, чего, я полагаю, по факту не случается. а, как факт, дырка есть... и закрывается она очень легко (должна по крайней мере).
сейчас шлется типа <директория><данные> -> <удаленный узел>-‎∞ (пишу, куда хочу)
а надо сделать <индекс><данные> -> <удаленный узел>-‎<индекс>-<заранее заданная директория>
т.е., получается, снаружи в принципе нельзя выбирать, куда писать данные.

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

Если библиотека используется, то там возможность копирования файлов встроенная и мы не можем обойти логику ее работы.

Чтобы причинить вред удаленному компьютеру, предполагается:
1. На удаленном компьютере можно читать и писать критичные для работы системные файлы. Что, в общем, не соответствует действительности.
2. Не организована защита канала внешними средствами.
3. Найти специалиста, который обладает специфическими знаниями и имеет нужную версию библиотеки и компилятора.
4. Получить каким-то способом реквизиты подключения.

Даже если чисто теоретически предположить, что удалось убить удаленный компьютер, восстановить его работоспособность несопоставимо менее затратно, серьезных проблем бизнесу это не создаст (речь не про сервер), а хакер получит разве что моральное удовлетворение.

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