P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"
Vieleicht "Es"? SCNR
Das ist korrekt. Ich bin eine Transe, aber lass mich doch gerne mit "sie"/Frau anreden. Doch relevant ist das nicht gerade hier.
Ich bin nur eine Person, manchmal zwiespältig, also vielleicht doch mehrere? lol.
Zu deiner Frage:
Ein Service, der u.U Werte in Mio. Höhe vorhält, sollte so konstruiert sein, daß
selbst ein unauthorisierter Shell Zugriff keinerlei Coin-Entwendung ermöglicht
sondern maximal eine Störung verursachen kann.
Ja ein zweites inputs.io sollte nicht passieren
Interpreter können das Aufgrund des direkt sichbaren Scriptquellen nicht leisten.
(...)
Simples Beispiel (PHP/MySQL):
Sobald Shell Zugang existiert (muss noch nicht mal root sein), reichen ein paar
Greps aus, alle DB Connectoren aus den Confs oder direkt aus den Sourcen auszulesen.
(...) ist deine Schwachstelle IMMER dein Script, da offen, tracebar und unter Kommunikationszwang zur DB.
Die Dateien mit Zugangsdaten als auch die Scripte könnte man verschlüsseln und das zugehörige Passphrase auf mehrere Dateien (teilweise ebenso verschlüsselt) verteilen bzw. so dass ein Angreifer dies nicht ohne großen Aufwand heraus findet.
Um das zu verhindern lohnt es sich Old-School Kompilierte CGI's einzusetzen.
Beispiel (C/NoSQL-Lib oder pure libmysql, falls SQL Syntax sein muss):
Als DB-Backend kommt eine Low-Level NoSQL-Lib in Frage, idealerweise ohne TCP Stack
(Min. Latenz), falls TCP zwingend erforderlich ist kommt eine C-Lib in Frage, die Request
aus den ebenfalls kompilierten CGI's abarbeitet. ALLE Zugangsdaten und Cluster-Adressen
sind in der Lib statisch einkompiliert. DB-Verschlüsselung erfolgt durch die Lib NICHT
File- Bzw. OS Basiert, sondern per DATENSATZ. Passt sehr gut zu dem Dokumentenorientierten
Ansatz der DB. Was findet ein Angreifer mit Shell-Zugriff jetzt vor?
Simpel gesagt 3 Dateien. Eine DAT (DB) eine LIB (DB-Cluster-Connector) und eine EXE (CGI).
Selbst mit den derzeit besten Decompilern ist da wenig - innerhab des Zeitfensters -
zu machen. Der Angreifer kann weder auf die DB Zugreifen bzw. Auslesen, noch brauchbare
Rückschlüsse auf die Ablauflogik oder Cluster-Topologie ableiten um weitere Schwachstellen
oder gar das Cold-Wallet im Cluster zu Identifizieren.
Ja gut. Hm. Dafür bräuchte man eine etwas andere Art von Programmierer als einfach fürs Web.
Wäre allerdings schon weitaus solider als Interpreter.. wenn sich genug Mitwirkende dazu finden, würde ich das durchaus vorziehen. Zumindest für die sicherheitsrelevanten Teile.
Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.
(...)
Du kannst es Drehen wie du willst und Layer über Layer einsetzen um die gefühlte Sicherheit
zu verbessern aber sobald die den Trigger auslösende Schnittstelle (hier Das Web) offen ist
(Scripts) hast du mit allen nachfolgenden Sicherheitsmaßnahmen zwangsläufig verloren.
Ist doch auch klar, wenn der Auszahlauslöser im Web logischerweise bis auf deinen TAS einwirken
muss um eine Auszahlung zu veranlassen. Wenn diese Auszahllogik offen liegt, ist das System Kaputt,
egal wieviel hinten dranhängt.
Und genau darum gehts, diese Logik als offenes Script auf dem Server zu *Lagern* ist das Problem.
Ja moment.. Man kann doch von Webserver zu Server 1 eine Auszahlungsanweisung samt Bitcoin Adresse schicken usw. - Dann leitet Server 1 diese Anweisung an Server 2 weiter - hier hat es mit dem Webserver nichts mehr zu tun also steht auch in keinem Script auf dem Webserver irgendwelche Logik dazu. Und so weiter.
