Quelques chiffres supplémentaires pour mon travail et mon Master en général :
Avec pas mal de retard, hop une année de plus. Ca me fait maintenant 20 ans et 6 ans d'expérience :)
Rendu vendredi 16 février 2007 à 11h10 et défendu le vendredi suivant, soit le 23 février à 10h30, voici quelques chiffres au sujet de mon travail de Master :
Analyse et ingénierie inverse de récepteur satellite Free-To-Air
L'argent n'est pas une finalité, mais un moyen.Cette phrase qui résonne dans ma tête depuis sa rédaction par Tristan Nitot, directeur de Mozilla Europe (voir l'article en question : les revenus du projet Mozilla), est le départ de cette digression sur mon dégout par rapport à la société capitaliste actuelle.
C'est annoncé officiellement par le mainteneur actuel du projet, je prête mes 10 doigts pour le développement du paquet PEAR::Mail_Queue2, qui est une réécriture de PEAR::Mail_Queue. En effet ce dernier souffre, comme on peut le lire sur l'interface reportant les bugs, de problèmes internes assez ennuyeux et qui ne peuvent pas être corrigés sans casser la compatibilité arrière (backward compatibility, ou BC pour les intimes).
Comme le paquet PEAR::Mail_Queue est noté comme stable, la BC doit être gardée, d'où le paquet Mail_Queue2.
Au menu :
Le tarpitting (désolé maman pour l'utilisation d'un mot d'anglais de plus dans mes billets) est un concept émergeant dans le domaine de la protection des mails.
Comme on s'aperçoit qu'on est mal embranché pour réduire la quantité de spam (voir We are loosing this war badly), des solutions en désespoir de cause se mettent petit à petit en place : autant essayer d'ennuyer le plus possible les spammers, en ajoutant un délai lors de la réception d'emails. La constatation est simple : si pour délivrer un mail, on ajoute un temps d'attente d'une seconde, l'utilisateur normal ne sera pas pénaliser car il n'est pas à une seconde près, mais le spammer qui envoie 1'000'000 de spam se verra pénaliser d'un million de seconde d'attente, soit plus de 11 jours. Bien sûr il peutva paralléliser l'envoi de ses mails, mais cela ne va réduire que linéairement son temps de pénalité.
De plus en plus de solution de la sorte voient le jour (principalement les systèmes de greylisting implémentent le tarpitting), et personnellement j'encourage fortement ce genre de solutions : si le mail courant est détecté comme du spam (pour éviter de reproduire ce couteux temps d'attente aux mailing "propres"), je temporise sa réception.
Spammers, chez moi vous allez perdre votre argent, car le temps, c'est de l'argent !
Dans la majorité des espaces requierant une authentification sur un site web, le soin du suivi de l'utilisateur est laissé aux sessions, ces petits cookies qui viennent se placer chez le client afin de permettre à l'application web de le reconnaitre lors du passage à la page suivante.
Ce modèle de sécurité a du être imaginé à cause de la nature "connexionless" du protocole HTTP, c'est-à-dire la fermeture de la connexion TCP au serveur entre 2 chargements de page consécutifs (contrairement aux modèles de connexions "continues").
Malheureusement différentes techniques pour voler ces informations de sessions existent, elles se nomment credential token stealing, et sont souvent réalisables grâce à des failles de type XSS.
Cet article va expliquer quel est le point faible des sessions, ainsi que présenter une solution pour en améliorer la sécurité. Un exemple d'implémentation sera une fois de plus donné en PHP.
Problèmes des sessions
Le problème lié aux sessions est que l'identité de l'utilisateur, une fois identifiée, repose entièrement sur ce cookie. Si une personne malveillante parvient à obtenir la valeur du cookie, elle pourra alors se faire passer pour la personne légitime aux yeux de l'application.
Meilleure emprunte (fingerprint)
Une première amélioration est d'associer la valeur du cookie à d'autres éléments qu'une personne malveillante ne peut pas modifier : l'ip de connexion, la signature du navigateur, etc...
Tous ces éléments combinés ensemble donnent ce qu'on appelle l'emprunte de la session, et tous ces éléments sont nécessaires pour pouvoir usurper une identité. La principale difficulté est l'adresse ip de connexion, mais si la personne malveillante est sur le même sous-réseau que la personne légitime, l'adresse ip n'est plus un problème. Autre désavantage d'un fingerprinting étendu, si la personne légitime est sur une connexion à adresse ip dynamique, elle devra se réauthentifier à chaque changement d'adresse ip.
ID de session temporaire
Une autre amélioration est la regénération dynamique de la valeur du cookie. A chaque nouvelle connexion, on test si l'utilisateur est légitime, et on génère une nouvelle valeur qu'on lui envoie.
Si une personne malveillante arrive à voler un cookie, sa valeur ne sera que temporaire et dès le prochain chargement de page, la valeur volée devient obsolète.
Mais cela est aussi vrai à l'inverse, si la personne malveillante arrive à usurper l'identité avant que la personne légitime ne redemande une page, c'est la personne légitime qui sera déconnectée du site.
Implémentation en PHP
Une combinaison des 2 méthodes améliorera la sécurité des sessions, sans pour autant la rendre infaillible.
Voici une petite implémentation en PHP :
<?php
/*
* Inspirated from SecureSession class
* initially written by Vagharshak Tozalakyan <vagh@armdex.com>
*/
class SecureSession {
private $_check_browser;
private $_check_ip_blocks = 0;
private $_padding = '*ftt56+g zwc%&gh7/3-lf%254*6c_qm';
private $_regenerate_id = true;
private $_session_var_name = __CLASS__;
public function _construct($check_browser = true,
$check_ip_block = 0, $regenerate_id = true)
{
$this->_check_browser = $check_browser;
$this->_check_ip_block = $check_ip_block;
$this->_regenerate_id = $regenerate_id;
$_SESSION[$this->_session_var_name] = $this->_fingerprint();
$this->_regenerateId();
}
public function isValid()
{
$this->_regenerateId();
return (isset($_SESSION[$this->_session_var_name])
&& $_SESSION[$this->_session_var_name] == $this->_fingerprint());
}
private function _fingerprint()
{
$fingerprint = "";
if ($this->_check_browser) {
$fingerprint .= $_SERVER['HTTP_USER_AGENT'];
}
if ($this->_check_ip_blocks) {
$num_blocks = min(abs(intval($this->check_ip_blocks)), 4);
$blocks = explode('.', $_SERVER['REMOTE_ADDR']);
for ($i=0; $i<$num_blocks; $i++) {
$fingerprint .= $blocks[$i] . '.';
}
}
return sha1($fingerprint . $this->_padding);
}
private function _regenerateId()
{
if ($this->_regenerate_id && function_exists('session_regenerate_id')) {
session_regenerate_id(true);
}
}
}
?>
Voilà que je me surprends à ajouter subtilement des ; à la fin des lignes d'une lettre de demande de congé pour l'armée...
Cette fois mes craintes se justifient : je suis vraiment un geek.
Non content de perdre la guerre du spam, les providers contre-attaques.
Relayé par Rags, voici le mail explicatif de Green :
Chers clients de green.ch
Dans le cadre d'un projet commun, les 4 grands fournisseurs de service internet en
Suisse (Bluewin, Cablecom, green.ch et Sunrise) mettent en place des mesures pour
combattre l'affluence massive des spams. La 1.ère étape est l'imposition de
l'authentification du serveur SMTP (Simple Mail Transfert Protocole). Cela signifie
que votre programme eMail, pour la récéption et l'envoi des emails, doit toujours
s'authentifier au niveau du serveur mail avec un nom d'utilisateur et mot de passe.
Il est possible que cela soit déjà le cas à votre niveau. Pour être sûr, nous vous
invitons à procéder à une vérification.
Le guide pour le paramétrage exacte ainsi que la configuration de votre compte eMail
se trouve ici: http://dtg.green.ch nous vous invitons à suivre la démarche pas à
pas.
Si vous utilisez exclusivement le Webmail pour vos eMails, vous ne devez rien
entreprendre.
Il est préférable d'effectuer le contrôle tout de suite afin de vous assurer que vos
eMails seront aussi envoyés à l'avenir.
Nous vous remercions de votre coopération.
Avec nos meilleures salutations
Votre équipe de support de green.ch
hotline, et que vous les avez former pour répondre à la question : "Je reçois toujours autant de spam, que faire ?".
