Statistik, FindHotelRoom.de (FU26)- + Fun-App-Zugriffe und Fraud

 
• Fraud/Angriffe: siehe rechts.  
 
Die Zugriffe auf die FindHotelRoom.de-Haupt-Anwendung und auf die angedockte, quasi autonome Fun-App werden einheitlich und unabhängig von einander protokolliert.  
 

Zugriff-Ablage

Die protokollierten User-Zugriffe auf die Seiten der Haupt-Anwendung (ha1) und der Fun-App (app,Fun-App) werden alle im x7-Basis-Verzeichnis gespeichert. Die Dateinamen der Protokolle orientieren sich an der laufenden Woche des Jahres. Sowohl die Standard-Protokolle als auch die Fraud-Protokolle werden im x7-Basis-Verzeichnis im x7-std-Unter-Verzeichnis abgelegt.  
 
Schadhafte Parameter werden bei FindHotelRoom.de (FU26) an zwei Stellen abgefangen:
1) Am Vor-Filter der Protokoll-Stelle (nur die hier abgefangenen Parameter gehen ins Fraud-Protokoll)
2) An der DB-Schnittstelle (hier letztendlich vollständige Abwehr des Angriffs)  
 
Außerdem gibt es Parameter, die niemals gefährlich werden können, das nur die ersten ein oder zwei Zeichen (z.B.j/n, de/en) durchgelassen werden und die Sache ggf. auf ein Default-Wert fällt. Dies hat ausschließlich statistische Relevanz.  
 
Protokolle:
 
Beispiele-Standard-Protokoll-Sätze Haupt-Anwendung (ha1):
|.!dd:16.07.26 20:00 .!vu:uk .!nr:ha1 .!ip:2003:d2:9711:6ed8:3da7:7908:6d4b:b003 .!Thema-Sel:uk .!lang:de .!ortSuche:Hamburg .!ortWolke: |.!dd:16.07.26 20:00 .!vu:uk .!nr:ha1 .!ip:2003:d2:9711:6ed8:3da7:7908:6d4b:b003 .!Thema-Sel:uk .!lang:de .!ortSuche: .!ortWolke:nrw  
 
Beispiel-Standard-Protokoll-Satz - Fun-App:
|.!dd:16.07.26 20:02 .!vu:uk .!nr:Fun-App .!ip:2003:d2:9711:6ed8:3da7:7908:6d4b:b003 .!Thema-Sel:uk .!pk/km-Sel:2/ .!button: .!in:Standort:a&o Düsseldorf Hauptbahnhof, 40215 Düsseldorf - Friedrichstadt .!px:6.782170 .!py:51.216280 .!pi:1 .!Sprache:de  
 
Hinweis:
Alle NICHT Protokoll-Sätze, die manipuliert sind, jedoch vom Fraud-Protokoll-Fänger nicht erkannt werden, laufen NICHT ins Fraud-Protokoll, sondern in das Standard-Protokoll. Es ist zu erwarten, dass die Anzahl dieser nicht erkannten Fraud-Sätze gering ist. Falls es nicht der Fall sein sollte, wird entsprechend nachgebessert.  
Bezüglich der System-Wirkung laufen auch diese Angriffe ins Leere oder werden vom DB-Interface erkannt. Eine Nachbeserung an dieser Stelle hätte einzig eine verbesserte Statistik zum Ergebnis.  
 

Statistische Auswertungen

Crawler der Suchmaschienen USA, Russland, China
Internet-Dienstleister: Semrush, ...  
 
... Statistische Auswertungen, Umschichtungen oder IP-Adress-Sperrungen kommen erst später hinzu. [!!:ToDo]  
 
 
 

Fraud - Angriffe auf FindHotelRoom.de (FU26)

 
Zugriffe, die mit einem versuchten Angriff auf die beiden Anwendungen zusammenhängen, werden sofort separiert und separat in einer Fraud-Protokoll-Datei protokolliert.  
 
Angriffe (Fraud) auf FindHotelRoom.de werden protokolliert. Zudem wird ein Pseudo-Ergebnis (sogenanntes leeres Ergebnis) geliefert und am Bildschirm ausgegeben. Das leere Ergebnis ist nicht wirklich leer, sondern ist beispielsweise eine Standardmeldung von FindHotelRoom.de. Es wird kein direkter Kenntnis-Hinweis auf den Vorfall gegeben. Das System arbeitet normal weiter. Das verwirrt die Angreifer am meisten und liefert eben keine Hinweise, die irgendwie nützlich sein könnten. Einem Angreifer bleibt dadurch eigentlich unklar, ob der Angriff entdeckt wurde. In manchen Fällen wird jedoch ein nichts sagender Hinweis hinzugepackt (internes Sicht-Signal), z.B.: Sonderfall beachten.
Für den Fall der Fälle, dass es zu irrtümlichen Fraud-Situationen kommen sollte. So sieht man selber einen erkennbaren Hinweis, der von anderen nicht wirklich beachtet werden wird.  
 
👉 Fraud-Hinweis bei Haupt-Anwendung (ha1):
Als Suchort geht nicht der manipulierte SuchOrt an die Linie, sondern wie im Suchfeld zu sehen, der nicht existierende Ort:
Sonderbart  
 
Fraud-Abwehr - falls zu scharf eingestellt
Falls bei einer Eingabe Unterkunft-Suche, beispielsweise zu einem Ort, das Sonderbart erscheint mit Hinweis gibt es nicht, so landet dieser Vorgang im Fraud-Protokoll und gibt Hinweise darauf, was in Sachen Angriff-Abwehr möglicherweise zu scharf eingestellt ist. Das kann dann nachgebessert werden.  
 
👉 Fraud-Hinweis bei Fun-App:
Ganz unten bei: Alternativen nahe Wunsch-Unterkunft + Fraud-Hinweis:
Sonderfall beachten.  
 
 
Protokolle:
 
Beispiel-Fraud-Protokoll ha1-Satz:
|.!dd:16.07.26 20:14 .!vu:uk .!nr:ha1 .!ip:2003:d2:9711:6ed8:3da7:7908:6d4b:b003 .!Thema-Sel:uk .!lang:de:1=1 .!ortSuche:Mainz .!ortWolke: .!ha1-Fraud:Sprache lang:de:1=1 ...  
 
In dem Beispiel wurde die Sprache manipuliert: de:1=1  
 
Beispiel-Fraud-Protokoll Fun-App-Satz:
|.!dd:16.07.26 20:01 .!vu:uk .!nr:Fun-App .!ip:2003:d2:9711:6ed8:3da7:7908:6d4b:b003 .!Thema-Sel:uk .!pk/km-Sel:2/ .!button: .!in:Standort:a&o Düsseldorf Hauptbahnhof, 40215 Düsseldorf - Friedrichstadt .!px:6.782170 .!py:x51.216280 .!pi:1 .!Sprache:de .!Fun-App-Fraud:py:x51.216280 ...  
 
In dem Beispiel wurde dem Geokoordinaten-lat-Wert ein x hinzugemogelt: x51.216280  
 
Fraud-Protokoll-Sätze:
Inhalt mit dem Standard-Protokoll-Satz identisch. Jedoch am Ende des Satzes, nach !Sprache, gibt es die Fraud-Info, z.B.:
.!Sprache:de .!Fun-App-Fraud:py:x51.216280 ...  
 
 
Bei der Protokoll-Fraud-Abfang-Vorstufe des Fraud-Protokolls gibt es Lücken. Jedoch sind diese in der Regel harmlos. Möglicherweise doch übersehene schad-bringende Parameter werden spätestens bei der FindHotelRoom.de (FU26)-DB-Zugriff-Schnittstelle abgefangen und neutralisiert (nach Symfony-Art).