• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Site-Parsing überprüfen ?

X

xoli

New member
Hi

Kurzfassung: per AJAX/PHP wird aus einer MySQL Datenbank eine Datenübersicht erstellt. Diese Seite ist für einige unserer Mitarbeiter online sichtbar und für Andere nicht. Nun hat sich herausgestellt, dass eine Schnittstelle geschrieben wurde, die sich wahrscheinlich irgendwie die Daten der Ausgabeseite nimmt und in einem eigenen Script darstellt. Der Link der entsprechenden Seite ist bekannt, da die eine Abteilung mit der Anderen kommuniziert. Benutzung fremder LogIn-Daten kann ich ausschliessen. Dadurch dass unsere Scripte nicht genutzt werden, ist es nicht möglich mit zu loggen und den Fremdzugriff zu beweisen .. es kann also nur sein, dass mit den fertig ausgewerteten Daten gearbeitet wird .. genau da liegt mein Problem ..

1. würde mich interessieren mit welchen Hilfsmitteln (Tools) so was machbar wäre. Wie kommen die an die sichtbaren Informationen um die dann für sich zu nutzen? Wie kompliziert ist so was?
2. gibt es eine Möglichkeit die Leute in eine Falle laufen zu lassen und das Parsen unserer Seite zu loggen?
3. was wäre euer Tip wie ich mich dagegen am Besten wehre?
4. was könnte man auf die Schnelle ändern/anpassen, damit das geparste Script die Daten nicht mehr richtig ausgibt?
5. gibt es evt andere Möglichkeiten als eine bereits fertig ausgegebene Seite zu parsen? Ist für mich die einzig denkbare Möglichkeit an die Daten zu kommen aber vielleicht liege ich ja falsch.

Ich würde mich wirklich um jeden Tip freuen, da dass hier ein ernstes Problem ist.

lg und vielen Dank
 
Verstehe ich das richtig, dass es um unerwünschtes Screenscraping der Seite geht? Dann kann man dem relativ einfach begegnen indem man wesentliche Ansatzpunkte verändert, Beispiel: Wenn jetzt etwas in einer <table> dargestellt wird, daraus ein <div> mit CSS Formatierungen machen. Dadurch verändert sich für den Benutzer garnichts aber der Screenscraper findet u.U. keine Daten mehr. Meinst du sowas?
 
Was mir noch gerade einfällt: Wenn die andere Abteilung mal irgendwann den Quellcode bekommen hat könnten sie den Ajax Request nachgebaut haben, das ist im Zweifeld ganz einfach, denn ein GET Request kann einfach durch Eingabe der Parameter in der URL Zeile nachempfunden werden. Ist dieser Request denn nicht an die Session gebunden? Also hat er nicht als Mindestanforderung an Sicherheit wenigstens ein Feld mit einer Session-ID die serverseitig überprüft wird? Dann könnte man darüber und über ein access.log mit IP-Adresse einige Informationen darüber sammeln und auswerten.
Außerdem könnte man den Request - falls er jetzt GET ist - in POST ändern, dann müsste die andere Abteilung erst nochmal dieses nachbauen.
 
Hallo

Ja genau darum gehts es. Über deinen 1. Post hatte ich bereits nachgedacht, bin aber der Meinung dass es nicht viel bringt, da der Quelltext der entsprechenden Seite jederzeit über einen entsprechenden PC einer anderen Abteilung neu ausgelesen werden und wieder angepasst werden kann. Damit knüpfe ich auch direkt an den 2. Post an. Sich den Quellcode zu besorgen halte ich für sehr wahrscheinlich und möglich. Die Requests haben nur POST Parameter und es gibt eine ID, welche dann serverseitig abgefragt wird .. allerdings ist diese nicht verschlüsselt ?! Ein Request sieht z.B. so aus:
Code: 
if (xmlHttp) {
       var url = "link.php";
       var params = "Merker=18&abt="+abt+"&grp="+group+"&job=<?php echo $job; ?>";
		
       xmlHttp.open("POST", url, true);
       xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded;charset=UTF-8");
       xmlHttp.setRequestHeader("Content-length", params.length);
       xmlHttp.setRequestHeader("Connection", "close");					
			
       xmlHttp.onreadystatechange = function () {
	      if (xmlHttp.readyState == 4) {
		 var A = xmlHttp.responseText;
                           .
                           .
                           .
              }
       };
       xmlHttp.send(params);	
}

lg
 
Ja, dann würde ich an deiner Stelle mit Token arbeiten.
Das heißt, bei jedem Seitenaufbau wird eine Zufallszahl generiert die dem Benutzer zugeordnet wird. Diese Zufallszahl muss dann vom anschließenden Ajax Request mitgeliefert werden, sonst antwortet der Server nicht. Das ganze kann man dann serverseitig mitloggen. Dann weißt du, über welchen Benutzer du an des Rätsels Lösung kommen kannst.
Falls kein weiterer unbefugter Zugriff mehr erfolgt hast du das Ziel ebenso erreicht, dass haben die es nämlich nicht hinbekommen, das Token vor dem eigentlichen Ajax Request abzufangen.
 
Danke .. das mit dem Token klingt super .. 1 Frage zwischendurch .. ist es wirklich so einfach dass ich nur den absoluten Pfad im Request angeben müsste und dann die entsprechenden Daten zurück geliefert bekomme?
 
Thema "TOKEN" scheint genau das zu sein was ich benötige. Allerdings geht es mir nicht nur darum die Seite sicher zu machen, sondern auch darum zu sehen, wer den Unfug anstellt.
Ich teste mich mal langsam ran und versuche mal nachzuvollziehen was du meinst:

1. Schritt - Token/Session generieren und verschlüsseln
Code: 
<?php
  session_start();
  $token = md5(rand(1000,9999));
  $_SESSION['token'] = $token;
?>

2. Schritt - Token meinem AJAX-Request übergeben
Code: 
if (xmlHttp) {
       var url = "link.php";
       var params = "Token=<?php echo $_SESSION['token']; ?>&Merker=18&abt="+abt+"&grp="+group+"&job=<?php echo $job; ?>";
		
       xmlHttp.open("POST", url, true);
       xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded;charset=UTF-8");
       xmlHttp.setRequestHeader("Content-length", params.length);
       xmlHttp.setRequestHeader("Connection", "close");					
			
       xmlHttp.onreadystatechange = function () {
	      if (xmlHttp.readyState == 4) {
		 var A = xmlHttp.responseText;
                           .
                           .
                           .
              }
       };
       xmlHttp.send(params);	
}

Ab jetzt verstehe ich nicht mehr wie es weiter gehen soll .. wie kann ich das Token einem angemeldeten User anhängen und serverseitig auf Gültigkeit prüfen?
Zumal in meinem Fall ja noch dazu kommt, dass selbst die angreifende Person ein zulässiger Benutzer ist .. ich müsste das Token dann im Zusammenspiel mit der Abteilung prüfen, oder versteh ich da was völlig falsch ?
 
Ja Moment, darf/kann denn der unberechtigte Benutzer die Seite aufrufen? Wird er dabei serverseitig identifiziert oder ist das ein Intranet, wo jeder alles aufrufen kann?
 
Ist eine reine Online-Seite und kein Intranet. Vorab gibt es einen LogIn Bereich und DIESE Seite darf er nicht aufrufen. Der entsprechende Link ist Benutzer gesteuert und ihm fehlen die Rechte. Ich versuch es etwas bildlicher zu machen .. es gibt Büromitarbeiter, die sehr viele Rechte (Buttons/Links...) haben und es gibt Außenmitarbeiter mit entsprechend weniger Rechten .. die Rechteverteilung läuft, da sie LogIn gesteuert ist und serverseitig abgefragt wird. Problem an der Sache ist, dass die Außenmitarbeiter auch manchmal im Büro sind, einen Blick auf Sachen geworfen haben, die sie nichts angehen und nun bei der Ein oder Anderen Geschichte versuchen die verbotenen Infos für sich trotzdem sichtbar zu machen. Vor einigen Monaten kam dann auch mal raus dass LogIn daten untereinander getauscht wurden worauf das Logging extrem verschärft wurde. Fremde Benutzerdaten kann ich ausschliessen, aber ich weiß dass eine Einsicht in den Quelltext über eine andere Abteilung, die die entsprechenden Rechte hat, gewährleistet ist .. und genau das muß ich ändern und blockieren ..
 
Das heißt, wir sprechen von dieser Situation: Ein Mitarbeiter gelangt durch einen bislang unbekannten Request an Daten für die er nicht berechtigt ist. Wir wissen aber nicht, ob dieser Mitarbeiter für diese Daten die Zugangsdaten einer anderen Person nutzt. Du sagst zwar, du kannst das ausschließen aber wodurch kannst du das?

Wir reden ja von einem Mitarbeiter der an einem Arbeitsplatz sitzt, dort authentifiziert und berechtigt ist und von diesem Arbeitplatz Inhalte abfragt, für die er nicht berechtigt ist.

Und was genau wollen wir jetzt erreichen? Soll der Zugriff gesperrt werden oder soll der Mitarbeiter aufgespürt werden zwecks Sanktionen?

Eines davon verstehe ich noch nicht ganz: Wenn der verbotene Content eine öffentliche Webseite ist die auch durch Login gesichert ist, wie soll ein unberechtigter Mitarbeiter diesen Content abrufen nur durch Kenntnis des Quelltextes? Du sagst, er nutzt garantiert nicht die Zugangsdaten einer anderen Person. Ja hat dann das Login einen Bug? Oder ist die Berechtigungsstruktur lediglich dadurch abgebildet, dass man Leuten Links anzeigt oder nicht anzeigt (das wäre dann eine mehr oder weniger organisatorische Sache, weil technisch bietet das ja 0 Sicherheit, was aber nicht zu der Aussage passt, dass das eine öffentliche Seite ist)?

Ich sehe im Moment noch folgenden Widerspruch den ich nicht aufgelöst bekomme:
xoli schrieb:
Ist eine reine Online-Seite und kein Intranet. Vorab gibt es einen LogIn Bereich
Zum Vergrößern anklicken....
sowie
xoli schrieb:
und ihm fehlen die Rechte
Zum Vergrößern anklicken....
versus
xoli schrieb:
Fremde Benutzerdaten kann ich ausschliessen
Zum Vergrößern anklicken....
 
Ich glaube da habe ich mich zu undeutlich ausgedrückt. Es handelt sich um eine normale Internet Seite, auf der ich mich einlogge, um dann in den Hauptbereich zu gelangen. Abhängig vom Benutzer der sich gerade anmeldet wird man dann in unterschiedliche Oberflächen geleitet. Die Berechtigungsstruktur bezieht sich auf die Funktionalitäten in der entsprechenden Oberfläche .. nicht jeder Mitarbeiter sieht die gleichen Buttons / Links und die entsprechenden Berechtigungen werden serverseitig verwaltet. Demzufolge hat die Person, um die es geht, keine Möglichkeit sich die entsprechende Seite oder den Quelltext anzeigen zu lassen. Das kriegt sie nur hin, wenn sie ins Büro fährt, sich neben einen Büromitarbeiter setzt und mit ihm zusammen die entsprechende Seite aufruft. Das ist möglich, da es um Disponierung geht und bei dem Ein oder Anderen Termin zusätzliche Dinge geklärt werden müssen, was die Außenmitarbeiter dann schon einmal im Büro machen.
Also über seinen Account kommt er an die Seite nicht ran, dadurch dass er sie aber auf einem anderen Rechner mal gesehen hat kennt er den Link. Dadurch dass die Problematiken vor 1 Jahr noch nicht so verschärft waren, und es im Büro teilweise auch lockerer zuging, gab es für die entsprechende Person also zahlreiche Situationen sich den Quellcode anzeigen und weiterleiten zu lassen.

Warum ich "ausschliessen" (klar 100% geht das nie) kann, dass es ein fremder LogIn ist hat mehrere Gründe:
- einer der Außenmitarbeiter hat mir gesteckt dass es eine Schnittstelle gibt, die unsere fertigen Daten neu abbildet
- vor ca. 4 Wochen sind für alle Benutzer neue Passwörter generiert worden
- serverseitig wird ne Menge mitgeloggt .. ist jetzt zu kompliziert, aber das würde auffallen .. mal davon ab dass ich durch Mitarbeiter halt weiß dass es nicht unsere Seite ist, sondern die Daten über eine Schnittstelle weiter geleitet werden. Demzufolge würde das mit dem AJAX-Request-Nachbau schon Sinn machen, wobei mir nicht klar war, dass es so einfach sein soll, sich das nachzubilden ?!

Vielen Dank für deine Hilfe
 
Da muss ein anderer mal mitdenken. Ich bekomme im Moment noch keinen Fuß dran, wie der Mitarbeiter ohne Berechtigung die Daten abrufen kann. Wenn die Berechtigung serverseitig überprüft wird, wieso liefert der Server dann Daten an einen Unberechtigten aus? Mal ganz unabhängig was beim Client passiert oder nicht passiert oder in der Vergangenheit passiert ist. Wie wird denn die Berechtigung serverseitig überprüft? Liefert der Request Anmeldename und Passwort in hidden Feldern mit oder wie genau ist das derzeit implementiert?
 
Also :)
Mitarbeiter A kann die Daten nicht abrufen. Mitarbeiter A kennt aber Mitarbeiter B und der kann und darf das. Also setzen sich Beide zusammen an den Rechner von Mitarbeiter B und schon hat/sieht Mitarbeiter A alles Nötige. Mitarbeiter B denkt sich wahrscheinlich nicht mal was dabei und kommt gar nicht erst auf den Gedanken dass Mitarbeiter A Interesse am Quellcode hat.

Das die Beide zusammen am Rechner im Büro sitzen ist nicht unüblich, da gewisse Sachen abgesprochen werden müssen .. das heisst aber nicht dass die sich dann einfach den Quellcode rauspicken dürfen, um den anderweitig zu nutzen .. und genau das ist passiert.

Das mit den Berechtigungen hätte ich gar nicht erwähnen sollen, da das anscheinend nur verwirrt. Jeder implementierte Client-Button wird anhand der Abteilung und ID serverseitig auf Gültigkeit geprüft. Ist ein Button für eine Person verboten, wird er ausgeblendet. Auch bei den Scripten ist klar definiert wer sie nutzen darf und wer nicht .. Fremdnutzung fällt sofort auf. Das ist aber echt nicht das Thema, da Mitarbeiter A den Link zu entsprechender Seite gar nicht sieht und sie somit nicht erst aufrufen kann. Ich seh ja auch dass er das nicht macht und auch kein Anderer ohne Berechtigung.
Das Problem ist dass sich Mitarbeiter A über Mitarbeiter B den Quellcode besorgt und diesen nachgebaut hat und somit nun die Daten angezeigt bekommt .. und genau das muß ich ändern.
 
xoli schrieb:
Mitarbeiter A über Mitarbeiter B den Quellcode besorgt und diesen nachgebaut hat und somit nun die Daten angezeigt bekommt .. und genau das muß ich ändern.
Zum Vergrößern anklicken....
Und genau das ist der Knackpunkt. Dann gibt es also doch keine serverseitige Berechtigungsprüfung. Denn entweder benutzt Mitarbeiter A später an seinem Rechner den selben Quellcode für die Abfrage wie B, dann steckt die Berechtigung von B im Quellcode in irgendwelchen Feldern und er nutzt dann doch unbewußt die Zugangsdaten von B ohne dass B sie ihm gegeben hat. Oder es gibt keine wirkliche Berechtigungsprüfung sondern nur Buttons/Links die entweder angezeigt oder nicht angezeigt werden, das bezeichnet man aber nicht als Berechtigungsprüfung sondern höchstens als erfolglosen Versuch einer solchen ;)

Letzteres kann man durch Implementierung einer vernünftigen Prüfung am Server beheben. Ersteres nur indem man im Quellcode keine Zugangsdaten hat sondern höchstens Sessiondaten und ggf. Tokens die nur an diesem PC mit diesem einen Benutzer funktionieren, dann ist nämlich egal, wer sich den Quellcode nimmt, die Session und Berechtigung von B wird am Platz von A nicht funktionieren.

*hab das mal verschoben, weil die Frage bisher noch struktureller Natur ist*
 
Zuletzt bearbeitet:
Nicht ganz .. es gibt ein Table wo für jeden Benutzer jede Funktion deklariert ist die er nutzen darf, was dann beim Aufrufen der Funktion miteinander verglichen wird. Entweder wird der Button/Link gar nicht erst angezeigt, oder beim Aufrufen der Funktion entsprechend geblockt. Um sich Zugang zu nicht erlaubten Funktionen zu verschaffen müsste man schon Zugang zur Datenbank haben und das bezweifel ich. Bisher wurden allerdings nur die Funktionen und Scriptseiten an sich geprüft .. nicht aber die einzelnen Requests innerhalb des Scriptes was glaube ich der Knackpunkt ist, denn das wurde nachgebaut wenn ich dich richtig verstanden habe.

Sicherheit ist sicher ein Thema in dem System, aber bisher war das nicht notwendig, da es nur eine interne Software ist und auch nur uns als Firma betrifft.

Ich glaube ich bin auf dem richtigen Weg, wenn ich jedem Request einen Token anhänge, der dann serverseitig geprüft wird .. ich habe nur noch nicht ganz verstanden wie das ablaufen soll. Es wäre wirklich super wenn mir mal jemand in kurzen Stichpunkten erklären könnte WAS ich WO generieren/prüfen/einstellen muss.

Vielen vielen Dank
 
Bei mir läuft das so in Stichworten:
  • Jeder Request (wirklich JEDER, auch Ajax) übermittelt die Session-ID, damit prüfe ich serverseitig, ob die Session noch läuft
  • Bei jedem Request wird das Session Cookie überprüft und ob das Cookie mit der ID übereinstimmt, damit prüfe ich serverseitig, ob der richtige Client sowie Browser verwendet wird
  • Bei jeder Auslieferung einer Seite die einen Request enthält (egal ob Ajax oder <form>) wird vorher serverseitig zu dieser Session ein Token generiert das dieser Session fest zugeordnet ist, der Request funkioniert nur, wenn das Token übermittelt wird und zu dieser Session passt, damit verhindere ich hauptsächlich Doppelklicks und nebenbei ist es eine zusätzliche Sicherheit zur Session
  • Nirgendwo - außer im Loginforumlar und das ist eine https Seite - tauchen im Datenverkehr oder auf dem Client Zugangsdaten auf, damit verhindere ich, dass jemand über den Quelltext an Zugangsdaten kommt
  • Am Client läuft grundsätzlich garnichts bezüglich Sicherheit außer der Speicherung des Cookies, damit verhindere ich, dass durch manipulierte Clients oder fehlende Funktionen sich Berechtigungen erschlichen werden können
 
@mikdoe: warum überträgst du die Session-ID in GET oder POST, wenn sie sowieso schon mit dem Cookie übertragen wird?
 
Weil ich für Ausnahmefälle auch Requests ohne Cookie zulasse. Das kann ich dynamisch steuern für Sonderfälle.
 
Nee, ob die Session noch gültig ist will ich ja trotzdem prüfen. Aber um den Request z.B. aus einem anderen Browser zuzulassen kann ich die Cookieprüfung steuern.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben