Diese Optionen funktionieren nur, wenn PHP als Apache Modul eingesetzt wird, was an sich unter Sicherheitsaspekten suboptimal ist - das es nicht klappt, ist also völlig in Ordnung
Beiträge von SniperSister
-
-
Danke dir , das heißt man kann nur einzelne Werte escapen und nicht verkettete Werte?
Beim Escaping geht es ja darum, einen String (z.B. Wert oder Spaltennamen) den man an eine Datenbank übergibt, vorher so zu behandeln, dass er nicht mehr schädlich sein kann. Beispiel:
Was passiert wenn du hier als $email ein
übergibst?Richtig, das hier:
Damit bekommst du dann plötzlich nicht mehr das Passwort von einem bestimmten Nutzer sondern die Passwörter von allen Nutzern, denn "1" = "1" trifft immer zu.
Das Escaping wandelt solche "Steuerzeichen" also um und escaped sie durch ein \ womit sie als normales Zeichen eingelesen werden - das sieht man dann ja in deiner Fehlermeldung.
Das hat natürlich sofort funktioniert. Wie kann ich denn in Zukunft Testen ob das Escapen funktioniert hat. Weil wen ich zb. $daten mit print_r ausgebe sehe ich kein Unterschied.Schmeiß ein paar pöse Zeichen rein.
Ein weiteres Anliegen wäre dann das Cachen der Werte. Hast du da zufällig noch ein paar verweiße zum nachlesen dazu?Der erste Link ist da eigentlich ganz gut, was anderes hab ich leider auch nicht zur Hand.
-
Eher so:
Code$id = (int) $rohdata['id']; $name = preg_replace("/[^a-zA-Z0-9 ]/","",$rohdata['name']); $status = preg_replace("/[^a-zA-Z]/","",$rohdata['status']); $ally = (int) $rohdata['alliance']; $daten[] = "($id, " . $db->quote($db->escape($name)) . ", " . $db->quote($db->escape($status)) . ", $ally)"; } $daten1 = implode(', ', $daten); $queryDb = 'REPLACE INTO #__ogameally ( `userid_ogame`, `user_name_ogame`, `status_ogame`, `ally_id_ogame`) VALUES ' . $daten1;
-
Hast du den Link zur Doku angeschaut, den ich gepostet habe?
-
Die Variante mit dem preg_replace ist schonmal ein sehr guter Anfang, aber warum lässt du die einzelnen Werte nicht trotzdem escapen?
-
Korrekt. Wenn die ID numerisch ist kannst du die z.B. mittels
umwandeln. Die Strings werden über die API escaped und gequotet:
https://docs.joomla.org/Secure…guidelines#Secure_strings -
Fragen wir mal andersherum: was passiert denn, wenn in besagtes XML mal bösartige SQL-Befehle eingestreut werden? Du gibst die hier 1 zu 1 an die Datenbank weiter und hast dadurch ein Problem. Ja, ich weiß, das ist vielleicht nicht sonderlich wahrscheinlich - aber es gibt keinen Grund diese potenzielle Lücke offen zu lassen.
-
Drei Tipps:
1. nutze JHTTP statt fopen, das ist zuverlässiger
2. du solltest das Ergebnis der HTTP Abfrage mittels JCache zwischenspeichern, du ruinierst dir sonst die Performance der Seite
3. du hast eine SQL Injection Lücke im Code. Du musst die Werte escapen, bevor du sie in der Query verwendest. -
Das würde ich nicht "Lösung" nennen. Anstatt die Inkompatibilität im JSN zu fixen hast du im Grunde genommen ein Downgrade gemacht.
-
Ich habe gerade mal versucht dass hier nachzustellen, hatte aber erwartungsgemäß keinen Erfolg - die Updates werden erfolgreich abgefragt, sowohl Serverseitig (Joomla macht die eigentliche Abfrage gegen die Update-Server, hier kann die .htaccess auch garnicht greifen) als auch Clientseitig (Browser fragt via AJAX den Update-Status ab und zeigt das Ergebnis).
Was sagt deine Browser-Konsole beim Abruf der Updates? Dort müssten etwaige Fehler ausgegeben werden.
ZitatBin eh skeptisch, denn die Auswertung der Header obliegt sicher den Browsern und kann daher auch einfach mißachtet werden. Ich habe daher Zweifel an dem Nutzen/Wirksamkeit allgemein, aber wie gesdagt ich kann mich täuschen, denn diese Headereinträge haben mich noch nicht beschäftigt.
Die Header greifen dann, wenn ein serverseitiger Angriff bereits erfolgreich war. Beispiel: die Seite hat eine XSS-Lücke über die externes JavaScript eingeschleust werden kann. Die CSP Header führen dann dazu, dass dieses externe JavaScript garnicht erst geladen wird, weil über die CSP ein Whitelisting erfolgt.
-
-
Falls jemand in der Kombination PHP 5.3, aktivierte Mehrsprachigkeit und Joomla 3.7.3 einen Error 500 im Frontend bekommt, hier gibt es einen Hotfix:
https://github.com/joomla/joomla-cms/issues/16965 -
Diese Validierung ist serverseitig.
-
Du stolperst hier über einen bekannten Bug von Joomla 3.7.0, als workaround kannst du in der globalen Konfiguration die HTML-Filterung für die jeweilige auf keine Filterung setzen.
-
-
@chr-hl wir (ich + Kollegen) arbeiten gerade an einem Relaunch der Website eures Stadtverkehrs und kommen dann wohl mal zur Kunden-Schulung hoch zu euch, vielleicht lässt sich das ja miteinander verbinden?
-
Feedback: ist wohl global für alle betroffenen Installationen gefixt worden!
-
Könnte es eventuell sein, dass dein primäres Ziel das pushen deines Services ist? Sich extra hier anzumelden um zu verkünden, dass man um das ohnehin vorhanden Joomla-Dockerfile noch ne docker-compose.yml gebaut hat ist doch ein wenig sehr motiviert, oder?
Reflektier doch einfach mal deine Motive und überleg dir, ob der Post in einem Forum wie diesem wirklich bleiben soll.
-
Das Caching mittels Apache-Modul wäre im Joomla-Kontext nicht machbar. Erstens unterstützen es viele Hoster nicht (erst recht nicht mit Memcached) und zweitens stellen sich dann so interessante Fragen wie Cache-Invalidation.
Der Weg, den Joomla da geht, ist somit schon in Ordnung.
-
Welche Werte bewirken denn in der .htaccess ein serverseitiges Caching?