Protezione WebServices e comunicazione

Avevamo visto in un articolo precedente come proteggere i siti in fase di sviluppo tramite .htaccess e .htpassword, ed effettivamente è un sistema molto comodo; tuttavia cosa succede quando è necessario sviluppare all'interno del sito dei WebServices che devono essere accessibili da remoto?

Vediamo come possiamo risolvere questo problema, sia ricorrendo all'autenticazione nella chimatada codice PHP che consentendo l'accesso da determinate macchine senza autenticazione.

Autenticazione nelle chiamate

Nel primo caso la procedura da utilizzare è quella di effettuare un'autenticazione usando le credenziali indicate all'interno del'.htpasswd; eventualmente create delle credenziali ad-hoc seguendo le indicazioni dell'articolo precedente.

Una volta che il nostro servizio (rigorosamente RESTFUL) è funzionante, possiamo utilizzare il seguente codice PHP che permette l'accesso tramite autenticazione su .htpassws:

<?php
// Nome utente
$username = 'test';
// Password
$password = 'test';
// Creo l'header con le credenziali di autenticazione
$cred = sprintf('Authorization: Basic %s', base64_encode($username . ':' . $password));
// Creo gli options per la chiamata
$opts = array(
  'http' => array(
    'method' => 'GET',
    'header' => $cred,
  )
);
// Creo lo stream context
$ctx  = stream_context_create($opts);
// Url del servizio
$url = 'http://mavimo.org/crss';
// Ottengo la risposta della chiamata
$rss = file_get_contents($url, FALSE, $ctx);

// Elaboro il contenuto della chiamata.. // ... ?>

Lo svantaggio di procedere in questo modo è dato dal tempo necessario a far si che la richiesta venga autenticata e poi venga effettuata la richiesta con successiva risposta; fino a che si tratta di una richiesta una tantum non dovrebbe comportare grosse problematiche, ma nel caso di un numero elevato di richieste, magari per la gestione di operazioni di sincronizzazioni tra server, può diventare un problema a causa della latenza del processo.

Altro problema derivato da questo tipo di protezione è dato dal fatto che il traffico potrebbe essere sniffate e dato che i dadi sono presente solamente encodati in base 64 è possibile che qualcuno possa ottenere le credenziali di accesso al nostro sistema.

Accesso da IP fidati

La seconda alternativa, consigliabile quando possibile, è di ricorrere all'apertura del canale tra indirizzi IP fidati, per fare questo all'interno della direttiva del nostro .htaccess andiamo ad aggiungere:

AuthUserFile /var/www/MIOSITO/.htpasswd
AuthGroupFile /dev/null
AuthName "SITO PROTETTO"
AuthType Basic
<Limit GET> 
  Allow from 11.22.33.44
  require valid-user
  Satisfy Any
</Limit>

Dove appunto si chiede l'autenticazione di utenti validi, oppure (e questo è dato dalla clausula Stasisfy Any) da richieste provenienti dall'indirizzo IP indicato (che è appunto quello del server fidato da cui possono venire le richeste. Omettendo la regola Satisfy Any devono essere soddisfatte enntrambe le condizioni per poter aver accesso al servizio (e al sito stesso).

A questo punto non ci sono proprio più scuse per NON proteggere il nostro sito (o i nostri WebServices, ovviamente).

EDIT: grazie a eliosh per il lavoro di revisione ;)

Bookmark/Search this post with: