Manchmal möchte man aus einem Tomcat heraus Processe und Programme aufrufen. Wie bei SQL-Injections muss man das natürlich stark absichern, aber das Konvertieren von Bildern und Video geschieht meistens auf diese Art und Weise.
Was aber wenn der Tomcat per ProcessBuilder nichts mehr aufrufen kann außerhalb seines Verzeichnisses, obwohl er alle Recht haben sollte? Wenn es ein System mit systemd ist (z.B. ein Ubuntu) ist, kann es einfach eine Security-Einstellung sein, die den Aufruf verhindert.
Hier muss man die Start-Config für den Service anpassen. "ProtectSystem=false" ist zum Prüfen der Lösung ganz gut, sollte aber später durch eine genauere Anpassung der ReadWritePaths geöst werden.
Ich hab mal ein M12/S-Mount Fisheye-Objektiv ausprobiert. Nun kann ich in der gesamten Küche überwachen, ob der Hund Unsinn anstellt. Das Objektiv hat so 7 Euro gekostet und liefert eine ganz gute Qualität an der einfachen 720p IP-Kamera.
Nach den Weihnachtstagen frage ich mich immer, warum viele Menschen so viel gegen Sicherheit haben? Auf der einen Seite halten sie schon das Lastschriftverfahren für zu unsicher, als dass man es verwenden könnte (man kann Amazon ja nicht trauen...) und Homebanking wird in deren Vorstellungen ja auch dauernd gehackt, ohne dass der Benutzer was dafür kann. Das ganze Internet gilt als unsicher und gefährlich. Am liebsten würden sie es gar nicht nutzen... das einzige was diese Menschen noch viel weniger nutzen möchten und als noch viel schlimmer als das Internet ansehen sind Sicherheitsmaßnahmen.
Ich habe früher gelernt, dass man auf Geld, Schlüssel und Ausweispapiere gut aufpassen soll. Wenn du deinen Schlüssel verlierst, sollte man das Schloss auswechseln, weil es könnte sein, dass jemand herausfindet zu welchen Haus der Schlüssel gehört und dort einbricht. Das hab von den selben Menschen gelernt, die
einen doof angucken, wenn man denen erzählt, dass es nicht gut ist PIN und Karte zusammen in der Brieftasche aufzubewahren. "Ich merk mir doch nicht noch einen PIN" (also einen zweiten... bei zwei Karten) kommt dann als Antwort. Dass man damit sich und sein Geld schützt, ist oft nicht wirklich rüber zu bringen. PINs sind eine Gängelung des Kunden durch die Banken. Er wird nur gesehen, dass die Banken einen zwingen einen PIN auswendig zu lernen. Der Sinn und Zweck dahinter wird oft nicht mal versucht zu erfassen. Wobei momentan EC-Karten bei vielen sowie so als absolut unsicher gelten, seit man damit kontaktlos bezahlen kann. Da muss ja nur jemand in der Nähe sein und schon ist das eigene Bankkonto leer geräumt. Also auf jeden Fall solche Schutzhüllen für die Karten kaufen. Auch für alte Karten, die gar kein NFC/RFID können, weil man kann sich nicht sicher sein, dass nicht doch jemand es mit so einem Lesegerät hinbekommt, das Konto leer zu räumen. Kontaktloses Bezahlen ist also kein extra implementiertes Feature sondern eine Sicherheitslücke die in einigen Karten vorkommt (und man kann sich nicht sicher sein ob man betroffen ist).
Aber eines der schlimmsten Dinge, die in den letzten Monaten passiert ist und viele Menschen wirklich extrem geschockt hat und den Glauben an die Sicherheit der Banking-System hat verlieren lassen, war PSD2. Viele trauen sich nicht mehr Homebanking zu benutzen oder sind gar nicht mehr in der Lage dazu... weil eine zusätzliche Sicherheitsabfrage beim Login auftaucht. Wie schaltet man das ab? - Garnicht? Weil es gut ist, dass man eine 2-factor Auth auch beim Banking hat?
Allein die Abschaffung der TAN-Listen (ich war eher gesagt geschockt, dass einige Banken, die immer noch hatten) war hart. SMS-TAN ging irgendwie noch, auch wenn dem Handy (nicht Smartphone!) auch nicht wirklich getraut wurde. TANs die nicht festgeschrieben sind und geklaut werden können... denen kann man nicht trauen. Aber wenn dann noch SMS-TAN abgeschafft wird (weil SMS-Nachrichten eben nicht verschlüsselt sind) kommen viele an den Punkt, wo für die Homebanking absolut nicht mehr nutzbar wird. Foto-TAN oder noch viel schlimmer eine Smartphone-App mit Push-Benachrichtigung und Fingerabdruckscanner.
Da ist das Vertrauen dann ganz weg. Die Lösungen sind nicht komplizierter zu nutzen (teilweise sogar einfacher), ihnen wird nur nicht mehr getraut und deswegen werden sie nicht mehr benutzt. Je sicherer etwas wird, desto unverständlicher ist es für die meisten und desto größer auch die instinktive Ablehnung dagegen.
Die beste Lösung für viele war die einfache TAN-Liste. iTAN war schon etwas seltsam... weil vorher weiß die Bank (die die Liste gedruckt und mir zugeschickt hat) welche TAN hinter welcher Nummer auf MEINEM Zettel stehen?
Fazit: Desto sicherer ein System ist, desto mehr Menschen werden versuchen es zu meiden oder zu umgehen, weil viele Menschen unsicheren Systemen mehr vertrauen als sicheren Systemen.
Wenn man in seinem Plugin irgendein Template erweitert, dass mit der Darstellung von Produkten zu tun hat, sollte man immer daran denken, dass diese sehr sehr oft auch als Widgets verwendet werden.
Wenn man das Template-Dir nicht beim Laden von Widgets dem System Verfügbar macht, kann es zu unschönen Fehlern kommen und einen Hannes lange nach dem Problem suchen lassen.
directory 'xxxxxxxxx/y.tpl' not allowed by security setting
Hier ist das gesamte Konzept mit Caching und Templates wirklich toll mit Beispielen beschrieben:
Da steht auch, wenn das {s}-Tag als unbekannt angesehen wird.. dann ging einfach in Smarty echt was schief und man sollte mal die Apache-Logs angucken.
Eine Lösung wird auch gleich mitgeliefert (wobei ich momentan noch mit 2 Events.. Frontend und Widgets arbeite.. und auch erst einmal dabei bleiben werde):
ABER Vorsicht: Im Backend gibt es kein Shop-Object. Wenn man beim Hinzufügen des Template-Dirs auch Smarty-Vars setzt und auf Customer- und Session-Daten zugreifen will, kann es schnell schief gehen! Bei Frontend und Widgets gibt es keine Unterschiede.
Nach einigen Versuchen mit einem billigen China NAS (langsam und laut), der NAS-Funktion der Fritzbox (die plötzlich die externe SSD nicht mehr erkannte) bin ich nun bei einer gebrauchten QNAP TS-120 gelandet. Eine der Hauptaufgaben des NAS sollte es ja sein Bilder und Videos einer oder mehrere Überwachungskameras zu speichern. Zusätzlich sollte es auch für andere Dinge dienen, wie Datenaustausch zwischen den PCs und so.
Die TS-120 kann viele Dinge der größeren und neueren NAS nicht. So kann sie weder als VM-Host dienen noch als Domain-Controller in Windows-Netzwerken eingesetzt werden (was schön gewesen wäre). Aber trotzdem ist sie den anderen Lösungen, die ich hatte, weit überlegen.
Die Einrichtung der IP-Kamera ging auch entsprechend einfach. Sie speichert über FTP und man kann über SMB dann auf die Daten zugreifen.
Jetzt mit dem Haus reicht es nicht mehr nur die Wohnungstür zu zuschliessen. Da viele Einbrüche über Garten und Terrassentür geschehen soll der Garten überwacht werden. Die Tür ist sicher und ein motorisierter Rollladen sichert nochmals ab. Also geht es mehr darum mögliche Einbruchsversuche zu dokumentieren.
Es ist ein ieGeek 720p IPCam für außen und mit LAN + WLAN. SD-Karte ist wohl auch möglich, ich will aber lieber FTP verwenden.
NAS mit FTP-Server kommt dann als nächstes und dann wird die Kamera installiert und kann benutzt werden. Die Bildqualität (720p) gefällt mir aber schon sehr gut.
Wenn man von einem alten Hash-Algorithmus auf einen moderneren wechselt gibt es ja zwei Wege. Einmal kann man einfach bei jedem Login prüfen, ob noch die alte Version verwendet wird und dann mit dem gerade im Klartext vorhandenen Passwort updaten oder man erklärt alle vorhandenen Passwörter für ungültig (man ersetzt sie durch Zufallscode, die schon mit dem neuen Algorithmus gehasht sind) und verschickt Emails, dass jeder ein neues Passwort eingeben soll.
Problem bei Variante 1 ist, dass inaktive Benutzer ihr altes Passwort behalten, wenn sie sich nicht neu einloggen. Bei Variante 2.. ja.. paar Hundert Emails mit Links zum Passwortwechseln, da weiß man dass es bei ein paar nicht klappen wird und ein paar einfach die Email nicht bekommen werden.
Deswegen wäre das Ideale vorgehen, 1-2 Wochen lang die Passwörter sanft zu migrieren und bei jedem Login das Passwort zu updaten. Nach dieser Zeit wird dann ein Script ausgeführt, das jedem der noch ein altes Passwort hat eine Erinnerungsemail zuschickt und das vorhandene Passwort ungültig macht.
Damit hat man insgesamt wohl am wenigstens Probleme.
Viele System hashen ihre Passwörter immer noch einfach mit MD5. MD5 ist seit längerer Zeit nicht mehr wirklich sicher und ohne Salt sollte man heute sowie so nicht mehr arbeiten. Eines der großen Probleme von MD5 ist, dass es sehr schnell ist. Wenn man Checksums für Dateien erstellen möchte ist es ideal, aber gerade bei Brute-force Angriffen ist ein langsamer Hash-Algorithmus von Vorteil, weil er die Zeit und damit den Aufwand extrem in die Höhe treibt. Salts tun das selbe für Wörterbuch Attacken und Rainbow-Tables.
Wenn man nun auf etwas sicheres Wechseln möchte ist es gar nicht so schwer. Man muss nicht die Passwörter der Benutzer vorliegen haben. Denn bei jedem Login liegt das Passwort für kurze Zeit in der Login-Methode sowie so als Klartext vor. Hier ist also der beste Punkt, um die Änderungen vorzunehmen. Es gibt nur eines dabei zu beachten.
Am Besten fügt man der User Entity ein Version-Flag hinzu, dass man verwendet um festzuhalten welche Hash-Variante gerade verwendet wird. 0 wäre dann einfaches MD5. Es sollte Integer sein, weil boolean einfach zu wenig ist und es mit der Zeit mehr als zwei Möglichkeiten für das Passwort geben wird... ich muss nochmal umbauen.
Wenn der Benutzer sich also einloggt und das Flag auf 0 steht, bedeutet es, dass man den Passwort-Eintrag in der Datenbank aktualisieren muss. Der Login muss dann eben alle möglichen Kombinationen aus Version Flag und Hash-Methode unterstützen. Flag und Hash-Methode immer zusammen, um alles noch sicher zu halten.. ob es ohne wirklich unsicher wäre, müsste man noch mal durch denken, aber verkehr es abzugleichen ist es sicher nicht.
Nun haben wir schon mal unseren neuen Hash, der gesetzt wird, sobald sich der Benutzer das nächste mal einloggt. Jetzt fehlt der Hash und dazu ist nicht viel zu sagen.
NUR niemals den Benutzernamen als Salt verwenden! Denn das würde bedeuten, dass man bei einer Änderung des Benutzernamen auch immer den Passwort-Hash neu setzen müsste und wenn der Admin den Namen des Benutzers ändert, hat er das einfach nicht. Das Salt kann ein Zufallscode sein und mit in der Entity gespeichert werden, würde der Name ja auch und es geht ja nur darum das Berechnen der Hashes aufwendiger zu machen und nicht Security through obscurity zu betreiben. Hier muss ich auch noch mal nacharbeiten :-)
Ich versteh nicht warum so viele Personen Passwörter so negativ gegenüber darstehen. Passwörter sind wichtig und schützen einen. Aber es sind oft auch die Menschen, die das Internet grund sätzlich als unsicher ansehen und glauben jeder könnte jetzt alles von denen sehen. Aber in Firmen sollte es den meisten schon klar sein, dass man sich damit nicht nur selber schützt sondern auch seine Kunden. Also Datenschutz und so.
Windows 7 hat ein Problem. Man muss das Admin-Konto per Hand aktivieren:
net user administrator * /active:yes
Ideal wäre es, wenn man ein admin-Konto und ein normales Konto anlegen müsste. Das automatische Einloggen, sollte nur mit Konten gehen die keine
Admin-REchte haben und man sollte dann das Passwort für das Konto auch nur über eine Admin-Konto setzen dürfen. Nachdem ich erlebt hat wie eine Person 5 Rechner lahm legen konnte, nur weil dort plötzlich ein Passwort gesetzt wurde, sehe ich es als noch dringender an, auch alles über einen Server laufen zu lassen. Denn dann hätte man dort einfach das Passwort nochmals neu gesetzt und alles wäre wieder ok gewesen. Aber sowas kostet ja und viele kleinere Firmen sparen sich das Geld lieber, was man Ende dann bedeutet, dass jemand wie ich Geld damit verdient, Festplatten an USB-Adater zu hängen udn Daten zu kopieren.. da wäre ein Server nach 5 Rechnern schon fast günstiger gwesen, wenn man noch den Arbeitsausfall der Mitarbeiter dazu rechnet.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
