Welche weiteren (auch unsinnigen) Methoden von Zugriffsbeschränkungen kennt ihr?
Felix Riesterer
- programmiertechnik
- selfhtml-wiki
- webserver
Liebe Mitlesende,
ich hatte gerade Lust den Artikel zu den Grundlagen der Zugriffsbeschränkung zu überarbeiten. Dabei habe ich die bisherigen Inhalte durch diese Struktur neu gegliedert:
Fallen irgendwem noch weitere Beispiele konzeptioneller Art ein, die man in den Artikel aufnehmen sollte?
Liebe Grüße,
Felix Riesterer.
Servus!
Liebe Mitlesende,
ich hatte gerade Lust den Artikel zu den Grundlagen der Zugriffsbeschränkung zu überarbeiten.
Vielen Dank, wieder ein ToDo weniger!
Herzliche Grüße
Matthias Scharwies
Hallo,
ich hatte gerade Lust den Artikel zu den Grundlagen der Zugriffsbeschränkung zu überarbeiten. Dabei habe ich die bisherigen Inhalte durch diese Struktur neu gegliedert:
- Deeplinks
- HTTP-Auth
- Session-basiert
- Unsinn
Fallen irgendwem noch weitere Beispiele konzeptioneller Art ein, die man in den Artikel aufnehmen sollte?
als potentiell unwirksam hätte ich noch:
So long,
Martin
Lieber Martin,
als potentiell unwirksam hätte ich noch:
- Referrer-Check
- Captcha
ach ja... Wie macht man einen Referrer-Check, wenn nicht mit einer serverseitigen Script-Sprache? Geht das auch ohne PHP/Perl/Ruby etc.?
Zu Captchas sollte schon etwas im Wiki stehen, darauf könnte ich im Artikel noch Bezug nehmen.
Vielen Dank für Deine Vorschläge!
Liebe Grüße,
Felix Riesterer.
Hallo,
- Referrer-Check
- Captcha
ach ja... Wie macht man einen Referrer-Check, wenn nicht mit einer serverseitigen Script-Sprache? Geht das auch ohne PHP/Perl/Ruby etc.?
ist das jetzt eine höhnische Bemerkung im Sinn von "ist doch bereits abgedeckt"?
Falls nein: Natürlich geht das nur mit einer serverseitigen Sprache - angefangen mit der Webserver-Konfiguration (.htaccess) bis hin zu direkten Abfragen der HTTP-Header z.B. mit PHP. Ich wolle das nur als konkreten Fall erwähnen.
Zu Captchas sollte schon etwas im Wiki stehen, darauf könnte ich im Artikel noch Bezug nehmen.
Ah, gut. Ich habe nicht konkret danach gesucht.
So long,
Martin
Lieber Martin,
ist das jetzt eine höhnische Bemerkung im Sinn von "ist doch bereits abgedeckt"?
NEIIIN!! Das war "auf dem falschen Fuß erwischt". HTTP_AUTH lässt sich rein über die Serverkonfiguration lösen (.htaccess). Dein Vorschlag hatte sich so angehört, als wäre der Referrer-Check auch darüber möglich (was mir neu gewesen wäre). Irgendwie wollte mir das spontan nicht einleuchten.
Falls nein: Natürlich geht das nur mit einer serverseitigen Sprache - angefangen mit der Webserver-Konfiguration (.htaccess) bis hin zu direkten Abfragen der HTTP-Header z.B. mit PHP. Ich wolle das nur als konkreten Fall erwähnen.
Wenn ich das mit einer serverseitigen Scriptsprache löse, wozu dann noch .htaccess?
Zu Captchas sollte schon etwas im Wiki stehen, darauf könnte ich im Artikel noch Bezug nehmen.
Ah, gut. Ich habe nicht konkret danach gesucht.
Das steht dort ja auch unter Webstandards/Benutzerfreundlichkeit_und_Barrierefreiheit und nicht unter Zugangsbeschränkungen.
Nach wie vor herzlichen Dank für Deine Vorschläge und Ergänzungen.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
ist das jetzt eine höhnische Bemerkung im Sinn von "ist doch bereits abgedeckt"?
NEIIIN!! Das war "auf dem falschen Fuß erwischt". HTTP_AUTH lässt sich rein über die Serverkonfiguration lösen (.htaccess). Dein Vorschlag hatte sich so angehört, als wäre der Referrer-Check auch darüber möglich (was mir neu gewesen wäre).
Ist er ja auch. Beispiel für Apache:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !example.org
RewriteRule .* - [F,L]
NGinx hat sogar (beschränkte) Scripting-Möglichkeiten in der Konfiguration.
LG,
CK
Moin Felix,
ist das jetzt eine höhnische Bemerkung im Sinn von "ist doch bereits abgedeckt"?
NEIIIN!! Das war "auf dem falschen Fuß erwischt".
na gut, dann hab ich da wohl etwas rausgelesen, was so gar nicht gemeint war.
HTTP_AUTH lässt sich rein über die Serverkonfiguration lösen (.htaccess). Dein Vorschlag hatte sich so angehört, als wäre der Referrer-Check auch darüber möglich (was mir neu gewesen wäre).
Ist es ja auch, wie Christian mittlerweile an einem Beispiel gezeigt hat.
Falls nein: Natürlich geht das nur mit einer serverseitigen Sprache - angefangen mit der Webserver-Konfiguration (.htaccess) bis hin zu direkten Abfragen der HTTP-Header z.B. mit PHP. Ich wolle das nur als konkreten Fall erwähnen.
Wenn ich das mit einer serverseitigen Scriptsprache löse, wozu dann noch .htaccess?
Nicht "auch noch", sondern alternativ. Über eine Direktive in der .htaccess kann ich einen Referrer-Check auch dann realisieren (Apache vorausgesetzt), wenn ich sonst gar keine Scriptsprache einsetze. Ich kann damit auch den direkten Zugriff auf "dumme", statische Ressourcen einfach abfangen.
So long,
Martin
Moin Moin,
- Deeplinks
Ich halte diese Aussage für falsch.
Die Idee hinter diesem Begriff ist die, dass die Internetadresse zu gewissen Inhalten von nirgendwo her verlinkt ist und auch nicht über Suchmaschinen gefunden werden kann, also eine Art Geheimnis darstellt.
Die Deeplinks werden auch ganz gezielt eingesetzt um den Besucher direckt auf den gewünschten Seiteninhalt zu schicken, ohne lästiges durchhangeln. Auch zeigen manche Suchmaschinen durchaus Deeplinks zu den Seiteninhalten an. Mit verstecken und Geheimnis hat dies überhaupt nichts zu tun.
Eine Kategorisierung von Links liegt auch an der juristischen Diskussion rund um die Fragen zur Haftung von Hyperlinks. Hotlinks sind auch eine Form der Deeplinks.
Fallen irgendwem noch weitere Beispiele konzeptioneller Art ein, die man in den Artikel aufnehmen sollte?
Einfallen ja, ob aufnehmen?
Man kann Secure-Links auch zum eingeschränktem Seitenbesuch missbrauchen. Ein URL-Shortnermechanismus auf der eigenen Seite kann auch zum Beschränken genutzt werden.
Hallo Felix,
außer den Schlangenöl-Methoden nennst du zwei grundsätzliche Ansätze: Zugriffschutz per Zugriffsrecht auf Files und Directories (die Apache mit .htaccess abbildet), und ein Formularlogin mit Session und Webapplication im Hintergrund. Ist die Welt damit tatsächlich abgedeckt? Weitere Schlangenöl-Methoden sollte man nicht bringen, und dann fällt mir für das Szenario "Webseite im Internet" auch nichts weiter ein. Insofern ist dein Artikel gut, wenn man diesen Scope im Auge hat. Es gibt aber noch mehr auf der Welt.
In Intranets sind durchaus Alternativen möglich, weil es dort Mechanismen wie NTLM, Kerberos oder Radius gibt (was ich leider nur als Stichwort auf den Boden der Tatsachen kübeln kann, ich bin kein Admin und kenne keine Details. Wie das in Unix/Linux läuft, weiß ich auch nicht). Aus meiner täglichen Arbeit weiß ich aber, dass ich eine Webseite, die auf einem IIS gehostet ist, mit NTLM authentifizieren kann - das ist ein Windows-only Mechanismus, der in einem Intranet dafür sorgt, dass Server und Brauser den Login unter der Haube aushandeln. Meine IIS Application kennt dann die User-ID des Nutzers. Und ich kann auf dem Server über Dateirechte steuern, wer auf das Web zugreifen kann. Kerberos ist eine Obermenge davon und nicht auf Windows beschränkt, und Radius ist ein Standardverfahren für Systeme, in die man sich von außen einwählt. Gehört sowas nicht irgendwie zumindest erwähnt? Ich würde ja einen Textvorschlag machen, wenn ich mehr wüsste als die Stichworte.
Sodann hätte ich ein paar Korinthen zu kacken ;-)
Deep Link - ich schließe mich da "Kay nicht angemeldet" an. Zumindest bist Du im Konflikt mit der Wikipedia: Deep Link ist das Gegenteil von Surface Link (also http://forum.selfhtml.org vs https://forum.selfhtml.org/meta/2016/may/15/welche-weiteren-auch-unsinnigen-methoden-von-zugriffsbeschraenkungen-kennt-ihr) und stellt eine Seite dar, zu der man von der Startseite aus erstmal hinnavigieren muss.
Da Du den Begriff eingebracht hast, läge es nun an Dir, eine Quelle zu benennen, die den Begriff so definiert, wie Du ihn nutzt.
Meine Versuche, konstruktiv beizutragen, sind leider nicht gelungen. Was Du meinst, würde ich analog zum Dark Internet eine Dark Page nennen wollen. Allerdings habe ich keine reputable Quelle, dass der Begriff für diesen Einsatzzweck wirklich korrekt ist und das ist schwierig zu googeln wegen Star Trek Next Generation, Staffel 7, Folge 7, "Dark Page" :). Abgesehen davon ist eine "Dark Site" eine Website, die offline ist und nur bedarfsweise online geht. Also vielleicht doch kein guter Begriff.
"Isolated Page" klänge auch gut, ist aber anders belegt (->Chromium Isolated Site).
Authentification ist französisch, die Engländer sprechen von Authentication. Auf deutsch dann wieder Authentifizierung.
Mit deiner Kommasetzung gehe ich auch nicht konform, aber ich fühle mich zu alt, um die neue Rechtschreibung noch richtig zu lernen, insofern mag meine Kommaflut falsch sein und dein Text richtig.
Gruß Rolf
Tach!
In Intranets sind durchaus Alternativen möglich, weil es dort Mechanismen wie NTLM, Kerberos oder Radius gibt (was ich leider nur als Stichwort auf den Boden der Tatsachen kübeln kann, ich bin kein Admin und kenne keine Details.
NTLM ist nur eine anderes Verfahren bei der Authentifizierung, so wie Basic Auth eine ist. Eine weitere nennt sich Digest Access Authentication. Kerberos und Radius sind Verfahren, die im Hintergrund auf dem Server in Richtung Domäne oder zentralem Anmeldeserver Anwendung finden. Sie haben mit einer Anmeldung übers Web nichts zu tun und sind Alternativen zur Verwaltung von Logininformationen in Dateien auf dem Webserver selbst (zum Beispiel .htpassword).
Wie das in Unix/Linux läuft, weiß ich auch nicht.
Auch die können das. Das NTML-Verfahren ist bekannt und die erwähnten Hintergrund-Verfahren kann Linux/Unix auch.
Aus meiner täglichen Arbeit weiß ich aber, dass ich eine Webseite, die auf einem IIS gehostet ist, mit NTLM authentifizieren kann - das ist ein Windows-only Mechanismus,
Es gibt Module für den Apachen, die NTLM auf Unix-Plattformen implementieren.
dedlfix.
Lieber Rolf,
außer den Schlangenöl-Methoden nennst du zwei grundsätzliche Ansätze: Zugriffschutz per Zugriffsrecht auf Files und Directories (die Apache mit .htaccess abbildet), und ein Formularlogin mit Session und Webapplication im Hintergrund.
ja, die Schlangenöl-Methoden waren schon da, als ich den Artikel zu überarbeiten anfing. Von mir aus kann auch eine generische Ankündigung "Lösungen mit JavaScript sind schlicht Schlangenöl" als Ersatz genügen.
Ist die Welt damit tatsächlich abgedeckt?
Wenn ich @dedlfix richtig verstanden habe, ja. Was Intranet-Lösungen angeht, so fehlt es mir da schlicht an Erfahrungen und Kenntnissen. Man kann in Intranets vielleicht IP-basierte Authentifikationen nutzen, weil man im Intranet weniger IP-Spoofing erwartet... Aber solche Fragen überlasse ich dann lieber Profis, die für Intranets Lösungen erstellen. Für den Hobbyisten, der an seiner Website schraubt, sollte der Artikel hoffentlich verständlich und hilfreich sein.
Sodann hätte ich ein paar Korinthen zu kacken ;-)
Ich liebe Rosinen.
- Deep Link - [...] Da Du den Begriff eingebracht hast, läge es nun an Dir, eine Quelle zu benennen, die den Begriff so definiert, wie Du ihn nutzt.
Es liegt an mir, einen anderen Begriff zu verwenden und das Wort "Deeplink" damit zu ersezten. Im Grunde meine ich damit "geheime URLs". Fällt das bereits in den Bereich "security by obscurity"? Das englische obscure träfe es ja gut.
- Authentification ist französisch, die Engländer sprechen von Authentication. Auf deutsch dann wieder Authentifizierung.
Ja, da gehe ich noch einmal drüber.
- Mit deiner Kommasetzung gehe ich auch nicht konform, aber ich fühle mich zu alt, um die neue Rechtschreibung noch richtig zu lernen, insofern mag meine Kommaflut falsch sein und dein Text richtig.
Hehehe. Da darf man gerne korrigieren.
Liebe Grüße,
Felix Riesterer.
Es liegt an mir, einen anderen Begriff zu verwenden und das Wort "Deeplink" damit zu ersezten
[X] done.
Liebe Grüße,
Felix Riesterer.
Es liegt an mir, einen anderen Begriff zu verwenden und das Wort "Deeplink" damit zu ersezten [X] done.
Security by Obscurity ist hier auf jeden Fall der richtige Begriff :)
Gruß Rolf
Hej Felix,
Sodann hätte ich ein paar Korinthen zu kacken ;-)
Ich liebe Rosinen.
Wenn man damit Geld machen kann, kacke ich Dir so viel du willst...
SCNR
Marc