Darum Schreibaktionen nicht mit GET ausführen
dedlfix
Darum Schreibaktionen nicht mit GET ausführen
dedlfix
Rolf B
TS
Matthias Apsel
MudGuardTach!
Gerade in den News https://twitter.com/wernermue/status/999377665126682624. Die Antivirensoftware folgt Links in Emails und nimmt so eine Anmeldung zum Email-Marketing vor, inklusive Zweit-Email mit Bestätigungslink.
Sowas passiert unter anderenm, wenn man Schreiboperationen bei GET ausführt. Da hilft auch nicht, dass man eine Bestätigungsmail schickt, in der auch noch ein Link angeklickt werden muss.
Mal ganz abgesehen davon, dass die AV-Software nicht von sich aus irgendwelchen Müll aufzurufen hat. Es sollte sich herumgesprochen haben, dass in Emails oftmals personalisierte Links enthalten sind, und man durch den Aufruf eine Bestätigung der Existenz der Email-Adresse gibt. Naja, die AV-Software will vermutlich auch in Zukunft eine Daseinsberechtigung haben und schafft sie sich selbst.
dedlfix.
-
hallo
Mal ganz abgesehen davon, dass die AV-Software nicht von sich aus irgendwelchen Müll aufzurufen hat.
hmm, du willst der Scareware ihr Futter vorenthalten?
Es sollte sich herumgesprochen haben, dass in Emails oftmals personalisierte Links enthalten sind, und man durch den Aufruf eine Bestätigung der Existenz der Email-Adresse gibt. Naja, die AV-Software will vermutlich auch in Zukunft eine Daseinsberechtigung haben und schafft sie sich selbst.
Was ja generell nicht sicher ist. Man denke etwa an das Freischalten eines neu zu erstellenden Accounts. Da sollen die personenbezogenen Daten eben NICHT via Email verschickt werden, sondern der alleinige Zweck besteht darin, eine Mailbox als dem Accountersteller zugehörig zu verifizieren, und nebenbei Bot-Accounts zu minimieren.
--
Neu im Forum! Signaturen kann man ausblenden! -
Lieber dedlfix,
Gerade in den News https://twitter.com/wernermue/status/999377665126682624.
davon hatte ich schon gelesen.
Sowas passiert unter anderenm, wenn man Schreiboperationen bei GET ausführt. Da hilft auch nicht, dass man eine Bestätigungsmail schickt, in der auch noch ein Link angeklickt werden muss.
Wenn man eine HTML-Email verschickt (grusel), in welcher man ein Formular einbaut, in dem der "Link" in Wirklichkeit ein Button ist, könnte man einen POST-Request auslösen. In Plain/Text geht das aber nicht.
Schlägst Du vor, dass man auf einer so erreichten Website dann einen solchen Button noch implementiert, der den tatsächlichen Schreibvorgang auslöst? Also dem Nutzer einen Klick mehr zumutet?
Mal ganz abgesehen davon, dass die AV-Software nicht von sich aus irgendwelchen Müll aufzurufen hat.
Das ist unbestritten.
Es sollte sich herumgesprochen haben, dass in Emails oftmals personalisierte Links enthalten sind, und man durch den Aufruf eine Bestätigung der Existenz der Email-Adresse gibt. Naja, die AV-Software will vermutlich auch in Zukunft eine Daseinsberechtigung haben und schafft sie sich selbst.
Hoffentlich gibt es dafür einen Schalter?
Liebe Grüße,
Felix Riesterer.
-
Tach!
Schlägst Du vor, dass man auf einer so erreichten Website dann einen solchen Button noch implementiert, der den tatsächlichen Schreibvorgang auslöst? Also dem Nutzer einen Klick mehr zumutet?
Der eine Klick muss es dem Nutzer wert sein.
Ob und inwieweit man sich auf Javascript als Unterscheidungsmerkmal zwischen Bots und Browsernutzern einlassen möchte, kann man auch noch in die Waagschale werfen.
Generell muss man sich als Betreiber die Frage stellen, ob man möchte, dass Automaten Links verfolgen und dabei Aktionen auslösen, oder ob das kleinere Übel ein zusätzlicher Klick ist.
dedlfix.
-
-
hi,
Warum nicht? Wenn Parameter im QueryString Schreibaktionen auslösen, dann ist das so und da hat sich der Enwickler bestimmt was dabei gedacht. Stell Dir vor, Du hast eine Tabelle im Browser und für jede Zeile gibt es eine Löschoption. Soll denn da für jede Zeile ein Formular+Submit-Button in den Browser gerendert werden nur, damit das Löschen eine POST-Aktion wird?
Da wird ein
delete=idgesetzt und fertig ist der Lack. Natürlich mit Rückfrage nach vorheriger Authorization. Wenn die Sicherheit darin bestehen würde, das Versenden solcher URLs per Email zu vermeiden, wäre das je geradezu idiotisch. Ebensowenig ist Sicherheit eine Frage der Requestmethode. Das war sie noch nie!MfG
-
Tach!
Warum nicht? Wenn Parameter im QueryString Schreibaktionen auslösen, dann ist das so und da hat sich der Enwickler bestimmt was dabei gedacht.
Natürlich, es macht ja auch nie jemand Fehler bei dem, was er sich da ausdenkt.
Stell Dir vor, Du hast eine Tabelle im Browser und für jede Zeile gibt es eine Löschoption. Soll denn da für jede Zeile ein Formular+Submit-Button in den Browser gerendert werden nur, damit das Löschen eine POST-Aktion wird?
Da wird ein
delete=idgesetzt und fertig ist der Lack.Dann kommt der Bot vorbei, folgt allen Links, und weg ist der Lack.
Du kannst auch ein Formular für alles nehmen, statt je ein Formular, wenn du etwas sparen möchtest. Andererseits kann der Link auch zu einer Bestätigung führen, die erst dann den POST-Request auslöst. Hauptsache, der einfache Link führt sie nicht direkt aus.
Natürlich mit Rückfrage nach vorheriger Authorization. Wenn die Sicherheit darin bestehen würde, das Versenden solcher URLs per Email zu vermeiden, wäre das je geradezu idiotisch.
Die Idiotie ist, Links mit Schreiboperation zu verbreiten, statt eine Schreibbestätigung per POST-Request einzubauen. Als zweiten Schritt beispielweise. Der verbreitete Link führt auf das Formular, da kann der Nutzer vielleicht auch nochmal sehen, was da über ihn gespeichert werden soll, und dann gehts per POST-Request zur eigentlichen Schreibaktion.
Ebensowenig ist Sicherheit eine Frage der Requestmethode. Das war sie noch nie!
Es gibt aber Requestmethoden, die real existierenden Bedingungen unterliegen. Beispielweise die, dass Links, deren Ziel üblicherweise mit GET aufgerufen wird, ungefragt und ohne Beachtung der Aktion, die dabei ausgelöst wird, von Bots verfolgt werden. Seien es Suchmaschinenbots oder auch Link-Checker, mit denen man in seinem eigenen Angebot tote Links aufspüren möchte, oder der Offline-Reader, der sich zu diesem Zweck alle verlinkten Seiten holt.
dedlfix.
-
Sicherheit war noch nie eine Frage der Requestmethode!
-
Hallo pl,
Sicherheit war noch nie eine Frage der Requestmethode!
du verwechselst Sicherheit mit best practice.
LG,
CK-
Hallo Christian,
ob GET oder POST ist keine Frage von best practice. Es geht schlicht darum, wie die Semantik der Requestmethoden definiert ist. Die RFC ist da eigentlich recht klar:
Request methods are considered "safe" if their defined semantics are essentially read-only
Und GET gehört dazu.
Rolf
--
sumpsi - posui - clusi-
Hallo Rolf,
ob GET oder POST ist keine Frage von best practice. Es geht schlicht darum, wie die Semantik der Requestmethoden definiert ist. Die RFC ist da eigentlich recht klar:
Request methods are considered "safe" if their defined semantics are essentially read-only
Und GET gehört dazu.
Die Semantik der Methoden zu befolgen ist natürlich eine best practice. Es gibt keine technische Notwendigkeit, das zu tun. Man handelt sich Nachteile ein, wenn man es nicht tut, siehe etwa OP, aber „es funktioniert“ auch wenn man es nicht tut.
Darum geht es doch bei best practices: man hält sich, auch ohne technische Notwendigkeit, an diese Praktiken, weil ein zuwiderhandeln einem starke Nachteile beschert und sich diese Praxis als die beste Vorgehensweise herausgestellt hat.
LG,
CK-
Hallo Christian,
aber „es funktioniert“
das läuft jetzt in Richtung von Gunnars "was ist bedienbar" Evangelium, aber ich würde bestreiten, dass etwas als funktionierend bezeichnet werden kann, wenn es gegen Grundprinzipien verstößt. Selbst in Anführungszeichen nicht. Zwischen best practice und Gebrauchsvorschrift ist ein qualitativer Unterschied.
Ich kann eine Zimmerbeleuchtung schalten, indem ich einen Kroko-Klemme an die Phasenleitung schraube und die Ader bei Bedarf an die Schaltleitung klemme. Das „funktioniert“. Bis jemand die Spitze der Klemme berührt, der nicht wusste, dass das bei diesem Design kein zulässiger Usecase ist.
Rolf
--
sumpsi - posui - clusi-
Hallo Rolf,
aber „es funktioniert“
das läuft jetzt in Richtung von Gunnars "was ist bedienbar" Evangelium
Ja, das ist religiös 😀
, aber ich würde bestreiten, dass etwas als funktionierend bezeichnet werden kann, wenn es gegen Grundprinzipien verstößt.
„Es funktioniert“ ist hier definiert als „es erfüllt die Anforderungen.“ Nur weil dir der Weg nicht gefällt heisst das nicht, dass es nicht funktioniert. Nach deiner Definition würde jeglicher zweckfremde/kreative Umgang mit Technologie „nicht funktionieren.“ Dass das nicht stimmt zeigt die in den letzten 10 Jahren massiv gewachsene Maker-Bewegung.
Oder, umgekehrt: es gibt (oder zumindest gab, ich glaube inzwischen ist das auch nicht mehr der Fall) im Java-Bereich ganze Frameworks, die HTTP nicht verstanden haben und, um das Caching zu umschiffen, alles via SOAP durch
POSTschleifen. Das funktioniert, auch wenn es bescheuert ist.Selbst in Anführungszeichen nicht. Zwischen best practice und Gebrauchsvorschrift ist ein qualitativer Unterschied.
Und genau da ist das Missverständnis: es gibt da keine Vorschrift, nur Empfehlungen. Wer will mich denn dazu zwingen, mich an die RFC zu halten? Es ist ja kein Gesetz, bei dessen Übertretung die Polizei vorbei kommt.
LG,
CK-
Hallo Christian,
es gibt da keine Vorschrift, nur Empfehlungen.
Hmmm. Vorschrift, Empfehlung - da ist eine Zwischenzone und die heißt Standard.
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community.Die Polizei kommt zwar nicht, aber wer Standards nicht beachtet, handelt fahrläsig (es sei denn, es gibt mehrere in Konflikt stehende). Und die HTTP Verbsemantik ist ein Standard.
Für mich waren die RfCs im Standards Track eigentlich immer das Gebetbuch des Internet.
Rolf
--
sumpsi - posui - clusi
-
-
-
-
-
-
Tach!
Sicherheit war noch nie eine Frage der Requestmethode!
Ich sehe keinen Nutzen darin, dass du diese Aussage wiederholst, ohne auszuführen, wie es denn besser gehen würde.
dedlfix.
-
Hallo dedlfix,
Sicherheit war noch nie eine Frage der Requestmethode!
Ich sehe keinen Nutzen darin, dass du diese Aussage wiederholst, ohne auszuführen, wie es denn besser gehen würde.
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.LG,
CK-
Tach!
Sicherheit war noch nie eine Frage der Requestmethode!
Ich sehe keinen Nutzen darin, dass du diese Aussage wiederholst, ohne auszuführen, wie es denn besser gehen würde.
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.Vermutlich meint er, das ein Berechtigungskonzept die notwendige Sicherheit geben soll, dass unbeabsichtigte Änderungen nicht vorgenommen werden können. Aber auch dann ist Datenändern mit GET keine gute Idee. Man kann zum Beispiel auch angemeldet Link-Checker über sein Angebot laufen lassen wollen. Oder Browser verwenden, die irgendwelches Vorab-Herunterladen betreiben. Es geht also auch darum, dass Automaten, die im Auftrag von berechtigten Nutzern unterwegs sind, möglichst keinen Schaden anrichten.
Aber abgesehen davon hätte ein Berechtigungskonzept im Falle der Anekdote im Startposting auch keine Hilfe gebracht.
dedlfix.
-
Hallo dedlfix,
Vermutlich meint er, das ein Berechtigungskonzept die notwendige Sicherheit geben soll, dass unbeabsichtigte Änderungen nicht vorgenommen werden können.
Ja, davon gehe ich auch aus.
Aber auch dann ist Datenändern mit GET keine gute Idee. Man kann zum Beispiel auch angemeldet Link-Checker über sein Angebot laufen lassen wollen. Oder Browser verwenden, die irgendwelches Vorab-Herunterladen betreiben. Es geht also auch darum, dass Automaten, die im Auftrag von berechtigten Nutzern unterwegs sind, möglichst keinen Schaden anrichten.
Ja, genau. Danke für deinen Beitrag, pl, leider hast du das Thema verfehlt und/oder das zugrundeliegende Problem nicht verstanden.
LG,
CK-
hi,
Ja, genau. Danke für deinen Beitrag, pl, leider hast du das Thema verfehlt und/oder das zugrundeliegende Problem nicht verstanden.
Doch, habe ich! Insofern ist auch der verlinkte Twitterbeitrag im Grunde genommen eine Lachnummer!
MfG
-
Hallo pl,
Ja, genau. Danke für deinen Beitrag, pl, leider hast du das Thema verfehlt und/oder das zugrundeliegende Problem nicht verstanden.
Doch, habe ich!
Warum schreibst du dann völlig am Thema vorbei?
Insofern ist auch der verlinkte Twitterbeitrag im Grunde genommen eine Lachnummer!
Ja ach! Darum ging es doch. Ein Fail auf zwei Seiten, bitte einmal grinsen und es selber besser machen.
LG,
CK -
hi,
Ja, genau. Danke für deinen Beitrag, pl, leider hast du das Thema verfehlt und/oder das zugrundeliegende Problem nicht verstanden.
Doch, habe ich! Insofern ist auch der verlinkte Twitterbeitrag im Grunde genommen eine Lachnummer!
PS: Und erst recht die Schlussfolgerung die manche Fachkräfte daraus ziehen, lächerlich!
-
-
-
-
Hello,
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.Ich bitte da mal um etweas Nachhilfe. Darf auch gerne ein wenig ausführlicher sein ;-)
Ist das wirklich so? Hat es überhaupt nichts mit Sicherheit zu tun?Wie ist das bei https und SNI? Ist der GET-Request-String da trotzdem schon verschlüsselt, auch beim initialen Aufruf der Ressource? Wie genau ist da der Ablauf?
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo TS,
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.Ich bitte da mal um etweas Nachhilfe. Darf auch gerne ein wenig ausführlicher sein ;-)
Ist das wirklich so? Hat es überhaupt nichts mit Sicherheit zu tun?Die best practice ist, dass man Schreiboperationen nicht mit
GET-Requests abhandelt, weil sonst Bots und Software (etwa Browser mit prefetch) den Links folgen.Nein, das hat nichts mit Sicherheit zu tun. Die Ressource kann ja sogar frei für jedermann und jederfrau zugänglich sein, sogar - shocking! - ohne HTTPS 😉
Wie ist das bei https und SNI? Ist der GET-Request-String da trotzdem schon verschlüsselt, auch beim initialen Aufruf der Ressource?
Das betrachtet andere Aspekte und hat nichts mit der genannten best practice zu tun.
Aber ich kann dir das gerne trotzdem beantworten: SNI ist ein Teil des TLS-Handshakes und ist in der Protokoll-Ebene unter HTTP. Der Query-String ist nicht Teil der Verhandlung, nur und ausschließlich der hostname ist Teil des Handshakes. Erst wenn der TLS-Handshake abgeschlossen ist, kommt HTTP zum Zuge.
LG,
CK-
Hello CK,
Aber ich kann dir das gerne trotzdem beantworten: SNI ist ein Teil des TLS-Handshakes und ist in der Protokoll-Ebene unter HTTP. Der Query-String ist nicht Teil der Verhandlung, nur und ausschließlich der hostname ist Teil des Handshakes. Erst wenn der TLS-Handshake abgeschlossen ist, kommt HTTP zum Zuge.
Danke.
Also ist der Request-String bei HTTPs bereits verschlüsselt. Dann kann er im Prinzip ja nur noch an den "offenen Enden" fälschlich (mehrfach) benutzt werden, was selbstverständlich nicht ausschließt, dass er - z. B. per eMail - versandt wird und das Vagabundieren beginnt.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
hallo
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.Ich bitte da mal um etweas Nachhilfe. Darf auch gerne ein wenig ausführlicher sein ;-)
Ist das wirklich so? Hat es überhaupt nichts mit Sicherheit zu tun?Die best practice ist, dass man Schreiboperationen nicht mit
GET-Requests abhandelt, weil sonst Bots und Software (etwa Browser mit prefetch) den Links folgen.Man denke einfach auch an Log-Files. (Schreiboperationen liegen IMMER vor). Man will nicht mehr Daten publizieren als unbedingt notwendig sind. Im Gegensatz zu GET muss man bei POST schon eine spezielle Dummheit begehen, dass Daten in den Logfiles landen, wo sie nicht hingehören!
Aus meiner Sicht gehören in eine URI nur Dinge, die ich sogar Google anvertrauen könnte.
--
Neu im Forum! Signaturen kann man ausblenden!-
Hello,
Man denke einfach auch an Log-Files. (Schreiboperationen liegen IMMER vor). Man will nicht mehr Daten publizieren als unbedingt notwendig sind. Im Gegensatz zu GET muss man bei POST schon eine spezielle Dummheit begehen, dass Daten in den Logfiles landen, wo sie nicht hingehören!
Das hängt aber nicht von der Applikation ab, sondern von der Konfiguration des Webservers. Man kann (beim Apachen) sehr wohl die Post-Daten (entschlüsselt) mitloggen, wenn man genug Platz im Logspeicher hat...
Das ist bei manchen Fehlersuchen sogar sinnoll.
Es ist aber üblicherweise nicht vorgesehen.
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
Hallo beatovich,
das Schreiben von Log-Files hat mit dem "GET soll nur lesen" nichts zu tun. Es könnten ja auch noch Session-Daten geschrieben werden.
Du musst also unterscheiden zwischen den Betriebsdaten des Servers und den Daten, die die von GET angeforderte Ressource bilden. Vom Server bereitgestellte Ressourcen müssen durch GET unverändert bleiben; du musst GET-Operationen kreuz und quer und beliebig oft durchführen können, und es darf sich nichts an den Ressourcen ändern[1]. Ein GET, der eine Registrierung bestätigt, führt einen Update an der Ressource "User" durch. Fail.
Dass man bei GET Dinge in die URI schreibt, die da möglicherweise nicht hingehören, ist natürlich auch richtig.
Rolf
--
sumpsi - posui - clusi
solange keine DoS-Attacke daraus wird und keine anderen Requests etwas updaten… ↩︎
-
hallo
Hallo beatovich,
das Schreiben von Log-Files hat mit dem "GET soll nur lesen" nichts zu tun. Es könnten ja auch noch Session-Daten geschrieben werden.
In einem gewissen Sinne sind Logfiles noch schlimmer als andere Schreiboperationen. 😉 Dabei spielt es keine Rolle, ob die dort abgebildete Information Daten verändernd ist oder nicht.
--
Neu im Forum! Signaturen kann man ausblenden!
-
-
-
-
hallo
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.Das hat schon was mit Sicherheit zu tun, aus der Sicht des Anwenders. Sicherheit betrifft nicht nur Automatenintegrität.
Sicherheit erlangen wir durch die konsequente Anwendung bester Methoden.
--
Neu im Forum! Signaturen kann man ausblenden!-
Hallo beatovich,
Nein, er hat schon recht, mit Sicherheit hat das nichts zu tun. Aber es ging ja auch nicht um Sicherheit. Es ging um eine best practice (Schreib-Operationen nicht via
GET) und deren Grund. Da mit Sicherheit zu argumentieren ist dann halt am Thema vorbei.Das hat schon was mit Sicherheit zu tun, aus der Sicht des Anwenders. Sicherheit betrifft nicht nur Automatenintegrität.
Nö, das sehe ich anders. Sicherheit (wie in „Security“) ist ziemlich klar definiert, und das hier fällt nicht in den Bereich.
Sicherheit erlangen wir durch die konsequente Anwendung bester Methoden.
Das ist ein notwendiges, aber kein hinreichendes Kriterium.
LG,
CK-
hallo
Das hat schon was mit Sicherheit zu tun, aus der Sicht des Anwenders. Sicherheit betrifft nicht nur Automatenintegrität.
Nö, das sehe ich anders. Sicherheit (wie in „Security“) ist ziemlich klar definiert, und das hier fällt nicht in den Bereich.
Sicherheit erlangen wir durch die konsequente Anwendung bester Methoden.
Das ist ein notwendiges, aber kein hinreichendes Kriterium.
Was ist denn ein hinreichendes Kriterium für Sicherheit (oder Security)?
--
Neu im Forum! Signaturen kann man ausblenden!-
Hallo beatovich,
Sicherheit erlangen wir durch die konsequente Anwendung bester Methoden.
Das ist ein notwendiges, aber kein hinreichendes Kriterium.
Was ist denn ein hinreichendes Kriterium für Sicherheit (oder Security)?
Dass dein System sicher (wie in „secure“) ist 😉
Was möchtest du jetzt da von mir hören? Der Punkt ist: selbst wenn ich mich an alle best practices halte, heisst das nicht, dass ich ein sicheres System habe. Security ist ein komplexes Thema, bei dem schon kleine Fehlen grosse Auswirkungen haben können.
LG,
CK-
hallo
Was möchtest du jetzt da von mir hören? Der Punkt ist: selbst wenn ich mich an alle best practices halte, heisst das nicht, dass ich ein sicheres System habe. Security ist ein komplexes Thema, bei dem schon kleine Fehlen grosse Auswirkungen haben können.
gg
Sicherheit ist wie Gott. Man weiss nicht ob es sie gibt.
Immerhin haben wir Einfluss auf die Zuverlässigkeit, zumindest eine statistische. Und sicheres Verhalten basiert darauf dass man die Zuverlässigkeit in befriedigender Weise erhöht. Sicherheit bleibt ein irrationales Gefühl. Dass wir rational diesem Gefühl eine Substanz zusprechen können, ändert nichts daran.
--
Neu im Forum! Signaturen kann man ausblenden!-
Hallo beatovich,
Sicherheit ist wie Gott. Man weiss nicht ob es sie gibt.
😂
Sicherheit bleibt ein irrationales Gefühl.
Deshalb schrieb ich explizit „wie in ‚Security‘.“ Computer/IT Security ist definiert und kein Gefühl.
Dass wir rational diesem Gefühl eine Substanz zusprechen können, ändert nichts daran.
Nein, du verwechselst Sicherheit, den emotional belegten Begriff und Sicherheit, den fachlich genau definierten Begriff.
Niemand kann mir sagen, warum Überwachungskameras die Sicherheit im fachlichen Sinne erhöhen, aber die gefühlte Sicherheit steigt. Fachlich definiert gibt es keine erhöhte Sicherheit.
LG,
CK-
hallo
Sicherheit bleibt ein irrationales Gefühl.
Deshalb schrieb ich explizit „wie in ‚Security‘.“ Computer/IT Security ist definiert und kein Gefühl.
Dass wir rational diesem Gefühl eine Substanz zusprechen können, ändert nichts daran.
Nein, du verwechselst Sicherheit, den emotional belegten Begriff und Sicherheit, den fachlich genau definierten Begriff.
Niemand kann mir sagen, warum Überwachungskameras die Sicherheit im fachlichen Sinne erhöhen, aber die gefühlte Sicherheit steigt. Fachlich definiert gibt es keine erhöhte Sicherheit.
Wir wissen nicht ob das Wissen der Forschung korrekt ist. Wir entdecken nur, wann es falsch ist. Solange es sich nicht als falsch erwiesen hat, akzeptieren wir es als bestes Wissen, ohne jede Sicherheit, dass es dabei bleiben wird.
Erklär mir doch den fachlich genau definierten Begriff? Und gibt mir bitte auch gleich eine Sicherheit, dass diese Definition richtig ist.
--
Neu im Forum! Signaturen kann man ausblenden!-
Hallo beatovich,
Wir wissen nicht ob das Wissen der Forschung korrekt ist.
Eine Definition ist keine Forschung, sondern eine Prämisse. Sie legt den betrachteten Bereich fest. Abgesehen davon ist mir diese Behauptung zu absolut, als dass ich ihr vorbehaltlos zustimmen könnte.
Erklär mir doch den fachlich genau definierten Begriff?
Das kann die Wikipedia besser als ich:
Cybersecurity, computer security or IT security is the protection of computer systems from the theft and damage to their hardware, software or information, as well as from disruption or misdirection of the services they provide.
Cybersecurity includes controlling physical access to the hardware, as well as protecting against harm that may come via network access, data and code injection. Also, due to malpractice by operators, whether intentional or accidental, IT security is susceptible to being tricked into deviating from secure procedures through various methods.
Und gibt mir bitte auch gleich eine Sicherheit, dass diese Definition richtig ist.
Eine Definition ich fachlichen Sinne legt fest („definiert“), was der Begriff in diesem Kontext meint. Sie ist nicht richtig oder falsch, sondern sie grenzt ein, worüber man sich unterhält. Du kannst mit einer Definition nicht einverstanden sein, etwa weil sie nicht den Bereich abdeckt, über den du dich unterhalten willst. Das macht sie aber nicht falsch.
LG,
CK-
hallo
Das kann die Wikipedia besser als ich:
Cybersecurity, computer security or IT security is the protection of computer systems from the theft and damage to their hardware, software or information, as well as from disruption or misdirection of the services they provide.
Cybersecurity includes controlling physical access to the hardware, as well as protecting against harm that may come via network access, data and code injection. Also, due to malpractice by operators, whether intentional or accidental, IT security is susceptible to being tricked into deviating from secure procedures through various methods.
Und gibt mir bitte auch gleich eine Sicherheit, dass diese Definition richtig ist.
Eine Definition ich fachlichen Sinne legt fest („definiert“), was der Begriff in diesem Kontext meint. Sie ist nicht richtig oder falsch, sondern sie grenzt ein, worüber man sich unterhält. Du kannst mit einer Definition nicht einverstanden sein, etwa weil sie nicht den Bereich abdeckt, über den du dich unterhalten willst. Das macht sie aber nicht falsch.
Ich sehe absolut keinen Unterschied zu meinem mundanen Gebrauch des Begriffs Sicherheit. Dass hier nur von Sicherheit im Zusammenhang von elektronischen Datenverarbeitenden Geräten und Medien gesprochen wird, macht ja keinen Unterschied aus.
Aber es bleibt die reale Komponente Mensch, der allein über seine Intention bestimmen kann, was nun die Sicherheit betrifft. Da streiten sich nämlich auf jedem System die Meinungen.
Bei Sicherheit geht's um Maximierung der Zuverlässigkeit entsprechend den Erwartungen durch Enduser, die ein System beurteilen oder benutzen.
--
Neu im Forum! Signaturen kann man ausblenden!
-
-
-
-
-
-
-
Hallo Christian Kruse,
Nö, das sehe ich anders. Sicherheit (wie in „Security“) ist ziemlich klar definiert, und das hier fällt nicht in den Bereich.
Ist es nicht auch eine Frage der Sicherheit, wenn ich mich darum sorge, dass meine Datensätze nicht versehentlich gelöscht oder verändert werden?
Bis demnächst
Matthias--
Rosen sind rot.
-
-
-
-
Tach!
Sicherheit war noch nie eine Frage der Requestmethode!
Ich sehe keinen Nutzen darin, dass du diese Aussage wiederholst, ohne auszuführen, wie es denn besser gehen würde.
Die Aussage daß die Frage der Sicherheit keine Fage der Requestmethode ist, heißt, daß sie woanders beantwortet werden muß. Ich schrieb da vorhin was von Authorization, genau das ist die Antwort!
Authorization heißt, daß jemand autorisiert sein muss dafür daß er bestimmte Aktionen ausführen darf. Das hat mit der Requestmethode überhaupt nichts zu tun!
MfG
-
-
hallo
Sicherheit war noch nie eine Frage der Requestmethode!
Das ist leider falsch.
Die POST Methode ist für alle schützenswerte Daten ein unverzichtbares Glied in der Kette.
Im Sinne des Schutzes der Privatsphäre sollte man nicht mal die Suchstrings in Suchformularen via GET übertragen.
--
Neu im Forum! Signaturen kann man ausblenden!
-
-
Hi,
Es gibt aber Requestmethoden, die real existierenden Bedingungen unterliegen. Beispielweise die, dass Links, deren Ziel üblicherweise mit GET aufgerufen wird, ungefragt und ohne Beachtung der Aktion, die dabei ausgelöst wird, von Bots verfolgt werden. Seien es Suchmaschinenbots oder auch Link-Checker, mit denen man in seinem eigenen Angebot tote Links aufspüren möchte, oder der Offline-Reader, der sich zu diesem Zweck alle verlinkten Seiten holt.
oder der Browser, der schon mal die verlinkten Seiten prefetched (da gab's mal eine Firefox-Version, die das gemacht hat ...)
cu,
Andreas a/k/a MudGuard-
Hallo MudGuard,
oder der Browser, der schon mal die verlinkten Seiten prefetched (da gab's mal eine Firefox-Version, die das gemacht hat ...)
Opera und Chrome haben das auch mal gemacht. CSS tricks hat dazu eine umfassende Analyse veröffentlicht.
LG,
CK
-
-
-
Hello,
Warum nicht? Wenn Parameter im QueryString Schreibaktionen auslösen, dann ist das so und da hat sich der Enwickler bestimmt was dabei gedacht. Stell Dir vor, Du hast eine Tabelle im Browser und für jede Zeile gibt es eine Löschoption. Soll denn da für jede Zeile ein Formular+Submit-Button in den Browser gerendert werden nur, damit das Löschen eine POST-Aktion wird?
Ein Formular reicht dafür.
Und außerdem ist die Version per GET auch doppelt gefährlich: Ein GET-Request kann bestimmungsgemäß an beliebigen Stellen zwischengespeichert werden (als Log-Eintrag, als Favorit, in eMails, etc.). Wenn man nun nicht sicherstellt, dass IDs nur EINMAL-IDs sind, also nach dem Löschen nicht wiederbelegt werden können, könnte ein anderer User mit Löschrechten versehentlich diesen Link klicken und ungewollt falsche Daten löschen.Beliebige weitere Szenarien hierzu sind denkbar.
Dass es besondere Techniken für derartige Aktionen gibt (Session mit Rechteprüfung auf Select, speichern, Request zum Löschen mit Gegenprüfung, Zeitfenstersperre. Was nicht vorher angezeigt werden konnte, darf auch nicht gelöscht werden), das wird bei der Simpel-Lösung mit GET oft vergessen. Da wird es dann eben einfach so gemacht, wie Du beschrieben hast: frei nach dem Motto "Wieso, funktioniert doch?".
Liebe Grüße
Tom S.--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
hallo
Warum nicht? Wenn Parameter im QueryString Schreibaktionen auslösen, dann ist das so und da hat sich der Enwickler bestimmt was dabei gedacht. Stell Dir vor, Du hast eine Tabelle im Browser und für jede Zeile gibt es eine Löschoption. Soll denn da für jede Zeile ein Formular+Submit-Button in den Browser gerendert werden nur, damit das Löschen eine POST-Aktion wird?
In query-strings gehören nur Dinge, die requestübergreifend eine Gültigkeit haben.
--
Neu im Forum! Signaturen kann man ausblenden!
-