Aiun Geschrieben 6. September 2007 Geschrieben 6. September 2007 hu, häufig werden in Links die Fremdschlüssel im Klartext eingefügt, &user=1, &postid=10 blubbla Nun zwei überlegungen: die ID steht ja immer für einen Datensatz, normalerweise angegeben durch den namen $postid=10, gibt es eine "sinnvolle" möglichkeit, das zu verschlüsseln, so das es nicht mehr "klartext" ist ? ich dachte an base64_encode, was haltet ihr davon ?! 2. Will ich übermitteln, "was" ich übergebe, also einen "Post" aus dem Modul "Forum", $param[]= serialized(array("Forum.Post",10)) oder so.... ?! problem ist hier die länge des GET.... Zitieren
Amstelchen Geschrieben 7. September 2007 Geschrieben 7. September 2007 alles, was nicht GET sein darf/soll, muss POST oder COOKIE sein. POST darf im gegesatz zu GET auch (beinahe) unbegrenzt gross sein. deine anforderung zu verschlüsseln, ist eher eine codierung - ich frage mich nur, wozu du z.b. die nummer eines $post oder eine $userid überhaupt unkenntlich machen willst. s'Amstel Zitieren
.vash Geschrieben 8. September 2007 Geschrieben 8. September 2007 Das Verschlüsseln denke ich bringt nichts - da Du die ja eh wieder entschlüsselst ist es piepegal ob der User eine 1 sieht oder einen String ala §$%&. Letzteres wäre mir als User sogar eher unheimlich ^^ Zitieren
Cadpax Geschrieben 8. September 2007 Geschrieben 8. September 2007 Base64 ist zumal gut 33% länger als der Ursprungscode. Machst du dir Gedanken über XSS? Da gibt es praktikablere Lösungen. Zumal jeder, der XSS beherrscht, auch einen Base64 String en-/dekodieren kann. Mit freundlichen Grüßen, Cadpax Zitieren
geloescht_JesterDay Geschrieben 10. September 2007 Geschrieben 10. September 2007 häufig werden in Links die Fremdschlüssel im Klartext eingefügt, &user=1, &postid=10 blubbla [...]gibt es eine "sinnvolle" möglichkeit, das zu verschlüsseln, so das es nicht mehr "klartext" ist ? ich dachte an base64_encode, was haltet ihr davon ?! Gar nichts. Grundsätzlich gilt ja: "Sicher ist es wenn es keiner kann, nicht wenn es keiner weiß." Was du willst ist ja, dass keiner weiß wie da evtl. Schlüssel o.ä. sind. Wenn du dich darauf verlässt, dann ist die Chance dass du eine andere Lücke übersiehst viel größer. Mach dein Ding so, dass egal welchen Schlüssel jemand kennt, er damit nichts anfangen kann. base64 ist ja keine Verschlüsselung, sondern einfach ein Kodieren. Das bringt gar nichts, denn aus X wird immer Y und ein Dekodieren ist auch ohne Probleme für jeden Möglich (der es will). So spontan würde mir einfallen, dass du bei der Ausgabe der Links eine Funktionalität einbaust, dass du die ID in eine Tabelle schreibst und dazu eine zufällige Pseudo-ID. Umgekehrt rufst du dann über die Pseudo-ID die richtige ID ab. Das ganz könntest du noch binden an eine IP-Adresse und einen Zeitraum usw. Aber ob das wirklich sinnvoll ist... 2. Will ich übermitteln, "was" ich übergebe, also einen "Post" aus dem Modul "Forum", $param[]= serialized(array("Forum.Post",10)) oder so.... ?! problem ist hier die länge des GET.... Der GET ist AFAIK auf 1KB beschränkt, also 1024 Zeichen. Das könntest du auch kürzen, indem du intern eine Tabelle mit den verschiedenen Modi hast: ID Modus 10 Forum.Post 20 Wiki.Post 30 Blog.Post ... und als Parameter hängst du dann &mode=10 an z.b. Damit sparst du Zeichen im GET, aber hast halt den Aufwand mit der DB und der Wartung etc. EDIT: Ich hab mir das hier grade mal angesehen, was da so gesendet wird wenn ich den Eintrag abschicke... Da wird neben der NAchricht noch z.B. ein posthash mitgesendet, dann eine loggedinuser-Nummer und eine poststarttime. Denke dass dass ähnlich wie oben gesagt dann intern erstmal alles geprüft wird, bevor die eintragungen gemacht werden. Zitieren
Aiun Geschrieben 10. September 2007 Autor Geschrieben 10. September 2007 naja, es geht jetzt nicht um perfekte sicherheit, nur um "sicherer" Die Übergabe des Entität-Namens würde mir erlauben eine Automatische prüfung und Konvertierung zum Objekt zu machen, bevor die eigentliche verarbeitungslogik ans Werk geht. Fakt ist, das es ein vielfaches an Aufwand ist, einen String in dem der schlüssel enthalten ist zu dekodieren, als ihn einfach per Hand zu ändern ^^ aber danke für die Antworten, vielleicht greife ich das später nochmal auf. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.