Sonderzeichen in forum-posts

[imara]

Hallo Leute,
da ich das Portal auf Englisch betreibe, habe ich viele Einträge mit ( \\\' ) wie I\\\'m und don\\\'t sowie andere Sonderzeichen. Wenn der User den Post abschickt, werden diesen Zeichen dann automatisch Schrägstriche vorgesetzt um sie PHP gegenüber zu deaktivieren. Kann man das irgentwie anders gestalten? Ist auf Dauer lästig und sieht nicht sehr professionell aus.

Schau in deine php.ini. Dort findest Du drei Konfigurationsoptionen, welche mit magic_quotes_ anfangen. Diese solltest Du auf \"off\" konfigurieren.Zusätzlich kannst Du noch die Funktion http://de.php.net/stripslashes\" rel=\"external nofollow\">stripslashes() verwenden.

[imara]

Hallo Statler,
die magic_quotes sind auf \"off\". Daran liegt es nicht.
Das mit den stripslashes musst du mir mal genauer erklären, da hab ich keine Ahnung davon.
Klingt aber nach URL. Bist dir schon darüber im Klaren, dass es sich im die Darstellung von Text im Post geht, ja?
So wie in diesem Englischen Satz:
I don\'t know if I\'m sure ...
die Backslashes werden nachträglich eingetragen, in der Vorschau ist noch alles klar.
Powie hat schonmal erwähnt, er werde einen Filter einbauen. Mal sehen wann es dazu kommt /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
Ich warte geduldig  /uploads/emoticons/icon_e_wink.gif.c059000ae48ff64afa53be0962c021f2.gif\" alt=\":wink:\" />

Original von imara Das mit den stripslashes musst du mir mal genauer erklären, da hab ich keine Ahnung davon.
Klingt aber nach URL. Bist dir schon darüber im Klaren, dass es sich im die Darstellung von Text im Post geht, ja?
[/quote]
Ja. Was meinst Du mit URL?

[Powie]

@imara -> magic_quotes auf ON setzen! Sicherheitsteschnisch wichtigst!

Original von Powie @imara -> magic_quotes auf ON setzen! Sicherheitsteschnisch wichtigst!
[/quote]
So ein Unsinn. magic_quotes_* haben genau gar nichts mit Sicherheit zu tun. Diese Konfigurationsoptionen, genau wie http://blog.php-security.org/archives/3-register_globals-is-not-evil.html\" rel=\"external nofollow\">register_globals oder allow_url_fopen, spielen Bedrohungen runter, an denen eigentlich unfähige Programmierer schuld sind. Sie helfen nicht mal als \"First Wall\" gegen Bedrohungen, da sie oft trivial zu umgehen sind (allow_url_fopen beispielsweise über php://input).
Imara, lass dich nicht veräppeln, denn wer als Programmierer empfiehlt, magic_quotes_* auf on zu setzen, weiß wohl, dass er bei der Input-Überprüfung seiner Skripte gepennt hat und versucht nun seine Verantwortung in den Einflussbereich des Nutzers abzuschieben.

[Powie]

da ist ja sicher etwas wahres dran Statler, kein Zweifel, aber ich erinnere nur an die letzten Advisory\'s zu Security Bugs in den eigentlichen php Releases, Das hat nichts  mit \"vorhersehbarer\" sicherer Programmierung zu tun. Aber was du gerade \"in Frage stellst\" ist das gleiche als wollte man eine Firewall im Rechenzentrum in Frage stellen.
Logisch: ist alles korrekt, sauber und sicher, so benötigt man auch dort keinen Firewall.... trotzdem gibts ihn!

Original von Powie da ist ja sicher etwas wahres dran Statler, kein Zweifel, aber ich erinnere nur an die letzten Advisory\\\\\\\'s zu Security Bugs in den eigentlichen php Releases, Das hat nichts  mit \\\\\"vorhersehbarer\\\\\" sicherer Programmierung zu tun.
[/quote]
Das ist aber was anderes. Gegen Bugs im Interpreter selbst gibt es für einen Programmierer nur wenig Schutz (aber beispielsweise den Hardening-Patch und oder Suhosin). Gegen Software, welche aber darauf vertraut, dass bestimmte Settings gegeben sind, von denen bekannt ist, dass sie eben nicht verfügbar sein müssen, gibt es aber sehr wohl Schutz. Das ist einfach Schlamperei.

Original von Powie Aber was du gerade \\\\\"in Frage stellst\\\\\" ist das gleiche als wollte man eine Firewall im Rechenzentrum in Frage stellen.
[/quote]
Vornweg: Firewalls sind keine Softwareprodukte, sondern Konzepte. Ich gehe jetzt einfach mal von einem Paketfilter aus.
Für manche Zwecke sind Paketfilter eben auch nicht das richtige Mittel. Ich betreibe mehrere Webserver in einem Cluster. Da existiert sowas gar nicht. Dafür ist der Cluster aber sauber konzipiert, wird regelmäßig aktualisiert und ist so eingerichtet, dass sowieso nur notwendige Ports nach außen offen sind. Andere Sachen laufen darauf einfach nicht. Schon hat man sich einen Paketfilter gespart, der nicht nur Performance, sondern auch Zeit und Geld kostet. Zumal es auch genügend Bugs in Firewall-Produkten gegeben hat und der in einem solchen Szenario genau gar nichts bringt, weil er den Zugriff auch nicht vorhandene Lücken regelt. Auch wird Software äußerst sparsam eingesetzt.

Original von Powie Logisch: ist alles korrekt, sauber und sicher, so benötigt man auch dort keinen Firewall.... trotzdem gibts ihn!
[/quote]
Sie. Es ist eine Brandschutzmauer.
Findest Du es nicht seltsam, dass man lieber Energie in eine weitere Schicht Sch(m)utz für bekannte Lücken steckt als diese endlich mal zu beheben?

[Powie]

Ich bin trotzdem der Meinung und stimme den folgenden Punkten zu:
- Es gibt keine fehlerfreie Software
- Es gibt keine 100% sichere Software
- Hardware wird immer irgendwann kaputt gehen
Daher ist eben ein Schutz niemals eine einstellige Massnahme. Das geeignete Mittel ist oftmals das Mittel mit dem geringsten Aufwand, sehen wir am Beispiel Firewall.
Oder der safe_mode bei php. Ich glaube darum dreht sich so ein riesen Hype, vor allem von Leuten die noch immer php 4.2.x oder 5.0.x benutzen, anstatt sich mal um die Advisory\'s zu kümmern die ihre benutzten Versionen durchlöchern. Oder we war da der Spruch: Cool ist was In ist.

- Es gibt keine fehlerfreie Software
- Es gibt keine 100% sichere Software
- Hardware wird immer irgendwann kaputt gehen
[/quote]
Warum dann die angreifbare Code- und Hardwarebasis mit zusätzlichen Schwachpunkten versehen?

Daher ist eben ein Schutz niemals eine einstellige Massnahme. Das geeignete Mittel ist oftmals das Mittel mit dem geringsten Aufwand, sehen wir am Beispiel Firewall.[/quote]
Was hilft dir der Schutz eines Paketfilters (nochmal: Eine Firewall ist ein Konzept kein Stück Technik), wenn gar nichts vorhanden ist, was angegriffen werden kann oder das Angriffsziel nicht ansprechbar ist? Was soll beispielsweise ein Paketfilter an einem Webserver schützen? Port tcp/80? Oder udp/53? Wenn Port 22 nur Verbindungen von $IP annimmt, wieso sollte man diese dann noch zusätzlich per Paketfilter abschirmen (wenn vorallem die Gefahr besteht, dass man einen DoS verursacht)? KISS wird nicht umsonst ständig empfohlen (und nur selten berücksichtigt).

Oder der safe_mode bei php.[/quote]
Kann funktionieren wenn der Host ordentlich eingerichtet ist. Aber hilft auch nichts gegen schlecht programmierte Skripte. Deswegen ist der Einsatz von safe_mode auch sinnlos. Im Gegenteil: Genau wie Paketfilter sorgt er für Scheinsicherheit (Risikokompensation) und verbreitert die angreifbare Codebasis.

Cool ist was In ist.[/quote]
Ja. Paketfilter beispielsweise.

[Powie]

das mit dem safe_mod erlebe ich ehr umgekehrt..... das sich Webhoster nicht \"trauen\" diesen abzuschalten, da sie denken sie reissen riesen Sicherheitslücken auf dem Server auf.... dabei ist die einzigste damit verbundene Sicherheutslücke eigentlich ein fälschlich konfigurierter Webserver selbst, der Kunde selbst kann da nicht wirklich was falsch machen.

[Powie]

backtotopic:
@imara: Welche php Version habt ihr auf dem Webserver , ich hab im Test feststellen können das die Erkennung der magic_quotes on oder off scheinbar nicht sicher funktioniert

[imara]

PHP 4.4.4
 
.