Dieser Artikelsagt, dass mitopcache_get_status()aktiviert ist ein Sicherheitsrisiko. Um es auszuschalten, muss man konfigurieren opcache.restrict_api, aber ich konnte kein Beispiel dafür finden.
Diese Personhatte die Einschränkung bei der Konfiguration als in Kraft opcache.restrict_api=/restricted, was mir einen Hinweis darauf gibt, dass es ein Pfad sein muss.
Ich begann mit der Erstellung eines Testskripts mit einem opcache_get_status()Aufruf und erhielt eine Ausgabe von vielen PHP-Skripten auf diesem System, was bestätigte, dass es keine Einschränkung gab. Dann bearbeitete ich meins /etc/php/7.3/fpm/php.iniso, dass es vorhanden war opcache.restrict_api=/dev/null, und derselbe Aufruf gibt jetzt zurück bool(false)– ich gehe davon aus, dass die Einschränkung aktiviert ist.
opcache_get_status()Mein Ziel ist es , Skripte und Ähnliches vollständig zu verbieten . Indem ich Skripte darunter „zulasse“ /dev/null, mache ich deren Verwendung im Wesentlichen unmöglich, da Sie dort keine Datei erstellen können.
- Ist diese Logik richtig?
- Sollte ich vielleicht einen anderen Weg verwenden?
- Gibt es eine Möglichkeit, die Einschränkung direkt zu aktivieren, ohne mit falschen Pfaden herumzuspielen?
Danke
Antwort1
Betrachtet man den Quellcode vonext/opcache/zend_accelerator_module.c
- Damit die Informationen „durchsickern“,
validate_api_restriction()muss zurückkehrentrue. - Indiese Funktion selbst, es dauert
SG(request_info).path_translated(was anscheinendist gleichSCRIPT_FILENAME) Undvergleicht es mitrestrict_api, Vergleichdie ersten paar Zeichender beiden Werte. - Da das erste Zeichen von
path_translatedakaSCRIPT_FILENAMEein Schrägstrich ist,opcache.restrict_api=1wird es nicht übereinstimmen (/!=1) und scheint daher sicher zu sein
Auchhier ist jemand anderes mitopcache.restrict_api=1zu.
Bitte korrigieren Sie mich, wenn ich irgendwo falsch liege! Bis dahin habe ich das Gefühl, dass dies meine Frage im Wesentlichen beantwortet.