Необходима бомба замедленного действия в приложении ASP.NET - PullRequest
17 голосов
/ 19 февраля 2009

Мы разработали специальное приложение ASP.NET для использования в интрасети нашего клиента. Похоже, они вряд ли заплатят за это, поэтому наш босс хотел бы, чтобы мы ввели бомбу замедленного действия.

[Редактировать:] Только технические ответы, пожалуйста! Является ли это хорошей (или юридической) идеей - вопрос для CEOoverflow.com ; -)

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

Мой вопрос: как и где мы должны хранить дату истечения срока действия заявки?

Некоторые моменты, на которые следует обратить внимание:

  • Приложение установлено на одном сервере в офисах клиента.
  • Данные приложения хранятся в базе данных SQL Server 2005 на том же сервере. База данных была разработана нами и не используется ни для чего другого.
  • Приложение доступно только в их внутренней сети: нет доступа к приложению через Интернет.
  • В настоящее время у нас есть удаленный доступ к рабочему столу на их сервере, но мы ожидаем, что потеряем его, если что-то пойдет не так.
  • Приложение написано на .NET 2.0.
  • Безопасность обрабатывается с помощью FormsAuthentication.
  • Нам нужно иметь возможность отключить бомбу замедленного действия или легко изменить дату ее запуска (предположим, что для этого у нас все еще есть доступ к удаленному рабочему столу).
  • Сервер обычно может получить доступ к Интернету, но было бы лучше не полагаться на это.
  • Бомба замедленного действия блокирует только пользователей: она не уничтожает никакие данные.
  • Если это не сработает, клиент никогда не должен знать о существовании бомбы замедленного действия.
  • Их айтишник с удовольствием покопается в web.config или в базе данных. Он не программист, но он не боится что-то менять «просто чтобы посмотреть, что происходит». Декомпиляция или обратный инжиниринг приложения будут за пределами его возможностей.

За дополнительные кредиты, как вы думаете, насколько это нормально, если в этом случае можно положиться на безопасность через неизвестность?

[ Edit: ]

  • Приложение выполняет много важных для бизнеса задач, связанных с датами, поэтому мы можем быть уверены, что они не изменят время на своем сервере, поскольку это сделает приложение хуже, чем бесполезным.

Ответы [ 23 ]

4 голосов
/ 19 февраля 2009

Две мысли:

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

2) Мы уже делали подобное раньше. Мы потратили гораздо больше времени на обдумывание того, как любая возможная «бомба замедленного действия» будет на 100% пуленепробиваемой, чтобы она не могла сработать случайно ни до даты отсечения, ни в какое-то время случайно после того, как была «снята». Например, может быть лучше удалить код, а не просто поменять флаг с «Пробный» на «Неограниченное использование»

3 голосов
/ 19 февраля 2009

Я не юрист, но вот моя точка зрения: Если они утверждают, что программа не работает и она непригодна для использования, то позднее они не смогут утверждать, что она «работает меньше» и будут считать вас ответственными за ущерб, если они уже не внесли частичные платежи за то, что работает.

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

3 голосов
/ 19 февраля 2009

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

2 голосов
/ 19 февраля 2009

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

Я бы дважды подумал, прежде чем просто согласиться с этим на вашем месте.

2 голосов
/ 19 февраля 2009

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

Самый простой способ - сохранить дату в самой сборке как переменную. Если вы боитесь простой декомпиляции, зашифруйте ее и сохраните ключ в сборке. Если вы думаете, что хотите изменить дату в будущем, сохраните ее в DB / web.config (зашифровано, конечно). Для шифрования вы можете использовать что угодно, от base64 до криптографии с открытым ключом. Очевидно, что это не помешает серьезной декомпиляции вашего кода ... но это полезно для начинающих.

Кстати, «логическая бомба» также напоминает вам рыбу-меч?

2 голосов
/ 19 февраля 2009

Сознательно вводить такую ​​«бомбу замедленного действия», безусловно, незаконно. Ваш босс не первый, кто обдумает это, и не будет последним. Лучше всего остановить производство до тех пор, пока не будет произведен платеж.

1 голос
/ 19 февраля 2009

Я не могу говорить по юридическим вопросам.

Технически, я предполагал, что ты мог бы сделать это. Создайте пару ключей и используйте закрытый ключ для шифрования файла с датой истечения срока действия. Ваше приложение будет использовать открытый ключ для расшифровки файла с датой истечения срока действия. Каждый раз, когда программа запускается, на видном месте отображается что-то вроде «57 дней осталось до истечения срока действия лицензии. Yada, yada». Таким образом, у них есть постоянное предупреждение о том, что приложение перестанет работать.

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

Трудно обойтись сисадмином, который задержит время. Но если у него есть сетевое соединение, вы можете использовать его как «телефонный дом», чтобы получить ключ, и вообще не работать, если он не может его получить.

1 голос
/ 19 февраля 2009

Я бы реализовал какой-то метод в скомпилированной dll, которую вы храните в каталоге bin. Назовите это как-то иначе, чем timebomb.dll.

В этом dll должен быть метод, который возвращает true или false:

public bool hasTimeExpired() {
  //Pseudocode
  DateTime expires = new DateTime(Janurary 10, 2009);
  return ( DateTime.Now() >= expires );
}

Просто проверьте метод hasTimeExpired () при запуске приложения (global.ascx ??) или на определенных кодовых страницах, в зависимости от того, как вы хотите обработать сообщение об истечении срока действия.

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

Кроме этого, вам действительно нужно работать с юристом, но иногда блокировка на заемном программном обеспечении, подобном этому, более эффективна и дешевле, чем юрист.

1 голос
/ 19 февраля 2009

Это довольно закулисно, но вы можете просто написать запланированное задание, которое выполняет программу, которая объединяет все пароли. Он не разрушает никакие данные, и, пока у вас есть доступ, вы можете отключить задачу расписания. Кроме того, если что-то случится, когда вы захотите вернуть им информацию, это будет так же просто, как не солить ... обессолить ... пароли.

Как и многие другие, у меня были бы сомнения относительно фактической реализации этого.

1 голос
/ 19 февраля 2009

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

Поговорите о своих проблемах и остановите разработку, если необходимо - я полагаю, что они все-таки хотят продукт!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...