Необходима бомба замедленного действия в приложении ASP.NET
Мы разработали специальное приложение ASP.NET для использования в интрасети наших клиентов. Похоже, они вряд ли заплатят за это, поэтому наш босс хотел бы, чтобы мы внедрили бомбу замедленного действия.
[Edit:] Технические ответы только, пожалуйста! Является ли это хорошей (или юридической) идеей - вопрос для CEOoverflow.com;-)
Все страницы в приложении наследуются от класса ApplicationBasePage и имеют согласованную обработку ошибок, поэтому я думаю, что исключение в начале жизненного цикла ApplicationBasePage будет простым способом сделать приложение непригодным для использования. Я открыт для других идей, которые вы можете иметь, хотя.
Мой вопрос: как и где мы должны хранить дату истечения срока действия заявки?
Некоторые моменты, на которые следует обратить внимание:
- Приложение устанавливается на одном сервере в офисах заказчика.
- Данные приложения хранятся в базе данных SQL Server 2005 на том же сервере. База данных была разработана нами и не используется ни для чего другого.
- Приложение доступно только в их интранете: нет доступа к приложению через Интернет.
- В настоящее время у нас есть удаленный доступ к рабочему столу на их сервере, но мы ожидаем, что потеряем его, если все пойдет не так.
- Приложение написано на.NET 2.0.
- Безопасность обрабатывается с помощью FormsAuthentication.
- Нам нужно иметь возможность отключить часовую бомбу или легко изменить ее дату запуска (предположим, что для этого у нас еще есть доступ к удаленному рабочему столу).
- Сервер обычно может получить доступ к Интернету, но было бы лучше не полагаться на это.
- Бомба замедленного действия только блокирует пользователей: она не уничтожит никаких данных.
- Если это не срабатывает, клиент никогда не должен знать о существовании бомбы замедленного действия.
- Их айтишник с удовольствием покопается в web.config или в базе данных. Он не программист, но он не боится что-то менять "просто чтобы посмотреть, что происходит". Декомпиляция или обратный инжиниринг приложения будут за пределами его возможностей.
Для дополнительного кредита, насколько вы считаете, что в этом случае можно положиться на безопасность через неизвестность?
[ Редактировать: ]
- Приложение выполняет множество важных бизнес-задач, связанных с датами, поэтому мы можем быть уверены, что они не изменят время на своем сервере, поскольку это сделает приложение хуже, чем бесполезным.
23 ответа
Спасибо за все ваши ответы!
Мы не совсем делали то, что предлагал один человек, но использовали идеи нескольких из вас.
Во-первых, мы перестали называть это бомбой замедленного действия и вместо этого назвали ее лицензией. Поскольку в настоящее время программное обеспечение (возможно) является неполным, и поскольку клиент не заплатил за него, мы можем назвать его тестовой версией, срок действия которой истекает. Это (вероятно) помогает нам преодолеть большую часть законного минного поля, и (как указал zsharp), если они утверждают, что продукт не соответствует стандартам, они не могут жаловаться, если не могут его использовать.
В любом случае, техническая реализация выглядит так:
Мы хотели, чтобы дата истечения срока была скрыта там, где ее нельзя было бы наткнуться, и, если бы она была замечена, была бы в форме, которую нельзя было бы легко изменить. Это также должно было быть где-то, мы могли быть уверены, что не пострадали бы непреднамеренно, даже несмотря на то, что на сервере мы не имеем такого большого контроля.
Таким образом, мы зашифровали дату окончания срока действия и поместили ее в Расширенное свойство в базу данных, которую использует приложение, присвоив ей подходящее вводящее в заблуждение имя.
Приложение проверяет ключ при запуске, устанавливая статический логический флаг в значение true, если срок действия приложения не истек. Каждая страница сайта проверяет этот флаг и перенаправляет пользователя на страницу ошибки, если флаг имеет значение false.
Мы рады этому решению по следующим причинам:
- Нам легко изменить срок действия заявки.
- Нет никакой зависимости от доступности интернета или чего-либо еще кроме их сервера.
- Защита выдержит резервное копирование и восстановление, или приложение будет перемещено в другой ящик.
Когда аргументы прекратились, они заплатили нам, и мы снова все друзья, следующее обновление их приложения вообще не будет проверено, гарантируя, что этот забытый кусок кода не будет случайно запущен в некоторых случаях. указать годы вниз по линии (спасибо, Кристен!).
"Они вряд ли заплатят за это, поэтому наш босс хотел бы, чтобы мы внедрили бомбу замедленного действия".
Вас некомпетентный бизнесмен просит вас найти техническое решение бизнес-проблемы. Если ваш клиент не собирается платить, ваш босс должен иметь дело с ситуацией, подобной взрослому, и не использовать логические бомбы, как хакер из старшей школы.
Это неэтично, возможно, незаконно, но в основном это просто глупо.
Я согласен с комментарием о том, чтобы назвать его пробной версией и дать ей истечь. В одном из наших продуктов, системе веб-публикации, у нас есть общий класс страниц, который будет проверять лицензионный ключ пользователя, и, если он недействителен, мы распечатаем сообщение в верхней части всех страниц. Сообщение очень хорошо видно, но оно не влияет на работу программы.
Для проверки мы храним "регистрационный ключ" в файле web.config. Мы сравниваем это с ключом, который вычисляем, и алгоритм его вычисления хранится в отдельной сборке. Если ключи совпадают, мы предполагаем, что продукт лицензирован.
Для нашего использования мы предоставляем только имя клиента для алгоритма расчета регистрационного ключа, но вы можете добавить номер версии или другую дату. Затем создается ключ регистрации путем вычисления MD5-хэша предоставленного имени в сочетании с секретным кодом (несколько случайных байтов в массиве).
Это ни в коем случае не является доказательством или очень надежным, но это просто и было достаточно для нашего использования.
Ну вот некоторые вещи, которые я могу придумать
- Поместите логическую бомбу, которая зависит от того, кто из ваших людей вошел в систему, чтобы через определенное количество дней после последнего входа в систему приложение закрылось.
- Использование блокировки на основе даты и сохранение даты в таблице на сервере SQL. Но зашифруйте значение, хранящееся в стандартном алгоритме, который использует соль, скрытую в вашем коде. Таким образом, вы избегаете показа даты системному администратору.
- Используя описанный выше метод, сохраните большое целочисленное значение, от которого вы будете вести обратный отсчет, как только приложение загрузится в IIS - как только оно достигнет нуля, удалите значение в БД и заблокируйте приложение - вам придется сбросить значение, используя для этого ваше шифрование снова работать
- Безопасность от неясности хороша, если это приложение, но если вы хотите продать его как продукт, вам понадобится какое-то шифрование.
Ни один из них не является надежным, хотя...
Отказ от ответственности: я не какой-либо юридический эксперт - я ответил на это только с технической точки зрения. Лично я бы не стал этого делать, так как считаю это морально неоднозначным.
Я действительно не вижу никаких сценариев, где это закончилось бы хорошо. Если вы беспокоитесь о том, что вам платят (а они, вероятно, беспокоятся о том, чтобы заплатить за приложение до того, как оно будет доставлено), как насчет настройки какого-либо условного депонирования? Они переводят платеж на условное депонирование с взаимосогласованными условиями выпуска денег, и вы затем продолжаете работать, зная, что деньги были отложены до тех пор, пока вы не закончите.
Если оставить в стороне этические проблемы, если вас беспокоит взлом вашей реализации серийного номера, почему бы не использовать сертификат X509? Если, например, у вас есть окно Windows с установленным сервером сертификатов, он может открыть список отзыва сертификатов в Интернете.
Выдайте каждому клиенту сертификат идентификации клиента (бонус, если вы предоставляете проверку обновлений центральному серверу - теперь вы можете использовать HTTPS клиент / сервер, не беспокоясь о паролях).
Если клиент не платит, отозвать сертификат. При запуске приложения просто загрузите сертификат и проверьте его действительность...
Есть ли у их веб-сервера доступ в интернет? Возможно, вы захотите использовать веб-сервис для запуска бомбы замедленного действия в дополнение к другим методам, так как хитрый системный администратор может захотеть установить часы на сервере несколько лет назад.
Если у клиента есть все части программного обеспечения, вы не можете полностью предотвратить это.
Единственный правильный способ - сделать приложение зависимым от какого-либо компонента, которым вы владеете, например, через некоторое время может потребоваться активация или проверка связи с вашим веб-сервером.
Этого можно достичь, взяв дату установки и используя ее как солевой / криптографический ключ и зашифровав с ней все данные. Затем вы можете сравнить с этой датой установки. Если клиент привинтит его (установив часы назад), вы заметите это, поскольку у вас есть первоначальная дата установки. Если они изменяют дату, это также изменит криптографический ключ, и, таким образом, данные больше не могут быть расшифрованы.
Существует еще способ обойти это, но с любым решением на основе времени вам как-то нужно сохранить дату установки в качестве базы для сравнения, и вы должны сделать это безопасным, так что идея использования в некотором виде шифрования чтобы защитить все данные с ним.
Пара моментов для рассмотрения:
Это даже законно? Предполагая, что вы не планируете раскрывать это пасхальное яйцо: "Если оно не сработает, клиент никогда не должен знать о существовании бомбы замедленного действия", у вас могут возникнуть некоторые юридические проблемы...
Если у клиента есть доступ к источнику, я не могу представить, как вы могли бы включить в него все, что он не мог нанять, чтобы удалить разработчик. Даже если айтишник не разработчик, он не может нанять другого разработчика для обратной разработки кода.
Наконец, плохая карма... Если вы действительно работаете с клиентом, которому, по вашему мнению, не доверяете, чтобы платить, то зачем вообще работать с ним? Я ожидаю, что вы захотите положить все на стол и получить от клиента полное обязательство перед выполнением работы. Если клиент отказывается от совершения платежа, я бы ходил..
Две мысли:
1) Я бы разместил приложение для них за пределами сайта, пока они не заплатят, или пока они не положат деньги на условное депонирование. Если они скажут, что это не работает и не будут платить, то они не будут возражать, если вы отключите доступ, пока соглашение не разобрано, не так ли?!
2) Мы делали подобное раньше. Мы потратили гораздо больше времени на обдумывание того, как любая возможная "бомба замедленного действия" будет на 100% пуленепробиваемой, чтобы она не могла взорваться случайно или до даты отключения, или в какое-то время случайно после того, как она была "слита". Например, может быть, лучше удалить код, а не просто поменять флаг с "Пробный" на "Неограниченное использование"
Это похоже на работу для адвоката.
Кроме того, я бы использовал простой файл конфигурации, который содержит дату истечения срока действия. Затем сохраните зашифрованный RSA хэш этой даты в файле конфигурации. Если вы обновляете дату истечения срока действия, то вы также просто обновляете зашифрованный хеш. Приложение регулярно читает дату, расшифровывает хеш с помощью открытого ключа RSA и затем проверяет хеш. Если они возятся с датой, зашифрованным хешем или открытым ключом, приложение перестает работать.
Не помещайте свое имя вокруг того, что вы делаете, и удаляйте все существующие комментарии, в которых есть ваше имя. Если это действительно разрешено, и ваше имя указано в программе, ваш начальник может легко бросить вас под автобус и сказать, что он не имеет к этому никакого отношения. Я серьезно пересмотрел бы на следующем направлении. Я знаю, что это решение руководства, но если вы делаете работу, которая может легко вернуться, чтобы укусить вас.
Я не юрист, но с моей точки зрения: если они утверждают, что программа не работает и она непригодна для использования, то позже они не смогут утверждать, что она "работает меньше", и возлагают на вас ответственность за ущерб, если они уже не внесли частичные платежи за то, что does work.
I would get their complaint in writing before you try any of the suggestions here. (I would add that the 'free trial' route seems safest)
Сознательно вводить такую "бомбу замедленного действия", безусловно, незаконно. Ваш босс не первый, кто обдумает это, и не будет последним. Лучше всего остановить производство до тех пор, пока не будет произведен платеж.
Возможно, вы захотите предупредить своего начальника о том, что если его клиент понесет какие-либо денежные убытки (включая потерю клиентов), ваша компания будет нести ответственность за эту потерю и, возможно, штрафы, а также судебные издержки вашей компании. И, если компания не переживет судебный процесс и урегулирование, вы останетесь без работы.
Я бы дважды подумал, прежде чем просто согласиться с этим на вашем месте.
Если вы хотите, чтобы дата была на самом сервере, а не в Интернете, кажется, единственной ставкой является безопасность через неизвестность. Это разумно - вы не хотите, чтобы приложение проверяло интернет каждый раз, когда оно запускается на определенную дату, и умирало при плохом интернет-соединении.
Самый простой способ - сохранить дату в самой сборке как переменную. Если вы боитесь простой декомпиляции, зашифруйте ее и сохраните ключ в сборке. Если вы думаете, что хотите изменить дату в будущем, сохраните ее в DB/web.config (зашифровано, конечно). Для шифрования вы можете использовать что угодно, от base64 до криптографии с открытым ключом. Очевидно, что это не помешает серьезной декомпиляции вашего кода... но это хорошо для начинающих.
С другой стороны, напоминает ли вам "логическая бомба" Рыба-меч?
Это довольно закулисно, но вы можете просто написать запланированное задание, которое выполняет программу, которая солит все пароли. Это не портит никаких данных, и, пока у вас есть доступ, вы можете отключить задачу расписания. Кроме того, если что-то случится, когда вы захотите вернуть им информацию, это будет так же просто, как не солить... обессолить... пароли.
Как и со многими другими, у меня были бы сомнения относительно фактической реализации этого.
Я не могу говорить с юридическими вопросами.
Технически я предполагал, что ты мог бы сделать это. Создайте пару ключей и используйте закрытый ключ для шифрования файла с датой истечения срока действия. Ваше приложение будет использовать открытый ключ для расшифровки файла с датой истечения срока действия. Каждый раз, когда программа запускается, на видном месте отображается что-то вроде "57 дней осталось до истечения срока действия лицензии. Yada, yada". Таким образом, они постоянно предупреждают, что приложение перестанет работать.
Что касается повреждения данных после истечения срока действия, я бы этого не сделал. Я думаю, что я бы зашифровал некоторые ключевые элементы в данных, которые требуют расшифровки приложения.
Трудно обойти системного администратора, который задержит время, хотя. Но если у него есть сетевое соединение, вы можете использовать его как "телефонный дом", чтобы получить ключ, и вообще не работать, если он не может его получить.
Как и многие другие здесь, я бы сказал, не делай этого. Я не знаю, является ли это незаконным, но это не кажется правильным. Бизнес должен основываться на доверии, а открытая дискуссия должна иметь приоритет над такими схемами.
Поговорите о своих проблемах и остановите разработку, если необходимо - я полагаю, что они все-таки хотят продукт!
Я бы реализовал какой-то метод в скомпилированном dll, который вы храните в каталоге bin. Назовите это как-то иначе, чем timebomb.dll,
Затем вы должны иметь метод в этой DLL, который возвращает истину или ложь:
public bool hasTimeExpired() {
//Pseudocode
DateTime expires = new DateTime(Janurary 10, 2009);
return ( DateTime.Now() >= expires );
}
Просто проверьте метод hasTimeExpired() при запуске приложения (global.ascx??) или на определенных кодовых страницах, в зависимости от того, как вы хотите обработать сообщение об истечении срока действия.
DLL в каталоге bin будет легко заменить новой скомпилированной версией, когда вы захотите отключить бомбу замедленного действия или продлить время. Его нужно декомпилировать, чтобы выяснить дату истечения срока действия, и его будет легко обойти, если они узнают, как это работает, но, как вы сказали, рассматриваемый администратор, вероятно, не сделает этого.
Кроме этого, вам действительно нужно работать с юристом, но иногда блокировка на заемном программном обеспечении, подобном этому, более эффективна и дешевле, чем юрист.
Переместите некоторую логику в веб-сервис на ваших собственных серверах. Пусть приложение клиента будет зависеть от этого веб-сервиса. У вас есть веская причина, чтобы переместить эту логику, например: "Это наша основная деятельность, поэтому нам нужно это контролировать", внести это изменение как часть "новой версии" программы.
Обновите договор с клиентом, добавив новый раздел, в котором говорится, что если он не оплатит, ваш веб-сервис будет отключен.
Если они не хотят подписывать контракт, они не хотят иметь с вами дело, и вы можете отключить для них веб-сервис, если они подпишут, они согласятся на новые условия.
Это действительно единственный способ сделать это, если вы хотите быть уверены, что они не смогут его использовать, если не заплатили. В противном случае вы должны передать на них иск или подобные угрозы.
Технические проблемы решаются программистами, бизнес-проблемы - юристами. Ваш босс должен использовать правильный инструмент для работы.
Сделайте маршрут Антивируса, сделайте внешний звонок для "Обновлений". Если вы не получаете обновления, приложение перестает работать, если они не платят, прекратите давать им обновления.
Я думаю, что это неправильное решение проблемы, но я понимаю, что ваша задача - делать то, что вам говорят.