Условий много получается, чтобы через локальную сеть зайти. 1. Пользователь должен зайти на фишинговый сайт. 2. Браузер игнорировать CORS, 3. Не должно быть антивируся, который это определит. 4. Быть подключенным через роутер, причем основную сеть (не гостевую). 5. Роутер с ip адресом по умолчанию.
Чтобы это запрос сделать, нужен включенный удаленный доступ к управлению в роутере и возможность подключения к нему с произвольного ip. А такого сочетания не должно быть изначально.
Так уязвимость и возникает когда он открыт. Иначе для ее эксплуатации хакеру надо “влезть” сначала на устройство за роутером (ну тогда и роутер уже не особо нужен).
Не понял, причем тут “дырявость” ? Веб-доступ с basic аутентификацией вещь изначально непримлемая ни для какого сколь-нибудь серъезной задачи. Провайдер должен понимать это. Можно ставить модели, где есть нормальный доступ (например по SSH с ключом). Ограничивать доступ к портам, чтобы они были доступны только тех. своей поддержке, но не вообще из любого места в интернете. Варинтов много.
Эксплуатация уязвимости из внутренней сети возможна, конечно. Но если хакер проник на устройство за роутером, то способов продвижения по обычной домашней внутренней сети предостаточно и без роутера.
Так чтобы в каком-то роутере была уязвимость, позволяющая “влезть” в него из интернета при закрытых портах и отключенных средствах типа встроенных торрент качалках, автоообновлениях прошивок (т.е. когда роутер это чисто роутер и ничего больше) - это по-моему совсем редкость.
Что за “вторичка” в канализации не знаю. Для X40 по инструкции высота места присоединения сливной трубки к канализации рекомендуется не более 80 см. На 40 см точно качает (у меня столько). Полную трубку (это примерно 5 метров), прокачивает (проверял сразу после покупки, ничего не присоединяя, а просто направив конец трубки в ведро, никакого уклона при этом не было, трубка лежала свитая кольцами на док станции). Обратный клапан на выходе есть. Думаю что для X60 примерно такие же параметры. Почему у автора не прокачал - не знаю, может сам док-станция неисправна была. (У меня в док-станции одна из трубок была неудачно проложена и пережата).
Насколько я понял, эта уязвимость работает, если на роутере включен доступ к веб-интерфейсу со стороны WAN. Позволяет обойти аутентификацию. Однако “домохозяйке” такой доступ вряд ли нужен, да и отключен он обычно по умолчанию. А вот тех. специалисты провайдера устанавливая роутер вполне могут его включить “для удобства техподдержки”, причем не сказав пользователю. И это ничем принципиально не отличается от ситуации, когда роутер без уязвимостей, но провайдер поставил слабый пароль, или просто список паролей абонентов от провайдера утек. Так что кто кому проблемы создает еще вопрос.
Если банк допускает одновременный вход с двух компьютеров (а некоторые допускают нескольких пользователей, в т.ч. с разными правами (директор / бухгалтер)), то никакие копейки гонять не надо.
Один пользователь создает “черновик” платежного поручения, другой его читает. Но платежное поручение это крайний случай, обычно есть и более пригодные для этой цели документы. Например обращение в банк, где и ограничения по длине нет, и файлы можно прикреплять.
Это же касается и многих других сайтов. Почти везде есть “черновики”, неважно чего - обращений, писем, проектов документов, в которых есть поле свободного назначения (“Примечание”, “комментарий”) заказов, карточек товаров (“описание”) и проч.
Я понял так. Мошенник купил товар. Потому оформляет возврат а от имени ПВЗ отмечает что возврат выполнен (хотя реально товаров не возвращалось). МП на основании подтверждения ПВЗ возвращает деньги покупателю (мошеннику). В итоге мошенник получает товар бесплатно. Вопрос в том, что не если бы документы оформллись по правилам бухучета, то они должны быть либо на бумаге (с "бумажной" подписью) либо в виде электронных документов с усиленной электронной подписью. (Т.е. создаваемой закрытым ключем, который не знает никто. кроме владельца)). А когда в наличии только ПЭП (простая электронная подпись) разумеется доказать что операции в действительности не было, весьма сложно. Причем это могло быть в реальности и не мошенничество, а просто сбой в базе.
Странно, я всегда считал что когда подобный процесс (даже безо всякого ИИ) пошел не по плану, это штатная ситуация. Исправляется откатом на состояние до начала операции. Очевидно, что как только стало ясно что дело идет не по плану (удалилось (или даже могло удалиться) хотя бы одно письмо), никакой срочности в kill / stop уже нет - надо будет восстанавливать данные.
Конечную продукцию можно исключить из-за маркировки. Остается оптовая продажа, где продукция она используется на следующей стадии как сырье (ткань например). Покупатель перед заказом попросит на товар документацию, сертификаты, прочие документы. В сертификате указан конкретный производитель. Если продукция по ТУ то оно на конкретного производителя. И так во всем. Соответственно отгружать надо будет продукцию того же производителя. Не говоря уже о качестве самой продукции (если это, конечно, реальное производство, а не наклеивание шильдиков на китайский товар). Оно различается (плотность, толщина и проч). А это сырье для следующей стадии производства. Нельзя просто так поменять качество сырья (поставщика) без перенастройки производственных линий. Поэтому не особо реальная ситуация.
Почему у вас при все плюсах решения 1 выбрано 2 я не понял. В Файле по ссылке есть утверждение про "доработка реализована через расширение. Типовое обновление не приводит к конфликтам". Непонятно на чем основано. Код же меняется. Всегда могут быть изменения в конфигурации поставщика, влияющие на доработки. Не понял почему в варианте 1 надо дорабатывать код для новых видов поступлений - привязку в типам документов может вынести в отдельный справочник.
Можно вообще не менять код типовой конфигурации. Уже после штатного формирования проводок отдельной обработкой менял счет учета. Именно в плане максимально простой поддержки, совместимости с обновлениям. Потому что задача намного сложнее, чем Вы пишете. Кроме Приобретения и Выпуска партии могут создаваться возвратами, пересортицами, излишкам. У Вас рассмотрено только одно юр. лицо, а может появиться второе. Тогда добавятся еще и передачи товаров между организациями. В сочетании с возврвтами это может приводить к потере исходных партий.
Постановку задачи, видимо, нейросеть писала. Во-первых, упомянутые в статье товары легкой промышленности в РФ уже несколько лет под маркировкой ("Честный знак"). Это поэкземплярный учет. Во-вторых даже если продукция каким-то образом и не под маркировкой, то у нее будет сертификат или хотя бы декларация соответствия. Где будет указан производитель. Он же должен быть указан на упаковках для розничной продажи. Какой-нибудь частник на рынке может продавать просто "гвозди". Но на предприятии с ERP никакого смешения не будет. Не говоря уже о таких вещах, как необходимость контроля качества, отслеживания бракованных партий и т.п.
Видимо на основании лога. Представьте, что покупателю в магазине дают купон на скидку, в нем написано: скидка 30%. А когда этот купон покупатель предъявляет на кассе, говорят что "у нас нет такого в системе" и в скидке отказывают. При том что купон оригинальный (не подделка). Конечно покупатель пойдет в суд.
Скидка может выдаваться случайным образом (типа лотереи), в т.ч. скриптом. Также с непредсказуемым результатом. И ничего тут пока не выяснилось. Я так понял, что магазин вернул деньги. Но он мог сделать это и против воли покупателя. Не говорится ничего о том, что покупатель отказался от намерения обратиться в суд.
Как в Великобритании, не знаю, но в РФ участником гражданского ИИ оборота не является. Только юридические и физические лица. ИИ ничем принципиально не отличается от любой другой программы, рассчитывающей цены / скидки. Например, скрипта на сайте. Нарушение со стороны клиента будет если клиент выторговывая скидку сообщил заведомо недостоверную информацию - например обещал в будущем сделать много заказов, которые он заведомо сделать не мог и т.п. Если просто уговорил, в итоге магазин сделал оферту (предложил купить товар по такой-то цене), а покупатель - акцептовал ее (оплатил товар) - то нет оснований не исполнять договор.
На просьбу предоставить платежный документ (кроме случаев, явно предусмотренных законом) гражданин имеет полное право дать отказ. Такая просьба - демонстрация неуважения к клиентам. Потому что платежный документ через банковскую систему при зачислении денег передается получателю платежа (в электронном виде). Точно такой же, у плательщика - списание со счета, у получателя - зачисление на счет. Идите в свою бухгалтерию и ищите там.
"Оплатил от своего имени" уже года 3 как не работает (ну если только в "черной" бухгалтерии). Если сотрудник действует от имени юр. лица он обязан сообщить об этом контрагенту и контрагент в кассовом чеке должен указать ИНН и название юр. лица покупателя. А если нужен зачет НДС - еще и счет-фактуру выписать. Иначе юр. лицо не сможет принять расходы по авансовому отчету.
Данные, скан, паспорта не подтверждают вообще ничего. Паспорт это не вексель на предъявителя. Паспорт подтверждает личность только при предъявлении владельцем.
Банковские документы подтверждают что платило конкретное физ. лицо, и то при условии что это обычное платежное поручение со счета физ. лица, где указан номер счета и плательщик полностью. А не какой-нибудь чек из терминала, где написано что оплата по договору за такого-то (по факту любой может написать за любого)
Наличие платежных документов в письме с почты не подтверждает, что данная почта принадлежит указанному в документах лицу. Вообще никак. Поэтому зная физ. лицо самый простой законный способ передать управление именно ему - сбросить пароль и отправить по адресу регистрации по почте заказным / ценным письмом.
Более современный способ - попросить прислать заявление, подписанное усиленной квалифицированной электронной подписью, в нем физ. лицо указывает почту, куда прислать пароль. Пароль еще и зашифровать сертфиикатом этого физ. лица Если у физ. лица УКЭП нет - идет к нотариусу, пишет заявление на бумаге, нотариус заверяет подпись, сканирует, подписывает скан своей УКЭП (нотариуса), выдает файл со сканом и файл с подписью заявителю, тот отправляет Вам.
Оно и штатно делается без потери контекста (перезапуска, открытия форм и проч). Код метода копируется во внешнюю обработку, в самом методе делается создание этой обработки и вызов метода из модуля обработки (формы обработки, если это клиентскиий код). Отладка при этом работает. И можно добавлять методы (которые будут вызываться из уже вынесенных в обработку). Благо при отладке какого-то процесса набор методов которые надо менять, небольшой и их можно вынести заранее. Но тут, конечно, более автоматизированно.
Условий много получается, чтобы через локальную сеть зайти. 1. Пользователь должен зайти на фишинговый сайт. 2. Браузер игнорировать CORS, 3. Не должно быть антивируся, который это определит. 4. Быть подключенным через роутер, причем основную сеть (не гостевую). 5. Роутер с ip адресом по умолчанию.
С удаленным доступом все намного проще.
Тогда и у другим роутерам можно пробовать получить доступ, используя, например, пароли по умолчанию или наиболее часто встречающиеся.
Чтобы это запрос сделать, нужен включенный удаленный доступ к управлению в роутере и возможность подключения к нему с произвольного ip. А такого сочетания не должно быть изначально.
Так уязвимость и возникает когда он открыт. Иначе для ее эксплуатации хакеру надо “влезть” сначала на устройство за роутером (ну тогда и роутер уже не особо нужен).
Не понял, причем тут “дырявость” ? Веб-доступ с basic аутентификацией вещь изначально непримлемая ни для какого сколь-нибудь серъезной задачи. Провайдер должен понимать это. Можно ставить модели, где есть нормальный доступ (например по SSH с ключом). Ограничивать доступ к портам, чтобы они были доступны только тех. своей поддержке, но не вообще из любого места в интернете. Варинтов много.
Эксплуатация уязвимости из внутренней сети возможна, конечно. Но если хакер проник на устройство за роутером, то способов продвижения по обычной домашней внутренней сети предостаточно и без роутера.
Так чтобы в каком-то роутере была уязвимость, позволяющая “влезть” в него из интернета при закрытых портах и отключенных средствах типа встроенных торрент качалках, автоообновлениях прошивок (т.е. когда роутер это чисто роутер и ничего больше) - это по-моему совсем редкость.
Думаю, что просто обязали провайдеров зайти на роутеры через штатный удаленный доступ и проверить настройки.
Что за “вторичка” в канализации не знаю. Для X40 по инструкции высота места присоединения сливной трубки к канализации рекомендуется не более 80 см. На 40 см точно качает (у меня столько). Полную трубку (это примерно 5 метров), прокачивает (проверял сразу после покупки, ничего не присоединяя, а просто направив конец трубки в ведро, никакого уклона при этом не было, трубка лежала свитая кольцами на док станции). Обратный клапан на выходе есть. Думаю что для X60 примерно такие же параметры. Почему у автора не прокачал - не знаю, может сам док-станция неисправна была. (У меня в док-станции одна из трубок была неудачно проложена и пережата).
Насколько я понял, эта уязвимость работает, если на роутере включен доступ к веб-интерфейсу со стороны WAN. Позволяет обойти аутентификацию. Однако “домохозяйке” такой доступ вряд ли нужен, да и отключен он обычно по умолчанию. А вот тех. специалисты провайдера устанавливая роутер вполне могут его включить “для удобства техподдержки”, причем не сказав пользователю. И это ничем принципиально не отличается от ситуации, когда роутер без уязвимостей, но провайдер поставил слабый пароль, или просто список паролей абонентов от провайдера утек. Так что кто кому проблемы создает еще вопрос.
Если банк допускает одновременный вход с двух компьютеров (а некоторые допускают нескольких пользователей, в т.ч. с разными правами (директор / бухгалтер)), то никакие копейки гонять не надо.
Один пользователь создает “черновик” платежного поручения, другой его читает. Но платежное поручение это крайний случай, обычно есть и более пригодные для этой цели документы. Например обращение в банк, где и ограничения по длине нет, и файлы можно прикреплять.
Это же касается и многих других сайтов. Почти везде есть “черновики”, неважно чего - обращений, писем, проектов документов, в которых есть поле свободного назначения (“Примечание”, “комментарий”) заказов, карточек товаров (“описание”) и проч.
Я понял так. Мошенник купил товар. Потому оформляет возврат а от имени ПВЗ отмечает что возврат выполнен (хотя реально товаров не возвращалось). МП на основании подтверждения ПВЗ возвращает деньги покупателю (мошеннику). В итоге мошенник получает товар бесплатно.
Вопрос в том, что не если бы документы оформллись по правилам бухучета, то они должны быть либо на бумаге (с "бумажной" подписью) либо в виде электронных документов с усиленной электронной подписью. (Т.е. создаваемой закрытым ключем, который не знает никто. кроме владельца)).
А когда в наличии только ПЭП (простая электронная подпись) разумеется доказать что операции в действительности не было, весьма сложно. Причем это могло быть в реальности и не мошенничество, а просто сбой в базе.
Странно, я всегда считал что когда подобный процесс (даже безо всякого ИИ) пошел не по плану, это штатная ситуация. Исправляется откатом на состояние до начала операции. Очевидно, что как только стало ясно что дело идет не по плану (удалилось (или даже могло удалиться) хотя бы одно письмо), никакой срочности в kill / stop уже нет - надо будет восстанавливать данные.
Конечную продукцию можно исключить из-за маркировки. Остается оптовая продажа, где продукция она используется на следующей стадии как сырье (ткань например). Покупатель перед заказом попросит на товар документацию, сертификаты, прочие документы. В сертификате указан конкретный производитель. Если продукция по ТУ то оно на конкретного производителя. И так во всем. Соответственно отгружать надо будет продукцию того же производителя. Не говоря уже о качестве самой продукции (если это, конечно, реальное производство, а не наклеивание шильдиков на китайский товар). Оно различается (плотность, толщина и проч). А это сырье для следующей стадии производства. Нельзя просто так поменять качество сырья (поставщика) без перенастройки производственных линий. Поэтому не особо реальная ситуация.
Почему у вас при все плюсах решения 1 выбрано 2 я не понял. В Файле по ссылке есть утверждение про "доработка реализована через расширение. Типовое обновление не приводит к конфликтам". Непонятно на чем основано. Код же меняется. Всегда могут быть изменения в конфигурации поставщика, влияющие на доработки. Не понял почему в варианте 1 надо дорабатывать код для новых видов поступлений - привязку в типам документов может вынести в отдельный справочник.
Можно вообще не менять код типовой конфигурации. Уже после штатного формирования проводок отдельной обработкой менял счет учета. Именно в плане максимально простой поддержки, совместимости с обновлениям. Потому что задача намного сложнее, чем Вы пишете. Кроме Приобретения и Выпуска партии могут создаваться возвратами, пересортицами, излишкам. У Вас рассмотрено только одно юр. лицо, а может появиться второе. Тогда добавятся еще и передачи товаров между организациями. В сочетании с возврвтами это может приводить к потере исходных партий.
Постановку задачи, видимо, нейросеть писала.
Во-первых, упомянутые в статье товары легкой промышленности в РФ уже несколько лет под маркировкой ("Честный знак"). Это поэкземплярный учет.
Во-вторых даже если продукция каким-то образом и не под маркировкой, то у нее будет сертификат или хотя бы декларация соответствия. Где будет указан производитель. Он же должен быть указан на упаковках для розничной продажи. Какой-нибудь частник на рынке может продавать просто "гвозди". Но на предприятии с ERP никакого смешения не будет. Не говоря уже о таких вещах, как необходимость контроля качества, отслеживания бракованных партий и т.п.
Видимо на основании лога. Представьте, что покупателю в магазине дают купон на скидку, в нем написано: скидка 30%. А когда этот купон покупатель предъявляет на кассе, говорят что "у нас нет такого в системе" и в скидке отказывают. При том что купон оригинальный (не подделка). Конечно покупатель пойдет в суд.
Скидка может выдаваться случайным образом (типа лотереи), в т.ч. скриптом. Также с непредсказуемым результатом. И ничего тут пока не выяснилось. Я так понял, что магазин вернул деньги. Но он мог сделать это и против воли покупателя. Не говорится ничего о том, что покупатель отказался от намерения обратиться в суд.
Как в Великобритании, не знаю, но в РФ участником гражданского ИИ оборота не является. Только юридические и физические лица. ИИ ничем принципиально не отличается от любой другой программы, рассчитывающей цены / скидки. Например, скрипта на сайте. Нарушение со стороны клиента будет если клиент выторговывая скидку сообщил заведомо недостоверную информацию - например обещал в будущем сделать много заказов, которые он заведомо сделать не мог и т.п. Если просто уговорил, в итоге магазин сделал оферту (предложил купить товар по такой-то цене), а покупатель - акцептовал ее (оплатил товар) - то нет оснований не исполнять договор.
На просьбу предоставить платежный документ (кроме случаев, явно предусмотренных законом) гражданин имеет полное право дать отказ. Такая просьба - демонстрация неуважения к клиентам. Потому что платежный документ через банковскую систему при зачислении денег передается получателю платежа (в электронном виде). Точно такой же, у плательщика - списание со счета, у получателя - зачисление на счет. Идите в свою бухгалтерию и ищите там.
"Оплатил от своего имени" уже года 3 как не работает (ну если только в "черной" бухгалтерии). Если сотрудник действует от имени юр. лица он обязан сообщить об этом контрагенту и контрагент в кассовом чеке должен указать ИНН и название юр. лица покупателя. А если нужен зачет НДС - еще и счет-фактуру выписать. Иначе юр. лицо не сможет принять расходы по авансовому отчету.
Данные, скан, паспорта не подтверждают вообще ничего. Паспорт это не вексель на предъявителя. Паспорт подтверждает личность только при предъявлении владельцем.
Банковские документы подтверждают что платило конкретное физ. лицо, и то при условии что это обычное платежное поручение со счета физ. лица, где указан номер счета и плательщик полностью. А не какой-нибудь чек из терминала, где написано что оплата по договору за такого-то (по факту любой может написать за любого)
Наличие платежных документов в письме с почты не подтверждает, что данная почта принадлежит указанному в документах лицу. Вообще никак.
Поэтому зная физ. лицо самый простой законный способ передать управление именно ему - сбросить пароль и отправить по адресу регистрации по почте заказным / ценным письмом.
Более современный способ - попросить прислать заявление, подписанное усиленной квалифицированной электронной подписью, в нем физ. лицо указывает почту, куда прислать пароль. Пароль еще и зашифровать сертфиикатом этого физ. лица
Если у физ. лица УКЭП нет - идет к нотариусу, пишет заявление на бумаге, нотариус заверяет подпись, сканирует, подписывает скан своей УКЭП (нотариуса), выдает файл со сканом и файл с подписью заявителю, тот отправляет Вам.
Оно и штатно делается без потери контекста (перезапуска, открытия форм и проч). Код метода копируется во внешнюю обработку, в самом методе делается создание этой обработки и вызов метода из модуля обработки (формы обработки, если это клиентскиий код). Отладка при этом работает. И можно добавлять методы (которые будут вызываться из уже вынесенных в обработку). Благо при отладке какого-то процесса набор методов которые надо менять, небольшой и их можно вынести заранее. Но тут, конечно, более автоматизированно.