Author Topic: Sicherheitskonzept WebsiteBaker  (Read 651 times)

Offline solo2219

  • Posts: 43
  • Gender: Male
Sicherheitskonzept WebsiteBaker
« on: March 26, 2017, 10:35:27 AM »
Hallo zusammen,

Die Struktur der Homepage ist eigentlich ganz klassisch. Für den „Geschlossenen Bereich“ habe ich ein eigenes Verzeichnis erstellt.

Der Zugang zur Homepage ist über die Benutzerverwaltung von WebsiteBaker organisiert.

1. Öffentlicher Bereich
2. Vereinsmitglieder (mit Anmeldung und Passwort)
3. Vorstand (mit Anmeldung und Passwort)

Das funktioniert auch im Prinzip.
Jetzt kommt aber die Beschwerde, dass Dokumente und einzelne Seiten aufgerufen werden können , wenn die URL bekannt ist. Auch Google findet Seiten und Dateien aus dem Geschlossenen Bereich.

Ich selbst bin kein Fachmann und bin nun auf Eure Hilfe angewiesen.

Was ich im Prinzip verstanden habe ist, dass es eine Möglichkeit des Schutzes über „.htaccess“ möglich sein soll. Nur wie verträgt sich die Steuerung  über die „.htaccess“ mit der Benutzerverwaltung von WebsiteBaker? Erschwerend kommt noch dazu, dass ich zwar alle Benutzernamen kenne aber nicht die Passwörter (die können ja selbstständig geändert werden).

Für eine praktische Lösung wäre  ich sehr dankbar.

Gruß Harald

Offline johnbroeckaert

  • Posts: 184
  • Gender: Male
Re: Sicherheitskonzept WebsiteBaker
« Reply #1 on: March 26, 2017, 11:14:33 AM »
You could consider to ad the following line in your temlplate:


You can use a special HTML <META> tag to tell robots not to index the content of a page, and/or not scan it for links to follow.

For example:

Code: [Select]
<html>
<head>
<title>...</title>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
</head>
There are two important considerations when using the robots <META> tag:

    robots can ignore your <META> tag. Especially malware robots that scan the web for security vulnerabilities, and email address harvesters used by spammers will pay no attention.
    the NOFOLLOW directive only applies to links on this page. It's entirely likely that a robot might find the same links on some other page without a NOFOLLOW (perhaps on some other site), and so still arrives at your undesired page.
It is a happy talent to know how to play!

Offline jacobi22

  • Posts: 5735
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitskonzept WebsiteBaker
« Reply #2 on: March 26, 2017, 02:06:02 PM »
Mit Verlaub: das Kind ist bereits in den Brunnen gefallen. Nun helfen nur noch radikale Maßnahmen, denn einmal drin im System, bekommst du das ganz schlecht bis garnicht wieder heraus  :oops: :oops:

Was möchte ich erreichen?
öffentliche Seiten sollen von den Suchmaschinen indiziert werden??

NEIN:
hier hilft nur ein Verzeichnisschutz über .htaccess/.htpasswrd
alles andere wie meta-Tags, robots.txt wirkt unterstützend, bietet aber null Sicherheit

JA:
Grundsätzlich sollte ein Robot auf einer passwortgeschützten Seite wohl den Meta-Bereich und den Link scannen können, jedoch nicht den Inhalt der eigentlich geschützten Seite, denn auch der Robot hat keine Zugangsdaten. Heißt: er holt sich page_description, page_keywords, page_title, was eben so im head-Bereich steht - das war's
War die Seite, die hinter der Anmeldung steckt, mal stundenweise öffentlich, hat ein Robot auch den Inhalt. Ich habe nur eine kleine Seite mit wenig Inhalt, aber ein Robot ist immer da.

Ich würde erstmal prüfen, was denn im Web bekannt ist. Ist da wirklich der Inhalt einer vorher geschützten Seite oder nur deren Login?

Die radikalen Maßnahmen.....
Will man wirklich, das der Link zur Seite vom Hans, wo man dann eh nur mit Passwort weiter kommt, nicht mehr gültig ist, hilft jetzt nur noch ein geschützter Bereich in einem sicheren Unterordner. Heißt: ein mit .htaccess/.htpasswrd geschützter Unterordner, in dem ein CMS deiner Wahl läuft. In diesem CMS baust du alles nocheinmal nach, was bei dir jetzt mit Passwort geschützt ist. Ginge am einfachsten mit einer Kopie des vorhandenen WB mit umbenennen aller TABLE-PREFIX, dann wieder einspielen und den Rest online korrigieren. In CMS1 nimmt man alle Links zu registrierten Seiten heraus, idealerweise gleich als kompletten Level, im geschütztem CMS2 dann den öffentlichen Hauptbereich.
Im öffentlichem CMS bleiben am Ende die Links zu den registrierten Seiten über. Hier mußt du über den Menüaufruf so eingreifen, das die geschützten Seiten dort nicht mehr auftauchen. Suchmaschinen scannen grundsätzlich das Menü und arbeiten sich dann Link für Link vor. Gleiches gilt für Links im Content, ist ein Link vorhanden, folgt der Robot diesem. Hauptaufgabe ist es also, alles, was nicht in den Suchmaschinen zu finden sein soll, vor dem Zugriff zu schützen. Da dies bisher nicht passiert ist, bleibt dir nur noch, nach dem Zugriff durch Schutz zu reagieren.

Alle im aktuellem Haupt-WB enthaltenen Links zu registrierten Seiten fängt man über eine .htaccess ab. Alle Links, die im Web vorhanden sind, wirst du nicht mehr rausbekommen. In Google-Webmastertools kann man wohl Seiten manuell entfernen, aber Google ist nur eine von tausenden Suchmaschinen. Das einzige, was auf die Dauer (und da spreche ich von Jahren) hilft, ist die Seiten ins Leere laufen zu lassen, ein 301er Redirekt auf deine öffentliche Startseite.

Für Dokumente gilt das gleiche. Alles, was nicht öffentlich ist, gehört in einen .htaccess-geschützten Ordner, die Links laufen alle über ein Addon (wie Download-Gallery), das verschlüsselte Links heraus gibt, idealerweise noch zeitlich begrenzt und nur einmal gültig. Und hier gilt das gleiche: alles, was bereits im Web vorhanden ist als Links, muß man ins Leere laufen lassen.

Was du zu allererst brauchst, ist ein Konzept. Ich würde mir in WB ein Addon wie Sitemap nehmen, das so anpassen, das ich jede Seite angezeigt bekomme, auch Sichtbarkeit privat und registriert. Das druck ich mir als Seitenbaum aus.
Dann mach ich mir ein paar Sicherheitsstufen, denen ich Farben zuordne, z.b. Grün für öffentlich, gelb für registriert/nur per Login erreichbar, rot - top secret. Dann gehts ans Malen. Das gleiche machst du für deine Dokumente.

Grundsätzlich würde ich auch mal drüber nachdenken, ob Sachen, die soooooooooo geheim sind, auch ins Web gestellt werden sollten. Ist es wirklich so geheim, empfehle ich eine Sicherheitsfirma.
Den Link zum Kunden-Login meiner örtlichen Sparkasse finde ich in jeder Suchmaschine, aber was im Kundenbereich zu sehen ist, nicht. Und hier muß deine/eure  Analyse beginnen. Die Information, das z.b. Hans, Peter und Paul im Vereinsvorstand sitzen, finde ich in jedem Vereinsregister, das muß auch öffentlich zugänglich sein. Von daher wäre die Frage, ob ein Link in einer Suchmaschine zur Unterseite von Hans, Peter oder Paul, wo man hinterher ohne Login nicht weiter kommt, wirklich schädlich ist, schon ein wichtiger Punkt, der dein weiteres Vorgehen bestimmt.

Vorausgesetzt, die Suchmaschine hat auch nur den Link zu einer geschützten Seiten und nicht deren eigentlich geschützten Inhalt....
Mitunter hilft auch ein Gespräch mit mit den Beschwerdeführern und die Frage, was denn daran so schädlich wäre und auch, was die Folgen sind, z.b. das sich für jedes Mitglied nun neue Links ergeben, sie sich neu registrieren müssen, ein zweites Login in den htaccess-geschützten Bereich haben usw


P.S.: kann es sein, das wir das gleiche Gespräch vor 3,4 Jahren schon mal geführt haben?  :wink:

Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline solo2219

  • Posts: 43
  • Gender: Male
Re: Sicherheitskonzept WebsiteBaker
« Reply #3 on: March 26, 2017, 05:09:23 PM »
Mit Verlaub: das Kind ist bereits in den Brunnen gefallen. Nun helfen nur noch radikale Maßnahmen, denn einmal drin im System, bekommst du das ganz schlecht bis garnicht wieder heraus  :oops: :oops:

Das hatte ich schon befürchtet.


Alle im aktuellem Haupt-WB enthaltenen Links zu registrierten Seiten fängt man über eine .htaccess ab. Alle Links, die im Web vorhanden sind, wirst du nicht mehr rausbekommen. In Google-Webmastertools kann man wohl Seiten manuell entfernen, aber Google ist nur eine von tausenden Suchmaschinen. Das einzige, was auf die Dauer (und da spreche ich von Jahren) hilft, ist die Seiten ins Leere laufen zu lassen, ein 301er Redirekt auf deine öffentliche Startseite.

Für Dokumente gilt das gleiche. Alles, was nicht öffentlich ist, gehört in einen .htaccess-geschützten Ordner, die Links laufen alle über ein Addon (wie Download-Gallery), das verschlüsselte Links heraus gibt, idealerweise noch zeitlich begrenzt und nur einmal gültig. Und hier gilt das gleiche: alles, was bereits im Web vorhanden ist als Links, muß man ins Leere laufen lassen.


Das wird wahrscheinlich dann die einfachste Möglichkeit sein - neue Verzeichnisstruktur und Absicherung durch .htaccess


Grundsätzlich würde ich auch mal drüber nachdenken, ob Sachen, die soooooooooo geheim sind, auch ins Web gestellt werden sollten. Ist es wirklich so geheim, empfehle ich eine Sicherheitsfirma.

Nicht doch. So geheim sind die Dokumente nun auch wieder nicht. Nur ändert sich die Befindlichkeit und das Sicherheitsbedürfni s des Vorstands nach jeder Vorstandswahl (vor allem, wenn das Personal wechselt).


Vorausgesetzt, die Suchmaschine hat auch nur den Link zu einer geschützten Seiten und nicht deren eigentlich geschützten Inhalt....
Mitunter hilft auch ein Gespräch mit mit den Beschwerdeführern und die Frage, was denn daran so schädlich wäre und auch, was die Folgen sind, z.b. das sich für jedes Mitglied nun neue Links ergeben, sie sich neu registrieren müssen, ein zweites Login in den htaccess-geschützten Bereich haben usw

Ich werde ein zweites Login machen - trifft dann nur die Mitglieder des Vorstands.
Eigentlich hatte ich die Hoffnung, dass die .htaccess mit den Passwörtern der Mitglieder (WB) zusammenarbeitet - wird wohl nicht funktionieren.

P.S.: kann es sein, das wir das gleiche Gespräch vor 3,4 Jahren schon mal geführt haben?  :wink:

Ist mir jetzt nicht so bewusst. Du hast mir zwar schon mal geholfen - aber da waren andere Themen im Spiel.

Trotzdem Danke für Deine Hilfe  :-)

Gruß Harald

Offline jacobi22

  • Posts: 5735
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Sicherheitskonzept WebsiteBaker
« Reply #4 on: March 26, 2017, 06:22:59 PM »
Eigentlich hatte ich die Hoffnung, dass die .htaccess mit den Passwörtern der Mitglieder (WB) zusammenarbeitet - wird wohl nicht funktionieren.
Nein, geht garnicht
wenn ich das recht im Kopf habe, sind es sogar unterschiedliche Verschlüsselungsalg orithmen. Diese .htaccess-Variante arbeitet entweder mit einer .htpasswrd oder einer .htuser zusammen, erstere für nur ein gemeinsames Passwort im gesamten Ordner, zweite für eine Userliste mit unterschiedlichen Passwörtern. Zum Generieren gibt es diverse Tools, die je nach Ausstattung auch mehrere Verschlüsselungsalg orithmen anbieten, z.b. sha1, md5 usw

Wenn es dein Ziel ist, die Unterseiten der Vereinsführung nicht indizieren zu lassen, mache den Login eine Ebene höher, z.b. so

--Home (öffentlich)
-- Seite 1 (öffentlich)
-- seite 2 (öffentlich)
-- Unser Verein (öffentlich)
-- Vereinsführung (registriert)
---- Chef 1  (besser registriert)
---- Chef 2  (besser registriert)

Der login würde dann genauso laufen, nur eine Ebene höher. Passwortänderung etc nicht nötig

Der Robot würde die Seite Vereinsführung wohl einlesen bis zum Login-Formular, aber nicht mehr die darunterliegenden Seiten. Man darf natürlich nirgens auf diese Unterseiten (Chef1 & Chef 2) direkt verlinken, sonst war das für die Katz.

Quote
Nur ändert sich die Befindlichkeit und das Sicherheitsbedürfni s des Vorstands nach jeder Vorstandswahl
wie vorhin schon gesagt, ein Verein hat auch die Pflicht, diese Vorstandsdaten öffentlich zu präsentieren. In wie fern da dann der link zu einer privaten Seite mit Loginfenster böse sein soll, verstehe ich nicht, muß ich aber auch nicht  ;-)

Wichtig ist, das nicht etwa der Inhalt solch einer Seite mit Sichtbarkeit "registriert" in den Suchmaschinen zu finden ist. Ich hatte schon mal ein 15-Seiten-Projekt 26 Minuten nach der Freischaltung und Anmeldung bei Google mit allen Unterseiten in den Google-Suchergebnissen, sicher eher Zufall, weil der Robot grad in dem Moment da war, soll aber zeigen, das der nur Minuten zum Scannen benötigt, wenn die Seite mal frei zugänglich ist (z.b. beim Erstellen des Projekts zur Voransicht)
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

 

postern-length