1ddb97371f
session.upload_progress.enabled = 0 e session.use_strict_mode = 1, come indicato da Sansec in attesa della patch; restano anche dopo, perche' all'applicazione non servono (Laravel ha le sue sessioni, in Redis). Test di guardia in VersionePhpTest. HANDOFF: stato della mitigazione e scelta ancora aperta sul rilascio in produzione. README: sicurezza. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
31 lines
1.1 KiB
INI
31 lines
1.1 KiB
INI
[PHP]
|
|
; upload_max_filesize e post_max_size NON stanno qui: li genera entrypoint.sh
|
|
; in conf.d/zz-upload-limit.ini a partire da MAX_UPLOAD_MB, insieme al
|
|
; client_max_body_size di nginx, cosi' una sola variabile governa tutta la
|
|
; catena. Rimetterli qui non farebbe danno (zz- viene caricato dopo e vince),
|
|
; ma sarebbe una seconda fonte per lo stesso numero.
|
|
memory_limit = 256M
|
|
max_execution_time = 120
|
|
max_input_vars = 3000
|
|
|
|
[Session]
|
|
; Mitigazione di CVE-2026-109618/109619 (RCE nel core di PHP, 21/10/2026),
|
|
; come indicato da Sansec in attesa della patch, e da tenere anche dopo:
|
|
; l'avanzamento degli upload nelle sessioni native di PHP non serve
|
|
; all'applicazione (Laravel ha le sue sessioni, in Redis, e Livewire non lo
|
|
; usa) ed è il punto da cui passano questi attacchi. Lo strict mode vale solo
|
|
; per le sessioni native, che qui non si usano: costa niente.
|
|
session.upload_progress.enabled = 0
|
|
session.use_strict_mode = 1
|
|
|
|
[opcache]
|
|
opcache.enable = 1
|
|
opcache.memory_consumption = 128
|
|
opcache.interned_strings_buffer = 8
|
|
opcache.max_accelerated_files = 10000
|
|
opcache.validate_timestamps = 1
|
|
opcache.revalidate_freq = 0
|
|
|
|
[Date]
|
|
date.timezone = Europe/Rome
|