3. url-tag versagt

url-tag versagt

  • D

    Die Browser maskieren sie garantiert auch.
    D.h. unser Tag sollte das auch machen.

    0
  • H

    Ja, der Browser maskiert sie vor dem abschicken. Aber das kann die Forensoftware natürlich nicht tun, weil sie dann jeden Text als URL erkennen würde und nicht mehr unterscheiden kann, bis wo die URL geht und bis wo nicht mehr.

    Normal sollte dein Browser nach dem Abschicken sie auch maskiert anzeigen, sodass du sie hier vernünftig reinkopieren kannst.

    Hier kannst du dir durchlesen, was erlaubt ist und was nicht:
    http://www.ietf.org/rfc/rfc1738.txt

    Und ja, wir versuchem dem Standard zu folgen, definieren aber keinen selbst.

    0
  • H

    Henno schrieb:

    ...nicht mehr unterscheiden kann, bis wo die URL geht und bis wo nicht mehr.

    Hmm... bis zum [/URL] bzw. bis zum letzten /]? 🙂 Auf die automatische URL-Erkennung verlässt sich ja sowieso niemand bei URLs, die komplizierter als www.google.de sind.

    Das Maskierte aus der URL ist aber für... nichttechnische Systeme (auch liebevoll User genannt) schwerer lesbar. Man müsste also zu jeder Url am besten gleich ein Alias angeben. Bäh.

    0
  • S

    HEZ schrieb:

    http://de.wikipedia.org/wiki/Überwachungsstaat
    bla

    http://de.wikipedia.org/wiki/Deviation (Navigation)
    [url=http://de.wikipedia.org/wiki/Deviation (Navigation)]bla[/url]

    😉

    Also in Deiner letzten ist eigentlich auch ein Unterstrich ( _ ), kein Leerzeichen... 😕

    dEUs schrieb:

    Die Browser maskieren sie garantiert auch.
    D.h. unser Tag sollte das auch machen.

    Henno schrieb:

    Ja, der Browser maskiert sie vor dem abschicken. Aber das kann die Forensoftware natürlich nicht tun, weil sie dann jeden Text als URL erkennen würde und nicht mehr unterscheiden kann, bis wo die URL geht und bis wo nicht mehr.

    Mhhh... ich fühl' mich jetzt schon blöd weil ich frage... - aber ich steh' wohl irgendwie ziemlich auf'm Schlauch. Darum frag' ich trotzdem: 🕶

    Warum muß (sollte) die Forensoftware ÜBERHAUPT irgendwas maskieren?!? 😕
    IMHO würde eine simpelste Textersetzung reichen:

    IF erste_5_Zeichen == "[url=" THEN ERSETZE_MIT( "<a href=" )

    IF erstes_Zeichen == "]" THEN ERSETZE_MIT ( ">" )

    IF erste_4_Zeichen == "[/url]" THEN ERSETZE_MIT( "</a>" )

    Also FF und IE haben bei mir jedenfalls keine Probleme mit

    <HTML>
<BODY>
<A HREF=http://de.wikipedia.org/wiki/Deviation_(Navigation)>Karl</A>
</BODY>
</HTML>

    bzw.

    <HTML>
<BODY>
<A HREF=http://de.wikipedia.org/wiki/Überwachungsstaat>Karl</A>
</BODY>
</HTML>

    ... 😕
    (...und auch bei Leerzeichen gibt's keine Abstürze ;))

    Da sollten sich doch die Browser drum kümmern, was gibt's denn da zu taggen?!? 😕 *schnellumdrehundwegrenn*

    Henno schrieb:

    Normal sollte dein Browser nach dem Abschicken sie auch maskiert anzeigen, sodass du sie hier vernünftig reinkopieren kannst.

    IMHO nicht aus oben genannten Gründen.
    Sie sollten auch nicht die IP statt der Domain anzeigen. 💡

    0
  • D

    Henno schrieb:

    Hier kannst du dir durchlesen, was erlaubt ist und was nicht:
    http://www.ietf.org/rfc/rfc1738.txt

    Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
    reserved characters used for their reserved purposes may be used
    unencoded within a URL.

    Die Url oben sieht also richtig aus.

    0
  • H

    Ja, deine ist korrekt und der Fehler wird behoben werden.

    0
  • H

    Sgt. Nukem schrieb:

    Also in Deiner letzten ist eigentlich auch ein Unterstrich ( _ ), kein Leerzeichen... 😕

    Nach der ersten Umwandlung. Aber gut, bei Leerzeichen steigt so einiges aus.

    0
  • H

    Sgt. Nukem: Mit deinem Vorschlag könnte man ne Menge Unsinn machen, den wir hier nicht haben wollen (z.B. beliebigen HTML Code einschmuggeln).

    Und IP anzeigen ist nicht das gleiche, wie URL anzeigen. Deswegen machen die Browser das nicht.

    Mozilla zeigt bei eurer Überwachungsstaat URL bei mir in der URL Leiste folgendes an:

    http://de.wikipedia.org/wiki/Überwachungsstaat

    0
  • H

    Henno schrieb:

    http://de.wikipedia.org/wiki/Überwachungsstaat

    Ja, und das sieht scheiße aus! Noch ein Umlaut und es %C3%9Cberhaupt nicht mehr klar, wor%C3%9Cber man sich %C3%9Cberhaupt unterh%C3%84lt.

    Und bring endlich den Vorschlag, dass man das auch [ url=http://de.wikipedia.org/wiki/%C3%9Cberwachungsstaat]http://de.wikipedia.org/wiki/Überwachungsstaat[/url] schreiben kann, dann haben wirs hinter uns. 🙄

    0
  • ?

    HEZ schrieb:

    Henno schrieb:

    http://de.wikipedia.org/wiki/Überwachungsstaat

    Ja, und das sieht scheiße aus! Noch ein Umlaut und es %C3%9Cberhaupt nicht mehr klar, wor%C3%9Cber man sich %C3%9Cberhaupt unterh%C3%84lt.

    Ja so ein Pech aber auch. '&' sieht auch scheiße aus im Vergleich zu '&' und trotzdem gibt es das. 😮 😮
    Wenn der Standard festlegt, dass es so aussieht, dann ist es so. Benutze halt keine URLs mehr. 🤡

    Wo ist denn jetzt das Problem, den richtigen URL anzugeben? Du kannst den Link ja trotzdem mit einem beliebigen Text ausstatten.

    0
  • H

    Optimizer schrieb:

    Ja so ein Pech aber auch. '&' sieht auch scheiße aus im Vergleich zu '&' und trotzdem gibt es das. 😮 😮

    Das Argument haut mich um. Du solltest nen Browser statt nem Texteditor verwenden, um Websites anzuschauen. Du wirst sicher überrascht sein, wie das plötzlich aussieht... 👍

    Wo ist denn jetzt das Problem, den richtigen URL anzugeben? Du kannst den Link ja trotzdem mit einem beliebigen Text ausstatten.

    Naja, zumindest fast die Antwort, auf die ich so lange gewartet habe. Danke.

    0
  • H

    Nein, über den Weg andersherum kann man sicher reden, also dass aus:

    [u r l]http://de.wikipedia.org/wiki/Überwachungsstaat[/u r l]

    [ u r l = http://de.wikipedia.org/wiki/Überwachungsstaat]http://de.wikipedia.org/wiki/Überwachungsstaat[/ u r l]

    gemacht wird. Kann sein, dass es dafür in PHP sogar ne Funktion gibt. Aber andersherum stellt ein Problem dar.

    EDIT: Übriegens ein nettes Beispiel, was passiert, wenn man reservierte Zeichen in den URLs zulässt *g*

    0
  • S

    Henno schrieb:

    Sgt. Nukem: Mit deinem Vorschlag könnte man ne Menge Unsinn machen, den wir hier nicht haben wollen (z.B. beliebigen HTML Code einschmuggeln).

    Okay. Reicht es dann nicht, einfach < in URL-Tags rauszufiltern und abzufangen, ggf. noch ein CheckFor( ToLowercase( 'javascript' ) ) und das rausfiltern. Was geht dann noch?!
    Wäre zumindest immer noch ohne RegEx mit 'nem simplen Text-Vergleich getan...

    EDIT:
    Für Links ohne URL-Tag könnte man das per RegEx gefundene in der Pre-Stufe bis zum ersten Leerzeichen in [ur.l] & [/ur.l] umklammern und dann die gleichen Regeln walten lassen.

    Dann würde auch ...Überwachungsstaat funzen und ein [ur.l]www.google.de>Google</a> <iframe=XXX/> <a href=www.google.de>Google[/ur.l] wäre trotzdem nicht mehr möglich, da statt

    <a href=www.google.de>Google</a> <iframe=XXX/> <a href=www.google.de>Google</a>

    folgendes

    <a href=www.google.de>Google/a> iframe=XXX/> a href=www.google.de>Google</a>

    rauskäme... 😕

    0
  • H

    Mhmm, also alle <, > und " muss man ja sowieso maskieren, von daher sollte man soweit ich das im Moment überblicken kann auch nicht aus der URL ausbrechen können.

    Man kann natürlich dann noch mit javascript (nur damit? Da gibts doch bestimmt noch anderen Scheiß von Microsoft) Blödsinn anstellen. Man könnte beliebige Links einfügen, also auch auf Pfade auf der eigenen Festplatte.

    Sicher ist es möglich das ganze Wasserdicht zu machen, aber es ist nicht einfach und höchst wahrscheinlich vergisst man irgendwas.

    0
  • S

    Henno schrieb:

    Man kann natürlich dann noch mit javascript (nur damit? Da gibts doch bestimmt noch anderen Scheiß von Microsoft) Blödsinn anstellen.

    Ja, deswegen ja mein

    Sgt. Nukem schrieb:

    ggf. noch ein CheckFor( ToLowercase( 'javascript' ) ) und das rausfiltern.

    Ansonsten geht halt sowas wie [ur.l]java\1:window.height=10;[/ur.l]. Gibt's für VBScript auch so ein Tag?! Gut, das wär's doch dann aber auch... 😕

    Henno schrieb:

    Man könnte beliebige Links einfügen, also auch auf Pfade auf der eigenen Festplatte.

    Aber ein [ur.l]file://C:\Eigene%20Dateien\Beethoven.mp3[/ur.l] ist jawohl nicht problematisch. Das kann man doch lassen...

    0
  • S

    Oder noch viel einfacher:

    Man schaut einfach nach null oder einem : -- bei mehr cancelt man. Falls ein : -> wird davor nach ftp und http und danach nach // untersucht. Alles andere wird gecancelt, maskiert, whatever. 💡
    Generell ist in so einem Sicherheitsfall eine Whitelist wohl besser als eine Blacklist.

    0
  • Y

    Am besten man lässt nur http und vlt. noch ftp zu, der Rest wird dann gemäß dieser Regeln maskiert. Ich seh' da eigentlich keine Sicherheitsrisiken.

    0
  • H

    https fehlt noch und : werden bei Wikipedia auch in der URL benutzt (glaub aber unerlaubter weise).

    Wenn man dann die URL seperat betrachtet oder nur die Eingabe einer URL hätte, dann gäbe es sicherlich keine weiteren Probleme. Aber hier geht es um die Einbettung in Text. Was passiert, wenn jemand das Close Tag vergisst? Wird dann alles bis zur nächsten URL zur URL? Was ist, wenn da irgendwo andere Tags drin sind?

    Ich behaupte nicht, dass es nicht geht, aber so einfach, wie ihr euch das hier an den isolierten Beispielen denkt, ist es nicht. Und das ganze muss ja auch jemand programmieren... du?

    0
Anmelden zum Antworten