sheel
I love Asm
Und dann? Wie soll der Server das überprüfen, wenn es nicht "in" einem Inputfeld ist, oder per JS gesendet wird?
✔ Ein paar grundlegende Sachen zur Sicherheit in PHP / MySQLi
- Themenstarter filament
- Beginndatum
filament
Erfahrenes Mitglied
Jetzt verstehe ich Deine Frage erst.
Ich würde das in einer Datenbank hinterlegen und prüfen
Oder aber ich übergebe es per Session, was die Anfragen geringer halten würde.
Nur die Bots werden wahrscheinlich mittlerweile Kopieren und Einfügen können wenn im selben Formular. Ich will ja auch die Nutzer nicht abschrecken und es zu umständlich machen.
Was mich im Dienst z. B. total abnervt sind diese bitte wählen Sie Verkehrsschilder oder Ladengeschäfte aus den Bildern aus.
Ich würde das in einer Datenbank hinterlegen und prüfen
Oder aber ich übergebe es per Session, was die Anfragen geringer halten würde.Nur die Bots werden wahrscheinlich mittlerweile Kopieren und Einfügen können wenn im selben Formular. Ich will ja auch die Nutzer nicht abschrecken und es zu umständlich machen.
Was mich im Dienst z. B. total abnervt sind diese bitte wählen Sie Verkehrsschilder oder Ladengeschäfte aus den Bildern aus.
Hi,
ohne Javascript? Da hast du nicht viele andere Möglichkeiten. Eventuell kannst du die zu schützende Funktion nur für angemeldete Benutzer freigeben?
Wenn es um die Anmeldung / Registrierung geht, dann wirst du hier wohl oder übel ein Captcha verwenden müssen. Die Bots sind teilweise schon so "intelligent", dass diese auch Javascript ausführen können um an die Werte zu kommen. Sobald es auf der Seite irgendwo steht (in Klartext) oder durch Javascript berechnet wird, dann können die Bots das auch raus parsen und verwenden. Generell kannst du das also nie zu 100% verhindern.
Die "einfachsten" Bots parsen nur die HTML-Seite, zerlegen diese in den DOM-Tree und holen sich da dann die Daten raus. Von daher erkennen diese meistens schon hidden-Felder, das ist inzwischen schon zu weit verbreitet und bekannt.
Die nächste Stufe erkennt Javascript und hat eine eigene HTML-Engine mit an Board (z.B. Gecko). Damit lässt der Bot die Seite komplett generieren und holt sich anschliessend die generierten Werte raus. Vo ndaher kann deine Berechnung noch so gut obfuskiert und versteckt sein, das interessiert die nicht sondern. Die emulieren ja einen richtigen Browser.
Eine Bilderkennung ist da schon etwas komplexer, wobei hier die Eigenimplemtnierungen meistens eher schlecht als Recht sind. Vorallem mit den aufkeimenden künstlichen Intelligenzen wird es immer einfacher, Zeichen in Bildern zu erkennen. Siehe zum Beispiel Googles Recaptcha. Hier trainierst du mit dem Lösen der Captcha die AI von Google
// Edit:
Grüsse,
BK
ohne Javascript? Da hast du nicht viele andere Möglichkeiten. Eventuell kannst du die zu schützende Funktion nur für angemeldete Benutzer freigeben?
Wenn es um die Anmeldung / Registrierung geht, dann wirst du hier wohl oder übel ein Captcha verwenden müssen. Die Bots sind teilweise schon so "intelligent", dass diese auch Javascript ausführen können um an die Werte zu kommen. Sobald es auf der Seite irgendwo steht (in Klartext) oder durch Javascript berechnet wird, dann können die Bots das auch raus parsen und verwenden. Generell kannst du das also nie zu 100% verhindern.
Die "einfachsten" Bots parsen nur die HTML-Seite, zerlegen diese in den DOM-Tree und holen sich da dann die Daten raus. Von daher erkennen diese meistens schon hidden-Felder, das ist inzwischen schon zu weit verbreitet und bekannt.
Die nächste Stufe erkennt Javascript und hat eine eigene HTML-Engine mit an Board (z.B. Gecko). Damit lässt der Bot die Seite komplett generieren und holt sich anschliessend die generierten Werte raus. Vo ndaher kann deine Berechnung noch so gut obfuskiert und versteckt sein, das interessiert die nicht sondern. Die emulieren ja einen richtigen Browser.
Eine Bilderkennung ist da schon etwas komplexer, wobei hier die Eigenimplemtnierungen meistens eher schlecht als Recht sind. Vorallem mit den aufkeimenden künstlichen Intelligenzen wird es immer einfacher, Zeichen in Bildern zu erkennen. Siehe zum Beispiel Googles Recaptcha. Hier trainierst du mit dem Lösen der Captcha die AI von Google
// Edit:
Das ist das erwähnte Recaptcha und im Moment so ziemlich das einzige (mir bekannte) System, was Spammer wirkungsvoll abhält und gleichzeitig auch einfach zu benutzen ist. Es nervt, stellt Menschen aber nicht vor allzu grossen Herausforderungen.Was mich im Dienst z. B. total abnervt sind diese bitte wählen Sie Verkehrsschilder oder Ladengeschäfte aus den Bildern aus.
Grüsse,
BK
filament
Erfahrenes Mitglied
Hmmm klingt nicht so befriedigend. Ich will es einfach nicht einbinden. Es schreckt Leute ab.
Okay wie wäre es damit:
Hidden Field als Checkbox I am not a User. Dazu Kontrolle ob das Formular in ein paar Sekunden ausgefüllt wurde. Wenn eines der Beiden zutrifft, dann Fehlermeldung. Email auf Plausibilität prüfen (Gibt es ja eine Funktion in PHP für, Sonst reguläre Ausdrücke). Danach dann Server der Email auf Erreichbarkeit prüfen. Sprich ob dieser existiert. Wenn er angesprochen werden kann kommt der nächste Schritt, wenn nicht dann kommt eine Fehlermeldung dass das nicht möglich war. Sollte das der Fall sein binde ich ein Captcha zur Verifizierung ein.
Sollte der Besuche den dritten Schritt erreicht haben, ob mit oder ohne Captcha, wird er in die Datenbank geschrieben aber auf inaktiv gesetzt.
Dann erstelle ich ein Validations-Code, den gibt es per Mail mit Link. Wenn der User nicht innerhalb von 7 Tagen aktiviert wird -> löschen.
Alles andere was Eingaben betrifft kann nur von registrierten angemeldeten Usern abgeschickt werden.
Dann müsste ich doch den großen Teil von Bots und Spam ausschließen?
Okay wie wäre es damit:
Hidden Field als Checkbox I am not a User. Dazu Kontrolle ob das Formular in ein paar Sekunden ausgefüllt wurde. Wenn eines der Beiden zutrifft, dann Fehlermeldung. Email auf Plausibilität prüfen (Gibt es ja eine Funktion in PHP für, Sonst reguläre Ausdrücke). Danach dann Server der Email auf Erreichbarkeit prüfen. Sprich ob dieser existiert. Wenn er angesprochen werden kann kommt der nächste Schritt, wenn nicht dann kommt eine Fehlermeldung dass das nicht möglich war. Sollte das der Fall sein binde ich ein Captcha zur Verifizierung ein.
Sollte der Besuche den dritten Schritt erreicht haben, ob mit oder ohne Captcha, wird er in die Datenbank geschrieben aber auf inaktiv gesetzt.
Dann erstelle ich ein Validations-Code, den gibt es per Mail mit Link. Wenn der User nicht innerhalb von 7 Tagen aktiviert wird -> löschen.
Alles andere was Eingaben betrifft kann nur von registrierten angemeldeten Usern abgeschickt werden.
Dann müsste ich doch den großen Teil von Bots und Spam ausschließen?
Hi,
ist es wirklich den Aufwand wert?
Was hindert mich als Spammer daran, eine Dummy-Domain zu registrieren und einen Mailserver dort zu starten der einfach nur "OK" sagt?
Ausserdem muss der Spammer nicht hier hin kommen, er kann schon früher "entkommen" und erfolgreich sein.
Obwohl dein System recht komplex erscheint und viele Fallstricke hat, kann das automatisiert umgangen werden.
Zusammenfassung wie das umgangen werden kann:
* Formular zu schnell abgeschickt? 50 parallele Sessions aufmachen, 30 Sekunden warten, ausfüllen, senden. Das bremst nur marginal.
* EMail auf Format prüfen? Sollte sowiso gemacht werden; Ist aber gar nicht mal so trivial.
* Mailserver erreichbar? Eigene Domain registrieren mit Mailserver. Dann ein Catch-All Postfach einrichten, somit kann er a@example.net, b@example.net, c@example.net usw. verwenden.
* Aktivierungsmail? Siehe vorherigen Punkt
Du müsstest noch eine Art "Quota" per IP oder Maildomain einführen, wobei dir das dann (wenn du mehr Benutzer hast) um die Ohren fliegen kann.
Der Kampf gegen Spammer ist wie der Kampf gegen Windmühlen. Man kann hier nicht gewinnen, das ganze nur verlangsamen.
Grüsse,
BK
ist es wirklich den Aufwand wert?
Um das Verhalten als Spammer zu erkennen brauch ich nicht lange und kann meine Bots darauf anpassen. Dazu noch von verschiedenen IPs / mit verschiedenen Sessions und gut ists.
Bitte zeige mir einen Regular Expression, welcher auch mit Umlautdomains und sonstigen RFC-Schweinereien umgehen kann
Du nimmst also die Mail, machst einen MX Lookup auf die Domain. Baust eine Verbindung mit dem Server auf, teilst ihm per "RCPT TO" die vom User angegebene Mailadresse mit und schaust ob ein 2xx-Status zurückkommt. Danach trennst du die Verbindung. Das wird von einigen Servern (je nachdem wie oft du hier Adressen prüfst) schnell als Adress-Farming erkannt und du wirst geblockt.
Was hindert mich als Spammer daran, eine Dummy-Domain zu registrieren und einen Mailserver dort zu starten der einfach nur "OK" sagt?
Und wieder mehr Komplexität, die du hier einbaust. Alleine um die ganzen Stati zu verfolgen (wann darf der Benutzer in welchem Status sein) musst du das ordentlich durchplanen und vor allem auch dokumentieren. Und das ganze soll dann natürlich auch noch wartbar bleiben
Ausserdem muss der Spammer nicht hier hin kommen, er kann schon früher "entkommen" und erfolgreich sein.Warum also die ganzen Prüfungen der Domain usw? Warum nicht gleich hierher?
Siehe Punkt "Erreichbarkeit". *Was hindert den Spammer daran, einen Mailserver zu emulieren und die Abfragen / die Mail abzufangen und automatisiert zu bestätigen?*
Obwohl dein System recht komplex erscheint und viele Fallstricke hat, kann das automatisiert umgangen werden.
Zusammenfassung wie das umgangen werden kann:
* Formular zu schnell abgeschickt? 50 parallele Sessions aufmachen, 30 Sekunden warten, ausfüllen, senden. Das bremst nur marginal.
* EMail auf Format prüfen? Sollte sowiso gemacht werden; Ist aber gar nicht mal so trivial.
* Mailserver erreichbar? Eigene Domain registrieren mit Mailserver. Dann ein Catch-All Postfach einrichten, somit kann er a@example.net, b@example.net, c@example.net usw. verwenden.
* Aktivierungsmail? Siehe vorherigen Punkt
Du müsstest noch eine Art "Quota" per IP oder Maildomain einführen, wobei dir das dann (wenn du mehr Benutzer hast) um die Ohren fliegen kann.
Der Kampf gegen Spammer ist wie der Kampf gegen Windmühlen. Man kann hier nicht gewinnen, das ganze nur verlangsamen.
Grüsse,
BK
filament
Erfahrenes Mitglied
Sagt mal wie sieht es eigentlich mit dem Schutz vor zu vielen Anfragen an den Webserver aus? Nehmen wir mal an ich habe richtig viele Zugriffe am Tag. Ab wievielen Besuchern muss ich mir Gedanken machen, dass mein Server das nicht gebacken bekommt?
Was kann man in diesem Fall dann machen? Wahrscheinlich eine Umleitung auf einen zweiten Server nehme ich an? Wie läuft sowas technisch ab? Auf was muss da im Hinblick auf die Sicherheit beachtet werden?
Was kann man in diesem Fall dann machen? Wahrscheinlich eine Umleitung auf einen zweiten Server nehme ich an? Wie läuft sowas technisch ab? Auf was muss da im Hinblick auf die Sicherheit beachtet werden?
sheel
I love Asm
Lässt sich so schwer sagen ... hängt ganz von deiner Situaion ab. Wann die Seite für dich zu langsam ist musst du selber wissen. Andere Kriterien wie verfügbarer Festplattenspeicher, oder zB. ob es die abzuarbeitenden Mails schafft ohne dass sich immer mehr aufstaut, muss man eben nachschauen.
Umleitungen im Sinn von HTTP sind in dem Fall jedenfalls keine Abhilfe (nur ein guter Weg, das Googleranking dauerhaft kaputt zu machen)
...
Wenn es um die generelle Last geht,
a) größerer (schneller usw.) Server
b) wenn das nicht mehr reicht, verschiedene Aufgaben auf verschiedene Server (zB. 4: statische Dateien wie Bilder, DB, PHP, Mail und anderes Zeug) und/oder Caches einführen (als Beispiel, die Neue-Forums-Beiträge Box hier rechts macht nicht bei jedem Seitenaufruf eine eigene SQL-Abfrage, um die Daten zu bekommen, sondern nur alle paar Minuten. Nachteil ist, dass es nicht immer die wirklich neuesten Beiträge sind, aber für den Geschwindigkeitsgewinn war das akzeptabel)
c) wenn das nicht mehr reicht, Einfachvariante Loadbalancing: Entweder beim überlasteten Ding (DB? PHP? ...) den Hauptserver die Arbeit nur auf ein paar andere Server verteilen lassen (dann Ergebnis zurückbekommen und zum Client senden ... hilft aber nicht wenn der Traffic das Problem ist, und auch der Verteilerserver kann irgendwann an die Grenzen kommen) (aufteilen entweder "alles auf allen Teilservern", oder "jeder Teilserver hat seinen eigenen Teil" was bei Speicherproblemen eher angebracht ist), oder mehrere gleichartige DNS-Einträge ("Round robin", Browser usw. nehmen dann halbwegs zufällig eine IP daraus, nicht nur immer die erste. Es ist aber nicht immer ausgeglichen; speziell mit Proxies usw. gibts wieder Situationen wo unverhältnismäßig viele Leute die selbe IP verwenden; und außerdem skaliert es nicht (4 IPs ok, 40 nicht mehr)
In beiden Fällen natürlich immer dafür sorgen, dass alle Teilserver die selben Daten haben (zumindest, wenn es nicht beacbsichtigt ist dass jeder Teilserver nur einen Teil hat) (speziell wenn es um die DB geht ... MasterSlave-Zeug wird von DB-Systemen oft auch ohne Bastelei unterstützt)
d) Nur der Vollständigkeit halber (wenn (c) auch nicht mehr reicht (weil RoundRobin und Verteilserver alle auch Grenzen haben) hat man hoffentlich schon ein Team von Sysadmins, die das folgende selber wissen): Hoster kontaktieren (bzw. die nächsthöhere Stelle, viele Hoster sind dazu auch nicht in der Lage) und ins Großrouting einsteigen (BGP usw.).
...
Btw., eng verbunden mit dem Thema (zumindest in den Stufen c und d) ist Ausfallsicherheit, bzw. dass ein ausfallender Teilserver die User nicht stört weil die anderen die Arbeit auch noch schaffen, und man es so aufgebaut hat dass die tote IP nicht stört...
...
Zurück zum eigentlichen Thema, bösartige Variante:
Wenn jemand einfach möglichst viel Anfragen etc. macht, damit dein Server überlastet wird, kann man technisch dagegen nicht viel machen. Zeug wie Sperren an verschiedenen Punkten (zB. IP-Sperren) hilft nicht, weil a) IPs kann man wechseln oder gleich von Anfang an mehrere verwenden, und wichtiger b) Die Anfrage kommt trotzdem zum Server etc., und verbraucht auch Prozessorzeit, Traffic usw. (Reduziert ja, weil zB. kein PHP usw. mehr laufen muss, aber trotzdem existiert eine Last).
... falls man auf dem legalen Weg nichts erreichen kann (bzw. nicht schnell genug), ist die Kernfrage dann einfach, wer der Stärkere ist. Überspitzt gesagt, ein einzelner Haushalts-PC mit einer 10MBit-Leitung kann nicht genug Anfragen machen, um Google zu überlasten. Google könnte umgekehrt den PC und dessen Internetanschluss schon überlasten, weil sie einfach mehr/bessere Computer usw. haben.
Botnets spielen bei realen DDOS-Attacken gegen halbwegs "prominente" Ziele eine relativ große Rolle. Statt sich selber zehntausende Computer kaufen, ist es billiger zehntausende nicht-upgedatete Computer im Internet zu hacken (ohne was sichtbar kaputt zu machen) und dann diese Computer die ganzen Anfragen machen lassen (viele Besitzer merken auch dann noch immer nicht, dass sie nicht mehr alleiniger Verwender ihres Computers sind... wie sollten sie auch.)
Zuletzt bearbeitet:
filament
Erfahrenes Mitglied
Macht denn das Cachen von Daten Sinn?
Wenn ja, wie sollte man da vorgehen? Einfach die Datenbankanfragen per Cronjob regelmäßig machen lassen und die Inhalte in eine PHP Datei auslagern, die included wird? Oder macht das keinen Sinn weil ich dann auch den Request auf die Datei habe?
https://upload-magazin.de/blog/10429-die-wichtigsten-handgriffe-fuer-eine-schnelle-website/
In diesem Artikel wird noch einiges erwähnt das ich spannend finde und mich jetzt etwas mehr interessiert. Vor Allem die Meinung von Leuten die mehr Ahnung haben.
Dort steht unter Anderem auch dass man von Weiterleitungen ala WordPress Abstand nehmen soll. Wie soll man denn dann ein großes Projekt aufbauen? Ich kann ja wohl schlecht jede Seite einzeln per PHP erstellen. Gerade in Foren etc. wo die Inhalte dynamisch erzeugt werden, wäre das ja ein Irrsinniger Aufwand.
Meint Ihr das dass komprimieren per Htaccess notwendig / zielführend ist?
Wenn ja, wie sollte man da vorgehen? Einfach die Datenbankanfragen per Cronjob regelmäßig machen lassen und die Inhalte in eine PHP Datei auslagern, die included wird? Oder macht das keinen Sinn weil ich dann auch den Request auf die Datei habe?
https://upload-magazin.de/blog/10429-die-wichtigsten-handgriffe-fuer-eine-schnelle-website/
In diesem Artikel wird noch einiges erwähnt das ich spannend finde und mich jetzt etwas mehr interessiert. Vor Allem die Meinung von Leuten die mehr Ahnung haben.
Dort steht unter Anderem auch dass man von Weiterleitungen ala WordPress Abstand nehmen soll. Wie soll man denn dann ein großes Projekt aufbauen? Ich kann ja wohl schlecht jede Seite einzeln per PHP erstellen. Gerade in Foren etc. wo die Inhalte dynamisch erzeugt werden, wäre das ja ein Irrsinniger Aufwand.
Meint Ihr das dass komprimieren per Htaccess notwendig / zielführend ist?
Zuletzt bearbeitet:
