Sollte ich meinen Anwendungen eine Selbstzerstörungsmethode hinzufügen?

Ich hatte kürzlich eine negative Erfahrung, bei der der Kunde von der Rechnung befreit wurde, aber mein Mittelsmann hat bereits unsere Software und unser Design auf den Client-Server hochgeladen. Client stellte sich als bekannter Krimineller heraus und änderte natürlich alle möglichen Passwörter des Servers.

Ich kann jedoch weiterhin auf das Admin-Panel des CMS zugreifen. Leider stellt sich heraus, dass meine Software sehr sicher ist. Ich habe versucht, SQL-Injection durchzuführen, den Image-Upload zu fälschen usw. Ich kann jedoch keine eigene Software hacken. Wie auch immer, ich bereite mich darauf vor, diese Person zu verklagen, das ist es nicht das problem .. ich denke gerade, dass es vielleicht eine selbstzerstörungsmethode im backend geben sollte. Wenn ein ähnlicher Fall eintritt, habe ich die Option , die Software zu beenden .

Meine eigene Idee ist es, einige Funktionen in den Kerndateien zu verstecken. Codiere es mit base64, es wäre also nicht offensichtlich. So etwas in der Art:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

Und im Grunde genommen machen Sie ein kleines Skript, das alle Dateien der Software nimmt, sie sicherheitshalber chmods und sie dann löscht.
In meinen neueren Versionen des CMS gibt es alle Dateimanager, die ich zum leichteren Hacken verwenden könnte . Was aber, wenn der Zugriff auf das Admin-Panel eingeschränkt ist?

Um ganz klar zu sein , dies ist nur für die Software in der Entwicklungsphase gedacht, auf meinem persönlichen Server oder dem Client-Server (letzter Teil ist ethisch bedenklich). Also, wenn mein Client meine Software stehlen sollte. Dies wird nicht in einer Werbung enthalten sein -Software. Um
es noch deutlicher zu machen , wir sprechen über diese seltenen freiberuflichen Jobs. Ich finde es ziemlich logisch, dass Auftragsarbeiten solche Methoden nicht benötigen. Es handelt sich also nur im Entwicklungsmodus um diese Jumprisk-Clients. Wenn das Projekt fertig ist, wäre dies offensichtlich eine sehr, sehr unethische Hintertür , die in Ihrer Software enthalten sein könnte.

1. Ethisch ist das eine gute Idee? (Denken Sie daran, dass ich es natürlich entfernen werde, wenn das Projekt zu 100% abgeschlossen und alles bezahlt ist.)
2. Musstet ihr jemals eure eigene Software hacken , wegen ähnlicher Probleme mit den Clients?
3. Irgendwelche Empfehlungen zu dieser Idee, Code und Methode?
4. Was können die möglichen Nachteile oder Auswirkungen von Selbstzerstörungsskripten sein?

Mein Fazit dazu

Ist ein bisschen traurig, dass alle Antworten auf die vertraglich vereinbarten Fälle gerichtet waren. Es war wirklich meine Schuld, dass ich es in meiner Frage nicht klarer formuliert habe. Ich dachte nur, dass es ziemlich klar ist, dass der Kill-Switch keinen Sinn hat, wenn Sie durch den Vertrag geschützt sind.
Wenn Sie jedoch eine Vertragsarbeit ausführen, sollte dies im Vertrag vermerkt sein - dies macht es auch innerhalb des Servers des Kunden legal. Kill-Switches in meinem persönlichen Server zu haben, ist jedoch wirklich eine Sache für niemanden (das wollte ich wirklich wissen.)

Ich habe beschlossen, das Kill-Switch-Skript für mein CMS zu erstellen. Hauptsächlich, weil es eine interessante Herausforderung zu sein scheint. Aber auch, dass ich dies für meine nicht vertraglich vereinbarten Arbeiten verwenden könnte, bei denen der Kunde ein Freund eines Freundes eines Freundes ist. Ich werde dies wahrscheinlich nicht auf dem Client-Server verwenden, aber für die Fälle, bei denen der Kunde oder einige Zwischenhändler haben Zugriff auf meinen Server. Und meine Software wird gestohlen oder "ohne mein Wissen verschoben", dann werde ich nicht bezahlt und sie kürzen den Zugriff auf die Software.

Ich habe hier eine Menge Themen durchgelesen, in denen empfohlen wird, eine Warnung zu senden und die Seite dann zu schließen. Nun, ich habe ein Problem darin gesehen, als ob ich es mit einer Person zu tun habe, die es einfach an eine andere Stelle kopiert (vielleicht umbenannt und verkauft) und mir mitteilt, dass es abgeschafft wurde. Außerdem würde ich die Site nicht "ausschalten", sondern löschen. Ich vermute jedoch, dass es immer noch illegal ist, auf meinen Client-Server zuzugreifen und ihn zu löschen. Oder greifen Sie zumindest über das Backend und nicht über FTP darauf zu. Dafür danke ich Ihnen allen, die geantwortet haben.

Ich bin kein Anwalt. Es hört sich so an, als ob Sie bereits eine haben, um Ihren Klienten zu verklagen. Während Sie ihn oder sie behalten, würde ich empfehlen, sich diesbezüglich beraten zu lassen.

Es gibt einige andere Fragen auf dieser Site, die sich mit "Kill Switches" und anderen Möglichkeiten zum Deaktivieren von Software befassen, für die der Entwickler keine Entschädigung erhalten hat. Es wird in der Regel als schlechte Idee angesehen, einfach eine "schlüsselfertige" Software einzubauen (wo Sie sie entwickeln und dann dem Kunden die vollen Rechte übertragen), ohne dass der Vertrag diese Möglichkeit vorgesehen hat.

Wenn in Ihrem Vertrag nicht ausdrücklich festgelegt ist, dass Sie die Software wegen Nichtzahlung deaktivieren können oder der Kunde bis zum vollständigen Zahlungseingang keine Rechte an der Software hat, können Sie keinen "Kill-Schalter" ohne diesen Schalter betätigen vertragswidrig sein. Ohne gegenteilige Worte ist "Besitz neun Zehntel des Gesetzes", also ist es seine Software, sobald er Besitz erlangt hat, und es zu zerstören, wäre vergleichbar mit der Dynamisierung eines neuen Bürogebäudes, das Sie für ihn gebaut hätten, wenn er es nicht getan hätte nicht dafür bezahlen.

Der zweite Punkt folgt; Jeder Vertrag, den Sie einem Kunden anbieten, sollte folgende Klausel enthalten: "Übertragung von geistigem Eigentum bei Vertragserfüllung" . Das bedeutet, dass er selbst dann, wenn Sie ihm eine Kopie der Software zur Verwendung gegeben haben, diese nicht besitzt, bis er Sie vollständig bezahlt hat. Dies WÜRDE Ihnen das Recht geben, seine oder eine Kopie der Software aus irgendeinem Grund zu deaktivieren, bis die vollständige Zahlung eingegangen ist, da dies immer noch Ihre Sache ist und Sie tun können, was Sie möchten. Jetzt hat er gegen den Vertrag verstoßen, und Sie haben es nicht getan. Daher ist es für Ihren Anwalt VIEL einfacher, den Fall vorzulegen, und währenddessen profitiert Ihr Mandant nicht von seinen unrechtmäßig erworbenen Waren.

Die Analogie zu einem Bauunternehmer lautet: Sobald ein im Bau befindliches Gebäude gegen unbefugtes Betreten gesichert werden kann, ist dies der Fall, und der Bauunternehmer wird im Allgemeinen alle Kopien aller Schlüssel des Betriebsgeländes aufbewahren, bis die Arbeiten abgeschlossen und abgemeldet sind Zahlung in voller Höhe erhalten. Auch nach der Schlüsselübergabe kann er bei Zahlungsausfall ein Pfandrecht an der Immobilie hinterlegen und diese im Extremfall zurückerhalten lassen. Das gleiche gilt hier; Sie können dem Client einen Schlüssel geben, um in die Software zu gelangen, aber Sie halten den "Hauptschlüssel" und er erhält keinen Administratorzugriff, bis Sie vollständig bezahlt sind. Wenn er jetzt einsteigen kann und Sie nicht bezahlt, können Sie einfach die Sperren ändern und ihn aus der Software ausschließen.

Sie haben Ihrem Client jedoch den "Hauptschlüssel" für die Software gegeben, und er hat alle Sperren geändert, sodass Sie jetzt nicht mehr einsteigen können. So sollte es nicht funktionieren. Sie können immer noch Schadensersatz verlangen, aber in der Zwischenzeit kann Ihr krummer Kunde die Software verwenden, sie an eine andere Stelle kopieren (das ist eine große Sache, die einem Bauunternehmer nicht passieren kann. Wenn er sein Gebäude zurücknimmt, muss er sich keine Sorgen um Sie machen Habe eine exakte kostenlose Kopie auf einem anderen Los angefertigt usw. Grundsätzlich besteht Ihre einzige Abhilfe darin, die Zahlung vollständig durchzusetzen, da Sie nicht garantieren können, dass Sie alle Kopien der Software zurückgefordert haben. Sie würden sich wahrscheinlich nicht freuen, Ihre Software zurückzubekommen, selbst wenn Sie garantieren könnten, dass er keine weiteren Kopien hat. Es ist wahrscheinlich eine Maßarbeit, die man nicht einfach umdrehen und an jemand anderen verkaufen kann.

Verstehen Sie, dass unabhängig von Ihren Rechten an der Software seine Daten ihm gehören. Sie können es nicht berühren. Sie können seinen Zugriff auf die Software, die Sie erstellt haben, beenden. Wenn Sie jedoch seine Daten zerstören, ist dies, als würden Sie seine Besitztümer verbrennen, nachdem Sie das Gebäude, für das er nicht bezahlt hat, wiederhergestellt haben. Sie haben keinerlei Anspruch auf diese Daten und müssen diese entweder intakt auf seinem Computer belassen oder, wenn auf die Daten ohne Ihre Software nicht in angemessener Weise zugegriffen werden kann, sie aus der Verstrickung mit Ihrer Software entfernen und an weitergeben ihn in einem verwendbaren Format (z. B. eine von Menschen konsumierbare Datenbank oder gedruckte oder elektronische Kopien).

Im Konzept hast du recht. Ihre Hinrichtung ist alles falsch.

Sie müssen ihm Testlizenzen bereitstellen, die ablaufen. Bei vollständiger Bezahlung erhält er die Final "forever" Lizenz. Alles offen und ehrlich.

Wenn Ihre Kunden es herausfinden würden, würden Sie gelyncht. Es ist überhaupt nicht sicher. Jemand wird herausfinden, wie man es auslöst, und dann haben Sie plötzlich die Aufgabe, alle Ihre Kunden zu kontaktieren, um ihnen davon zu erzählen und warum sie einen Notfall-Patch durchführen müssen.

Wenn Sie es hacken, öffnen Sie sich auch für Strafverfahren. Ich gehe davon aus, dass Sie den Beweis haben, dass Sie die Website noch besitzen. Dass Sie das Recht haben, darauf zuzugreifen? Die Kosten für sein Geschäft könnten "astronomisch" sein

Es gibt akzeptable Alternativen. Fügen Sie der Site ein Wasserzeichen hinzu, damit auf jeder Seite eine Meldung angezeigt wird. Bei Bezahlung können Sie das Wasserzeichen entfernen.

Dies scheint eine phänomenal schlechte Idee zu sein, die Sie möglicherweise ins Gefängnis bringen könnte.

1. Das ist unethisch. Schlechtes Verhalten Ihres Kunden macht es nicht richtig für Sie, ihr System zu hacken.
2. Es ist illegal. Dies ist schon früher passiert , mit schlechten Ergebnissen für die beleidigenden Parteien.
3. Es hat keinen Sinn. Was würden Sie möglicherweise mit dieser Hintertür tun, die Sie nicht in Schwierigkeiten bringen würde? Würden Sie den Kunden erpressen?
4. Es ist dumm. Selbst wenn Sie dies tun könnten, ohne erwischt zu werden, überwiegen die potenziellen Risiken den möglichen Gewinn bei weitem.

Bitte fragen Sie keine Programmierer, fragen Sie einen Anwalt. Ich würde mir zumindest vorstellen, dass Sie eine Klausel in Ihren Vertrag aufnehmen möchten, die besagt, dass Sie das Recht haben, das zu tun, was Ihre Frage vorsieht. (Erlaubt Ihnen die "irreparable Schädigung" - Klausel einiger Verträge nicht, die Software sofort außer Betrieb zu setzen, bis das Gericht die Möglichkeit hat, die Angelegenheit zu klären?) Ich denke, eine gerichtliche Verfügung wäre für Sie viel sicherer als eine Codebombe (die als kriminell eingestuft werden kann, wenn ein Gericht feststellt, dass Sie die Software nicht besitzen, kann dies zur Zerstörung von Eigentum führen. In den USA fällt sie möglicherweise unter die Bestimmungen für die digitale Verschlüsselung des Digital Millennium Act usw. Ich könnte Stellen Sie sich vor, Sie würden vor einem Zivilgericht Schadenersatz gewinnen und immer noch vor einem Strafgericht verurteilt.

Die Regeln variieren je nachdem, wo Sie und Ihr Mandant leben und arbeiten. Ich glaube, Sie möchten einen Anwalt.

Ethisch ist das eine gute Idee?

Absolut nicht. Dies lässt Sie nicht nur unprofessionell für ehrliche, hochstehende Kunden aussehen, sondern schadet meiner Meinung nach auch dem gesamten Berufsstand. Software-Ingenieure haben eine Verantwortung gegenüber ihren Kunden oder Arbeitgebern, einschließlich der Lieferung von Software von höchster Qualität. Sollte es zu Streitigkeiten über Zahlungen oder Verträge kommen, gibt es entsprechende Kanäle. Die Qualität Ihrer Software zu reduzieren, ist kein angemessener Kanal.

Musstet ihr jemals eure eigene Software hacken, wegen ähnlicher Probleme mit den Clients?

Niemals, obwohl ich noch nie als Vertragspartner oder Freiberufler gearbeitet habe. Ich war immer Angestellter einer größeren Organisation (die in einigen Fällen unter einem Vertrag arbeitete). Für mich ist der Gedanke undenkbar. Ich möchte lieber Software liefern, auf die ich stolz bin, wenn mein Name einem kleinen Prozentsatz von Kunden zugeschrieben und von diesen betrogen wird, als die Qualität meiner Software und meine ethischen Verantwortlichkeiten gegenüber den Benutzern des Systems zu verringern.

Irgendwelche Empfehlungen zu dieser Idee, Code und Methode?

Tu es nicht.

Was können die möglichen Nachteile oder Auswirkungen von Selbstzerstörungsskripten sein?

Abgesehen von den offensichtlichen ethischen Problemen würde ich mir Sorgen um rechtliche Probleme machen. Ich bin nicht sicher, ob es legal ist, Ihre eigene Arbeit zu sabotieren, und selbst wenn dies der Fall ist, kann es sein, dass ein solcher Exploit nicht verwendet wird.

Implementieren Sie einfach ein Lizenzierungsmodul mit zeitlich begrenzten Lizenzen, mit dem die Software nach Ablauf deaktiviert wird. Dies ist eine in der Softwareindustrie bekannte Praxis, und Ihre Kunden sollten nichts dagegen haben, da Sie die Einschränkung anschließend aufheben werden.

Dies kann auch nützlich sein, wenn Sie die Funktionen einschränken und verschiedene Versionen Ihres Produkts anbieten möchten.

Kill Switches haben einfach viel zu viele Risiken und sind es nicht wert.

Eine geheime Selbstzerstörung ist eine schreckliche Idee. Ja, Sie werden klug sein und vielleicht die Gelegenheit haben, es in Zukunft einem schrecklichen Kunden zu zeigen, aber es ist mehr Mühe als Mühe wert.

1. Sie werden immer noch nicht für Ihre geleistete Arbeit bezahlt. Ja, die andere Person wird Ihren Code nicht verwenden. aber Sie werden immer noch Zahlungsmangel leiden. Sie denken, ein Krimineller wird sich dafür entscheiden, die Person, die ihre Website bereits heruntergefahren hat, einmal per Fernzugriff zu bezahlen? Sie werden einen neuen Trottel finden, um ihre Seite kostenlos zu machen.

2. Durch die Verwendung der Selbstzerstörungssequenz haften Sie für Ihre eigenen rechtlichen Probleme. Abhängig von der Rechtsprechung können Sie leicht als Hacker / Zerstörer ihrer Daten angesehen werden (wenn sie im Begriff waren zu zahlen und viele mildernde Umstände hatten, warum sie nicht früher gezahlt haben). Selbst wenn Sie nicht verurteilt / erfolgreich verklagt werden, können Sie immer noch hohe Anwaltskosten erheben und mehr Ärger haben, als es wert ist.

3. Was passiert, wenn ein gut bezahlter Client Ihren Code später durchsucht (oder einen CS-Freund hat, der ihn nur durchsucht hat, um kleinere Änderungen vorzunehmen), die Funktion mit dem seltsamen base64-Teil sieht, wie folgt aussieht, versucht, sie auszuführen und versehentlich die Web-App löscht (und dauert es, während Sie im Urlaub sind, so dass es eine Weile dauert, um zu beheben)? Oder posten Sie überall eine Reihe von öffentlichen Bewertungen über Sie, die besagen, dass Sie unethisch sind und Hintertüren in Ihrer Arbeit hinterlassen? Sicher können Sie es vom fertigen Produkt entfernen, nachdem sie bezahlt haben, aber mit VCS durchsuchen sie möglicherweise ältere Quellen oder möchten Sie nicht auf ihrem Server, nachdem sie bezahlt haben (und das wäre eine umständliche Unterhaltung; ja, ich brauche wieder einen Account, weil ich einen Port habe die geheime selbstzerstörende Hintertür nicht entfernt).

4. Was ist, wenn der Kriminelle seine Daten sichert? Sie löschen ihren Webserver mit einer geheimen Hintertür, die Site ist für ein oder zwei Tage offline, während sie (oder ein Freund) die beleidigende Funktion der Hintertür und ihre Rückseite online findet.

Lassen Sie sich in Zukunft von Mitarbeitern dazu bringen, einen einfachen Vertrag zu unterzeichnen, Sie schrittweise zu bezahlen, und lassen Sie den Code erst dann vom Entwicklungsserver und vom Computer, den nur Sie steuern, ab, wenn Sie bezahlt haben. (Wenn sie es brauchen, um live zu sein, bevor die ganze Arbeit beendet ist; stellen Sie sicher, dass sie ungefähr für den Bruchteil des Codes bezahlt haben, der live wird). Wenn sie die Arbeit als in der Entwicklung befindlich ansehen möchten, geben sie Ihnen einige IP-Adressen, mit denen Sie Ihre Firewall für Ihren Entwicklungsserver öffnen (und möglicherweise mit einem cleveren CNAME, um dies zu bewirken)unpaid_work_in_development.example.com). Geben Sie keine Garantie für die Verfügbarkeit Ihres Entwicklerservers und schließen Sie die Firewall einfach, bis sie bezahlt ist, wenn Sie mehr Verkehr haben, als Sie sollten (z. B. wenn Sie feststellen, dass viele Leute auf Ihre Site weitergeleitet werden). Wenn sie Inhalte zu Ihrem Webserver beitragen müssen, senden Sie ihnen entweder eine E-Mail mit den Inhaltsvorschlägen oder erstellen Sie einen freigegebenen Dropbox-Ordner für sie, der nur die Berechtigung zum Schreiben in die kleine Teilmenge der Dateien (unter VCS-Kontrolle außerhalb von Dropbox) hat kann sinnvoll dazu beitragen (zB HTML-Vorlagen).

Sie haben die falsche Frage gestellt. Die Sache, an der man arbeiten und die man verbessern muss, ist nicht, eine Art Remote-Kill-Schalter hinzuzufügen (der eine Sicherheitslücke hinzufügt, die Sie oder eine andere Person ausnutzen können), sondern das eigentliche Problem zu beheben, das eine schlechte Art war, Zahlung und Lieferung zu arrangieren. Klingt so, als ob Sie ein besseres Treuhandsystem benötigen (oder wie auch immer ein solches Konzept heißt, wo Sie leben).

Verschwenden Sie Ihre Zeit nicht mit einem Kill-Switch, sondern finden Sie heraus, wo Sie den Teil des Geschäftes vermasselt haben.

Ich denke, ich würde eine Art Lizenzierungsmechanismus entwickeln. Dies kann auf einer beliebigen Anzahl von kommerziellen oder hausgemachten Ideen beruhen und dazu führen, dass die Software nach Ablauf der Lizenz nicht mehr funktioniert. Sobald das System vom Kunden akzeptiert und bezahlt wurde, können Sie eine vollständige Lizenz bereitstellen, die nicht abläuft.

Dieser Ansatz muss ebenfalls von einem Anwalt in Ihrem Gebiet genehmigt werden, hat jedoch den Vorteil, dass Sie die Software nicht per Fernzugriff deaktivieren müssen und festlegen können, dass dies Teil des Systems ist. Es scheint mir jedoch sehr traurig, dass Sie es mit Menschen zu tun haben, die sich weigern, überhaupt zu zahlen.

Heißt das nicht DRM? Solange Sie die "Bombe" nach Zahlungseingang entfernen, sehe ich kein rechtliches Problem damit. Stellen Sie einfach sicher, dass Sie einen Patch zur Verfügung haben, der Ihren Arsch bedeckt, und zeigen Sie, dass Sie keine böswillige Absicht hatten.

Es erinnert mich an die „Giftpillen“ -Vorschrift in den Satzungen einiger Unternehmen, die im Falle einer feindlichen Übernahme aktiviert werden.

Die Mentalität, die einige der anderen Plakate hier zum Ausdruck bringen, erinnert mich daran, warum manche Programmierer ständig darauf treten. Wenn mehr Leute solche Bomben in ihren Code einfügen, werden Programmierer wahrscheinlich schneller bezahlt ... Ich hätte absolut kein Problem, wenn dies die Norm wäre. Die Leute lieben es, die harte Arbeit anderer Leute zu stehlen. Zeitraum. Und wenn Apple et al. kann DRM die Hölle raus aus ihren Sachen, dann denke ich, können auch freiberufliche Programmierer ...

In der Praxis würde der Client sicherlich seine Protokolle überprüfen, die Kill-Anforderung finden, den Code aus einer Sicherung wiederherstellen, den Kill-Schalter entfernen und erneut implementieren.

Die Details Ihrer Frage machen deutlich, dass dies eine absolut schreckliche Idee wäre. Der erste Client, der einen solchen Kill-Schalter entdeckt (möglicherweise nachdem Sie ihn verwendet haben und er sich von einem Backup erholt hat), veröffentlicht den Kill-Schalter und die Tatsache, dass Sie ihn in den Code aufgenommen haben, den Sie an ihn gesendet haben. Ihr Ruf wäre dann völlig zerstört.

Und bevor du sagst "Nun, sie wären ein tödlicher Schlag, wie werden sie meinen Ruf zerstören?" Stellen Sie sich ein Szenario wie das folgende vor: Der Kunde ist in gutem Zustand, aber einer seiner Mitarbeiter nimmt eine Kopie des Codes. Sie feuern diesen Mitarbeiter, er sieht sich den Code an, findet den Kill-Schalter heraus und benutzt ihn. Ratet mal, wer die Schuld bekommt? (Hinweis: Du bist es.)