Ecco le meravigliose notizie che ci giungono dalle ultime due nuove release di wp, a breve distanza.
SONO TUTTI AGGIORNAMENTI DOVUTI A FALLE DI SICUREZZA! GROSSE!
La 4.7.2 ci dice:

Summary

From the WordPress 4.7.2 release post: WordPress versions 4.7.1 and earlier are affected by three security issues:

1. The user interface for assigning taxonomy terms in Press This is shown to users who do not have permissions to use it. Reported by David Herrera of Alley Interactive.
2. WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data. WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability. Reported by Mo Jangda (batmoo).
3. A cross-site scripting (XSS) vulnerability was discovered in the posts list table. Reported by Ian Dunn of the WordPress Security Team.

From the additional 4.7.2 security disclosure, WordPress versions 4.7.0 and 4.7.1 are affected by the following security issue:

1. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this. Reported by Marc-Alexandre Montpas of Sucuri.

LA PRECEDENTE NON CHE ANDASSE MEGLIO….

Summary

From the WordPress 4.7.1 release post: WordPress versions 4.7 and earlier are affected by eight security issues:

1. Remote code execution (RCE) in PHPMailer – No specific issue appears to affect WordPress or any of the major plugins we investigated but, out of an abundance of caution, we updated PHPMailer in this release. This issue was reported to PHPMailer by Dawid Golunski and Paul Buonopane.
2. The REST API exposed user data for all users who had authored a post of a public post type. WordPress 4.7.1 limits this to only post types which have specified that they should be shown within the REST API. Reported by Krogsgard and Chris Jean.
3. Cross-site scripting (XSS) via the plugin name or version header on update-core.php. Reported by Dominik Schilling of the WordPress Security Team.
4. Cross-site request forgery (CSRF) bypass via uploading a Flash file. Reported by Abdullah Hussam.
5. Cross-site scripting (XSS) via theme name fallback. Reported by Mehmet Ince.
6. Post via email checks mail.example.com if default settings aren’t changed. Reported by John Blackbourn of the WordPress Security Team.
7. A cross-site request forgery (CSRF) was discovered in the accessibility mode of widget editing. Reported by Ronnie Skansing.
8. Weak cryptographic security for multisite activation key. Reported by Jack.

ok, sono anni che lo evito, ma visto che il 2016 è stato un anno di m****a, ecco, che prima della fine mi riserva un sorpresone:
installati i certificati SSL per un sitone di lavoro.. 😮
mhuuuu io voglio fare frontend e finisco sempre a ravanare nell’oscurità dei server 🙁
vabbè. dai, forza! un po di “alone in the dark” nei manuali in inglese. ..ultimi 3 giorni dell’anno.
Procedura certificati SSL per Gandi hosting (niente certbot e let’s encript! avvisati! almeno, non in modo esplicito, poi loro di Gandi sotto dicono di usarli!)
-1) SSL, sta per secure socket layer, quindi uno strato di canale sicuro, diciamo… è la s che compare in http >> https quando state mandando al server una password.. comunemente, quindi quando vi autenticate su qualche sito/email/cloud, etc..
Le forze in gioco sono: dominio, server, toccati di sbieco i DNS.
0) da ssh, generarsi un .csr e un .key che mitologicamente sono come una chiave privata ed una richiesta di chiave pubblica (io penso..). La seconda conviene metterla offline.
E’ il mittico e discusso openssl che ve la genera con un comando suppergiù così:
openssl req -nodes -newkey rsa:2048 -sha256 -keyout myserver.key -out server.csr

in cui gli DOVETE specificare il CN giusto!

1. dal pannello dei domini fare richiesta di un certificato SSL a Gandi, mandandogli il vostro .csr
2. Gandi verifica che voi abbiate i giusti permessi su quel dominio facendo una verifica da DNS, la prima 25 minuti dopo la richiesta e poi .. dicono 5 min in 5 min. Oppure da file TXT, quindi ce la si cava da ftp 🙂
3. dalla parte dell’ hosting/server metteteci la vostra chiave privata e il cvr che avrete ricevuto dalla certification autority. E qiundi anche nel phpmyadmin dove avete il db.

Gandi dice che 24 ore ci vogliono..
Speriamobbbene.
POi l’ultimo passaggio per WP..
Dicono: nell’htaccess

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.tuosito.tuaestensione/$1 [R,L]
</IfModule>

E in General settings metterci:
https://
e PARE FUNZIONARE TUTTO!
MOre info:
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#11-use-2048-bit-private-keys
https://wiki.gandi.net/en/dns/zone/a-record