Dal punto di vista grafico questa versione di WordPress mostra alcune modifiche all’interfaccia della DashBoard, menu a tendina, top menu modificato con integrazione del template e dei plugin più utilizzati, mentre per gli sviluppatori è stato implementato un nuovo motore JQuery, una performante gestione del permalink e l’editor di nuove API.

La chicca più interessante sembra essere il supporto di grafica per dispositivi tablet, che promette un’esperienza senza paragoni nelle pagine create con il nostro CMS preferito. Potrete effettuare l’aggiornamento direttamente dall’area amministrativa del vostro WordPress o eseguendo il download cliccando qui.

Al seguente link è possibile visualizzare l’elenco di tutti i miglioramenti apportati:

http://codex.wordpress.org/Version_3.3

Prima di eseguire l’aggiornamento a WordPress 3.3, vi consiglio caldamente di eseguire un backup di sicurezza sia del vostro spazio web che del database e di stare molto attenti con i vostri plugin di cui allo stato attuale non è garantito il funzionamento. Bisognerà aspettare i relativi aggiornamenti!

Per fortuna arrivarono i Content Management System, più conosciuti come CMS.

Qualche povero tizio, martoriato come il sottoscritto, ma con più pazienza e capacità di me e della maggior parte dell’umanità, ha avuto la brillante idea di semplificare la vita a se stesso e a tutto il mondo: perchè perdere ore a scrivere righe di codice quando posso creare una piattaforma che mi permetta di aggiornare una gran mole di dati con pochi semplici click?

Ed ecco che i CMS spuntarono come funghi, ognuno con uno scopo differente, ognuno con la Sua utilità e caratteristiche, molti Open Source e GRATUITI, fino a creare delle sottocategorie in base al loro utilizzo.

Allo stato attuale esistono centinaia di progetti per CMS di vario genere e quando qualcuno mi chiede “Cosa devo fare per farmi il mio sito?” la mia risposta è “cosa VUOI fare per il tuo sito? Di sicuro c’è il CMS giusto per te!!“.

Di seguito elencherò in ordine alfabetico una serie di CMS ed applicativi tra i più conosciuti ed utilizzati con una breve descrizione ed il sito di riferimento per guide e downloads:

Coppermine (galleria fotografica)

piattaforma multiuso pieno di funzionalità con gestione integrata delle immagini tramite le librerie GD o ImageMagick, scritto in PHP, necessita di un Database MySQL

Sito ufficiale

Sito ufficiale supporto italiano

Drupal (cms)

gestore di contenuti (CMS) Open Source realizzato in PHP, che consente di realizzare una grande varietà di siti Web basati sulla logica contenuto/commenti. Le sue doti di robustezza, sicurezza e flessibilità ne stanno decretando la diffusione a livello mondiale

Sito ufficiale

Sito ufficiale supporto italiano

e107 (cms)

sistema di gestione dei contenuti scritto in PHP e utilizza il popolare sistema di database open source MySQL per la memorizzazione dei contenuti.

Sito ufficiale

Sito ufficiale supporto italiano

Joomla! (cms)

gestore di contenuti per la realizzazione di siti Internet dinamici, è gratuito, per il suo utilizzo non sono necessarie conoscenze di linguaggi di programmazione e può essere utilizzato anche per scopi commerciali

Sito ufficiale

Sito ufficiale supporto italiano

Magento (ecommerce)

piattaforma ricca di funzionalità costruita su tecnologia OpenSource flessibile e personalizzabile

Sito ufficiale

Sito ufficiale supporto italiano

MediaWiki (enciclopedia)

pacchetto di software libero ed open source wiki originariamente scritto per Wikipedia. Attualmente viene usato anche per gli altri progetti no profit della Wikimedia Foundation e per altri wiki

Sito ufficiale

Sito ufficiale supporto italiano

Moodle (e-learning)

noto anche come Learning Management System (LMS) o Virtual Learning Environment (VLE), è una applicazione web libera che i formatori possono utilizzare per creare siti di formazione efficaci

Sito ufficiale

Sito ufficiale supporto italiano

PhpBB (forum)

forum free  con funzionalità di bacheca virtuale che può essere utilizzato per rimanere in contatto con un gruppo di persone o per costruire integralmente il vostro sito web

Sito ufficiale

Sito ufficiale supporto italiano

PhpList (mailing list)

gestore di mailing list e news letter, semplice e integrabile con qualsiasi cms

Sito ufficiale

Sito ufficiale supporto italiano

PivotX (blog)

applicativo free da utilizzare per il mantenimento di siti dinamici come blog, giornali online e siti con frequenti aggiornamenti

Sito ufficiale

non è presente supporto in lingua italiana

PrestaShop (ecommerce)

ecommerce OpenSource gratuito, completamente personalizzabile, vanta un premio come miglior piattaforma OpenSource per il 2010

Sito ufficiale

Sito ufficiale supporto italiano

vBullettin (forum)

sistema a pagamento di gestione di forum, prodotto dalla Jelsoft Enterprises, scritto in PHP e basato su database MySQL permette la gestione di contenuti come un cms

Sito ufficiale

Sito ufficiale supporto italiano

WordPress (blog)

applicativo web Open Source gratuito, basato su PHP e MySQL, permette la creazione di siti web o blog, completamente personalizzabile può essere arricchito di funzionalità tramite appositi componenti aggiuntivi. Questo sito è realizzato con piattaforma WordPress

Sito ufficiale

Sito ufficiale supporto italiano

 ZenCart (ecommerce)

sistema di carrello elettronico open source completo, gratuito e di notevole facilità d’uso

Sito ufficiale

Sito ufficiale supporto italiano

ZenPhoto (galleria fotografica)

applicativo web per la gestione semplificata di galleria di immagini, personalizzabile

Sito ufficiale

non è presente supporto in lingua italiana

Una volta selezionata la piattaforma ideale alle nostre esigenze dovremo verificare quali requisiti hardware vengono richiesti (tipologia di spazio web e tipologia di Database). Questi requisiti vengono in genere illustrati in apposite sezioni del sito di supporto o nelle guide all’installazione.

I CMS elencati richiedono principalmente spazi web basati su sistema operativo Linux, con webserver Apache, Database MySQL e supporto per il linguaggio PHP. Questa configurazione viene definita LAMP e ve ne parlerò nella seconda parte di questa guida.

Per ora vi lascio all’ardua scelta di quale sia il CMS fatto apposta per voi.

Le principali novità e fix riguardano:

• Migliorie di sicurezza e delle query di tassonomia
• Fix di sicurezza del redirect canonical redirects
• Fix di sicurezza media
• Aggiunta prevenzione da azioni malevole tramite file host
• Pulizia del vecchio file di importazione di WordPress se l’importazione non giunge a termine.
• Aggiunta protezione “clickjacking”

Provvedere quanto prima ad aggiornare il vostro WordPress dall’Area Admin o scaricandolo da qui.

FONTE: http://www.wordpress-it.it/2011/05/25/wordpress-3-1-3-in-inglese/

Armato di tempo libero ho deciso di crearlo e a questo link potrete trovare il plugin che ho sviluppato: wp-users-page.

Utilizzando un semplice shortcode o tag all’interno di una pagina o post si potranno visualizzare tutti gli utenti appartenenti ad un Gruppo (Admin, Editor, Author, Contributor,Subscriber) mostrando ognuno in un riquadro con:

• Nome
• Ruolo
• Descrizione Breve
• Avatar

Testatelo e datemi il vostro giudizio

Utilizzando WordPress davo per scontato, ahimé, che ci fosse una funzione o un plugin che permettessero di realizzare tale pagina in poco tempo.

Sono rimasto deluso dallo scoprire che non esisteva nulla del genere e così ho deciso di sviluppare da me il Plugin che svolge questa funzione.

Il plugin si chiama wp-users-page e utilizzando un semplice tag o shortcode permette di elencare tutti gli utenti facenti parte di un determinato ruolo.

Ricordo che in WordPress i ruoli predefiniti sono i seguenti:

• Admin
• Editor
• Author
• Contributor
• Subscriber

Installazione

L’installazione avviene come per tutti i plugins di WordPress.

1. Scaricate il file dal seguente link:
   
   Clicca su Mi Piace per scaricare il file!
2. Estraete la cartella “wp-users-page”
3. Uploadate la cartella all’interno di “wp-content/plugins” del vostro WordPress
4. Attivate il plugin dal menu”Plugin” dell’Admin del WordPress

Utilizzo

Una volta installato il plugin basterà inserire il tag seguente :

[wpuserspage role="<role>"]

e al posto del Tag apparirà la lista degli utenti.

Di seguito tutte le configurazioni del tag:

[wpuserspage role="administrator"] -> per far comparire i soli utenti Amministratori

[wpuserspage role="editor"] -> per far comparire i soli utenti Editori

[wpuserspage role="author"] -> per far comparire i soli utenti Autori

[wpuserspage role="contributor"] -> per far comparire i soli utenti Collaboratori

[wpuserspage role="subscriber"] -> per far comparire i soli utenti Sottoscrittori

L’utilizzo è molto semplice e il risultato sarà una pagina che riporta le seguenti informazioni:

• Nome utente
• Avatar (se impostato nel Profilo utente e se abilitati in Impostazioni -> Discussioni)
• Breve descrizione (se impostata nel Profilo utente)
• Ruolo nello Staff
• Link a tutti gli articoli

Demo Link: http://www.capn3m0.org/staff

Wp Users Page DOWNLOAD

N.B. – Questa è la versione 0.1 e può essere considerata una beta. E’ stata testata su tutte le versioni 3.x. Se dovessero riscontrarsi problemi contattatemi all’indirizzo capn3m0@capn3m0.org o tramite il Form Contatti.

Per Joomla, che attualmente sta portando avanti le due famiglie 1.5.x e 1.6.x sono state rilasciate le versioni 1.5.23 e 1.6.3 (c’è stata anche una 1.6.2 che ha avuto una vita molto breve).

La 1.5.23 è una security release in quanto una vulnerabilità nelle precedenti versioni permetteva di generare un errore che printava a video la path assoluta del sito (Information Disclosure). Era una informazione in più in mano all’eventuale hacker ma nulla di realmente pericoloso.

Joomla 1.5.23

Le versione 1.6.3, invece, è una bug fix che risolve alcuni problemi emersi con questa nuova versione.

Al link sottostante potrete trovare maggiori informazioni e consultando il Changelog potrete leggere tutte le modifiche/correzioni che sono state apportate.

Joomla 1.6.3

Per quanto riguarda WordPress, invece, sono state rilasciate a distanza di pochi giorni le versioni 3.1.1 e, l’ultima, la 3.1.2 che corregge una vulnerabilità (security release) che permetteva agli utenti “Contributor” di postare bypassando la fase di revisione obbligatoria da parte dell’Admin.

WordPress 3.1.2

Si consiglia a tutti di effettuare gli upgrade dei propri Cms e, soprattutto, di monitorare costantemente la pubblicazione di nuove release, soprattutto quando si tratta di security release

Spesso capita d non ricordarsi la password o, a volte (purtroppo), ci troviamo la password cambiata in seguito a qualche attacco hacker.

Per poterla ripristinare basterà copiare il file “wordpress_reset_pwd.php” nella root del vostro WordPress e successivamente richiamarlo via Web all’indirizzo:

http://www.dominio.com/<root_wordpress>/wordpress_reset_pwd.php

Vi apparirà un form minimal come quello della seguente figura:

Basterà inserire l’username dell’utente e la password che si vuole impostare e il gioco è fatto!!

Download wordpress_reset_pwd.php

Per analizzare le performance e l’impatto delle nostre modifiche su di esse ci siamo serviti del plugin “YSlow” di Yahoo e “PageSpeed” di Google che offrono la possibilità di visionare statistiche e analisi dettagliate delle varie aree del sito suggerendo le modifiche da effettuare per ottenere un punteggio migliore.

Come funziona?

Solitamente i punteggi assegnati da YSlow e PageSpeed si basano su valutazioni effettuate sui singoli oggetti di una pagina Web quali i Css, i Javacript, la loro posizione nella pagina, il peso della pagina etc.

Tutti questi fattori hanno pesi diversi ai fini della valutazione finale ma, per ottimizzare le performance del sito è necessario concentrarsi sul numero di richieste Http generate, la posizione dei Javascript e il peso della pagina che, ovviamente, è composto da tutti i singoli oggetti quali immagini, css/js, codice,etc.

Il plugin W3 Total Cache agisce in particolar modo sul peso finale della pagina e sul numero di richieste Http generate. Come è noto al momento della richiesta di una pagina il Server provvede ad inviare tutti i singoli oggetti nell’ordine previsto nel codice sorgente al Browser dell’utente. Questo avviene ad ogni click di ogni utente. Se però, come è probabile, un articolo una volta pubblicato rimane invariato per giorni non è performante far elaborare ogni volta l’intera pagina al WebServer. Il plugin serve proprio a questo ossia a creare una copia “html” dell’intera pagina elaborata dal Browser per fare in modo che alle successive richieste venga servita direttamente la pagina html (l’output generato dal Server) invece che farla elaborare ogni volta.

In questo modo, analizzando una pagina con un Http Viewer come Fiddler o Tamper Data si noterà che la prima richiesta genererà per esempio

100 richieste Http x 400 Kb x 5 secondi

mentre il seguente refresh solo

35 richieste Http x 114 kb x 2,4 secondi.

Oltre ciò è possibile applicare una compressione all’output così da ridurre ulteriormente i tempi di caricamento.

Procediamo!

Per prima cosa sono necessari i seguenti plugins:

• W3 Total Cache by W3 EDGE – consente di gestire in maniera avanzata il caching delle pagine, del Database e il Minify dei Css e Javascript. A mio avviso si tratta del miglior plugin disponibile attualmente per la gestione della cache e non appena lo si installa e attiva si riscontrano subito dei miglioramenti nei tempi di caricamento.
• No Frames -  permette di evitare che il proprio sito venga visualizzato in Frames aumentandone così il punteggio Seo.
• Javascript To Footer – utilizzando questo plugin tutti gli scripts Javascript del proprio sito verrano posizionati a fine pagina garantendo una maggior velocità di caricamento del sito.
• SEO Friendly Images – Aggiunge automaticamente i tag Html “ALT” e “TITLE” alle immagini utilizzate nei post così come consigliato dal W3C.

W3 Total Cache by W3 EDGE

Per il plugin si suddivide in più aree ognuna delle quali è personalizzabile dall’utente.

A seconda dell’Hosting utilizzato alcune funzionalità possono non essere supportate e per evitare di impazzire nella configurazione ho provveduto a creare il file di configurazione adatto all’Hosting Linux Aruba. Se dovessero verificarsi degli errori nel suo utilizzo non esistate a contattarmi.

W3 Total Cache Configuration – Hosting Linux Aruba

Una volta scaricato è necessario modificare il riferimento alla sitemap. Per fare ciò aprite il file e andate alla riga 407 che apparirà nel seguente modo:

‘pgcache.prime.sitemap’ => ‘http://www.xxxxxxx.xxx/sitemap.xml’,

e sostituite l’url con quello della vostra sitemap. Per questo sito, quindi, andrà inserito:

‘pgcache.prime.sitemap’ => ‘http://www.capn3m0.org/sitemap.xml’,

Eseguita tale modifica rinominate il file da:

w3-total-cache-config.txt

a

w3-total-cache-config.php

ed importatelo nel plugin.

Accedete al vostro Pannello Admin del WordPress e seguite il percorso:

Performace -> General Settings

In basso troverete le opzioni di “Import/Export” come nella seguente figura:

Importate il file “w3-total-cache-config.php” e il gioco è fatto!

Navigate un po’ il sito e tornate sulle stesse pagine almeno due volte per verificare come appaiono dopo che sono state cachate. Se si dovessero verificare dei problemi con Javascript o Css provvedete a disabilitare tutte le opzioni di Minify del plugin.

N.B. – Potrebbero verificarsi degli errori “500 Internal Server Error” poiché il plugin modifica automaticamente il file “.htaccess” di WordPress e non tutti gli Shared Hosting supportano alcune istruzioni che vengono inserite. No panic!

Scaricate il file “.htaccess” seguente e sostituitelo a quell presente nella root di WordPress e il problema è risolto.

.htaccess WordPress + W3 Total Cache + Mod_Deflate On

Come indicato all’inizio dell’articolo oltre al caching, che riduce notevolmente il numero di richieste e la dimensione delle pagine, è possibile applicare una ulteriore compressione. Nel file .htaccess fornito ho provveduto ad inserire le istruzioni che abilitano il Mod_Deflate di Apache che, appunto, applicano la compressione all’output inviato all’utente.

Le righe che svolgono tale compito sono le seguenti:

SetOutputFilter DEFLATE
AddOutputFilter DEFLATE text/plain
AddOutputFilter DEFLATE text/xml
AddOutputFilter DEFLATE application/xhtml+xml
AddOutputFilter DEFLATE text/css
AddOutputFilter DEFLATE application/xml
AddOutputFilter DEFLATE image/svg+xml
AddOutputFilter DEFLATE application/rss+xml
AddOutputFilter DEFLATE application/atom_xml
AddOutputFilter DEFLATE application/x-javascript
AddOutputFilter DEFLATE application/x-httpd-php
AddOutputFilter DEFLATE application/x-httpd-fastphp
AddOutputFilter DEFLATE application/x-httpd-eruby
AddOutputFilter DEFLATE text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

In seguito procedete con l’installazione degli altri plugins indicati; la loro configurazione di default andrà bene.

A questo punto le operazioni sono terminate e, se tutto è andato bene, il vostro sito guadagnerà qualche punto nelle valutazioni di YSlow e PageSpeed.

Ma non ci fermiamo qui!

Faccio presente che in alcuni Shared Hosting è presente anche il Modulo Apache chiamato “Mod_expire” che consente di indicare al Browser di salvare gli oggetti nella cache locale del Pc per un periodo da noi prefissato.

Questa configurazione aumenta notevolemente i tempi di caricamento del sito poiché tutti gli oggetti quali parti del template, immagini, css e javascript saranno già presenti nell’Hard Disk del visitatore e pertanto i dati REALMENTE da scaricare saranno minimi.

Come è facile intuire aprendo due articoli a caso di questo sito le differenze tra le due pagine sono limitate all’immagine dell’articolo, il testo di esso e altri pochissimi dati. Ogni volta che navighiamo, quindi, scarichiamo per intero delle pagine da 400 kb (template,css,testo,immagini,javascript,video,etc) in cui in realtà le differenze sono solo di 10 kb (testo,immagini).

Il Mod_Expire consente proprio di evitare questo inutile spreco di banda, richieste DNS e request HTTP, facendo salvare tutto nel Browser locale e interrogando realmente il sito solo per richiedere i pochi dati necessari.

Ecco di seguito i risultati ottenuti applicando quanto indicato in questo articolo:

Come si può constatare è stato classificato come Grade B in YSlow tra gli “Smaller Site or Blog” e le richieste sono passate da 49 a 10 con una riduzione di 300k sul peso delle pagine.

Postate i risultati per i vostri siti !!!

Ciao a tutti, dopo diverso tempo dall’ultimo post pubblico una vulnerabilità che potrà creare non pochi problemi agli utilizzatori del noto Cms Joomla.

E’ stata pubblicata da poco una vulnerabilità di tipo XSS per tutte le versioni < =1.5.20, ossia tutte le versioni attualmente pubblicate.

Tale exploit sfrutta una falla nella verifica delle variabili GET encodate eseguendo quindi il codice Javascript che si passa all’applicativo.

Full Discolsure Advisories

Al seguente video si potrà vedere un Proof of Concept dell’attacco Xss.

Proof of Concept by yehg.net

Un malintenzionato potrebbe sfruttare tale falla per rubare i cookie degli utenti loggati, Administrator compreso, e sfruttarli per modificare pagine o uploadare shell malevole che permetterebbero qualsiasi operazione nello spazio del sito vittima. Una volta rubati i cookie di Admin, infatti, basterà andare nella pagina di edit di uno dei template di default, di solito ‘beez’, e successivamente editare la pagina con il codice di una shell php quali c99 o r57.

Provvedero’ ad aggiornare il post quanto prima con tutti i riferimenti e i dettagli (sono in treno con l’app WordPress per Blackberry ).

AGGIORNAMENTO #1
Lo staff di Joomla ha provveduto a rilasciare la nuova versione dove tale problema e’ stato fixato.

Chiunque utilizzi questo Cms e’ invitato ad effettuare l’upgrade alla versione 1.5.21

Joomla 1.5.21 – Official Site

Joomla Security News

Testando i link che venivano segnalati in errore, però, mi sono accorto che si dividevano in 3 “sottocategorie”:

• Alcuni venivano correttamente caricati dal Browser;
• Alcuni erano riferimenti al plugin “Global Translator” e, quindi, a file non più in cache o non disponibili in quel momento;
• Altri erano nel formato “url/feed/” e se caricati generavano un errore di “Redirect Loop“.

Per quanto riguarda quelli che il Browser caricava correttamente ho analizzado gli Http Header utilizzando il plugin Tamper Data e ho scoperto che rispondevano alla prima Request Htpp con un “301 – Moved Permanently” che poi redirettava alla pagina corretta che rispondeva “200 – Ok“.

Approfondendo le verifiche ho riscontrato che la prima risposta Http variava a seconda del formato dell’url.

Se l’url era scritto nel seguente modo, ossia senza trailing slash:

http://www.dominio.com/tag/tag1

la risposta era “301 – Moved Permanently“.

Se l’url veniva scritto con il trailing slash, ossia:

http://www.dominio.com/tag/tag1/

allora la risposta era “200 – Ok“.

A questo punto ho cercato in Rete informazioni riguardo la presenza del trailing slash o meno e ho trovato un plugin per WordPress chiamato Permalink Trailing Slash Fixer che consente di modificare le regole di Rewrite aggiungendo sempre il trailing slash garantendo, di fatto, che la prima risposta del WebServer sia “200 – Ok“.

Per quanto riguarda, invece, l’errore di “Redirect Loop” che sembra abbastanza frequente per chi utilizza WordPress ho trovato diversi tricks da attuare nella configurazione del sito per risolverli.

Il primo consiste nel modificare l’url impostato nel Menu:

Impostazioni -> Generale -> Indirizzo del blog (URL)

Il consiglio è di sostituire l’url, che dovrebbe essere:

http://www.dominio.com

con

http://www.dominio.com/index.php

Oltre ciò è necessario installare un plugin che provvede a disabilitare i “Canonical Url Redirect” che sono gli artefici dell’errore del “Redirect Loop“. Il plugin si chiama “Disable Canonical URL Redirection” e lo potete scaricare qui.

Una volta apportate queste modifiche ed abilitati i plugin gli errori nei Google Webmaster Tools sono finiti e non si verificano più spiacevoli “Redirect Loop“.

La notizia non era molto dettagliata poiché la vulnerabilità era stata annunciata molto genericamente come una vulnerabilità che permetteva di “aggirare le limitazioni ai nomi dei file in determinate configurazioni Apache”. Ora che è stata patchata, come spesso accade, iniziano a trovarsi maggiori informazioni e Proof of Concept.

In realtà la vulnerabilità permette di uploadare file bypassando il controllo della tipologia di file e permettendo, quindi, di uploadare script php e similari che possono poi essere richiamati da colui che attacca. Affligge tutte le versioni inferiori alla 2.8.5 (compresa) perciò provvedete quanto prima ad aggiornare il vostro blog.

La notizia era stata pubblicata l’11 Novembre scorso nella nota Mailing List Full Disclosure dove Dawid Golunski ha pubblicato un Proof Of Concept che potete leggere a questo link. Praticamente spiega che la verifica del file uploadato avviene confrontando l’estensione del file, estrapolata tramite una Regular Expression, con un array dei Mime Type permessi.

La Regular Expression, però, unita al fatto che i WebServer Apache (solamente in una particolare configurazione spiegata qui) consentono di creare file nel formato

filename.ext1.ext2

può essere bypassata uploadando un file contenente codice Php e assegnandogli un nome come il seguente:

phpinfo.php.jpg

In questo modo la verifica del file applicata da WordPress estrapolerebbe tramite la RegEx l’estensione “.jpg” e successivamente, verificandola con l’Array dei Mime Types ammessi, permetterebbe al file di essere uploadato scambiandolo per un’immagine.

Una volta fatto ciò chi attacca potrà richiamare lo script digitando la path standard dei file uploadati di WordPress ossia:

http:///wp-content/uploads/2009//phpinfo.php.jpg

Questa vulnerabilità, sebbene grave, non dovrebbe causare gravi danni visto che chi attaca deve essere un membro dello staff con privilegi di pubblicazione come era stato annunciato in occasione della 2.8.6.

Resta invece ancora sconosciuta la vulnerabilità di Cross Site Scripting scoperta da Benjamin Flesch sempre nella versione 2.8.5 di WordPress.

Eccovi alcuni link correlati:

Proof Of Concepts – WordPress <= 2.8.5 Unrestricted File Upload Arbitrary PHP Code Execution by Dawid Golunski

Vupen – WordPress Arbitrary File Upload and Cross Site Scripting Vulnerabilities

SecurityFocus – WordPress Unspecified Cross Site Scripting Vulnerability

La prima è una vulnerabilità del componente “Press This” (Pubblicalo in italiano) scoperta da Benjamin Flesch che permetteva di eseguire XSS (Cross Site Scripting) agli utenti registrati con privilegi di pubblicazione.

La seconda, invece, è stata scoperta da Dawid Golunski e consentiva di aggirare le limitazioni ai nomi dei file in determinate configurazioni Apache.

In attesa della versione WordPress 2.9 consiglio a tutti di provvedere ad aggiornare la propria versione tramite la funzione di “Aggiornamento Automatico” che verrà suggerita non appena entrerete nella vostra Bacheca.

Chi utilizzava  una versione precedente ha avuto la possibilità di effettuare l’aggiornamento automatico senza dover stare a scaricare il pacchetto, unzipparlo, uploadarlo via Ftp etc..

Terminato l’aggiornamento  alcuni hanno avuto la triste sorpresa di riscontrare l’errore “500 Internal Server Error” su tutte le pagine del proprio sito. Questa problematica si manifesta negli Hosting (nel mio caso Aruba) dove i permessi di default per avere il corretto funzionamento dei file devono essere impostati a CHMOD 0755 (dovuti all’utilizzo del suExec di Apache) dato che l’aggiornamento automatico comporta il reset dei permessi a CHMOD 0644.

L’errore è facilmente risolvibile reimpostando i permessi CHMOD corretti per tutti i file e cartelle che compongono il WordPress.

La community di WordPress aveva rilasciato già in data 5/12/2008 una modifica da apportare al file “wp-config.php” per evitare il manifestarsi di questo problema.

ARTICOLO ORIGINALE

Tale modifica consente di impostare manualmente i permessi CHMOD di default (attualmente sono a 0644) da assegnare ai file del WordPress in occasione di aggiornamenti o similari.

Per implementarlo è sufficiente seguire questi pochi semplici passi:

1) Aprire con un Editor il file “wp-config.php“;

2) Aggiungere le seguenti due righe in qualsiasi punto del file:

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

Fine! d’ora in poi tutti gli eventuali aggiornamenti automatici assegneranno di default i permessi 0755