Skip to main content

Comprendre le problème avec le filtrage de Free

Ces jours-ci, vous avez dû en entendre des vertes et des pas mûres sur Free, qui a mis en place (uniquement sur ces nouvelles box Revolution, et donc uniquement une partie de ses abonnés) une option activée par défaut qui permettait de masquer la publicité sur tous les sites Internet (sauf ceux dont il est actionnaire ou partenaire tel quel Le Monde ou Dailymotion). Suite au recadrage de la ministre Fleur Pellerin, Free a désactivé son filtre.

Filtrage, censure, mise en péril du modèle économique de millions de sites web, mise à mal de la neutralité du web… sont les mots que vous avez dû entendre pour qualifier cet acte. Certains articles prennent carrément la défense de Free ; d’autres le désignent comme l’ennemi public numéro un et n’hésitent pas à le lyncher sur la place publique.

Bien que je ne sois pas favorable à ces techniques de filtrage, je trouve qu’il est important de regarder l’affaire d’un oeil objectif afin de bien en comprendre les tenants et les aboutissants, et ne pas s’en tenir à la vision manichéenne « Free cay le bien, la pub nous fait chier » vs. « Free cay le mal, ils censurent le web et tuent des sites webs et des bébés phoques ».

Et j’ai pour cela trouvé deux articles très intéressants : le premier provient de Blogmotion (Pourquoi Free n’aurait pas dû filtrer les publicités), et le deuxième provient de Slate (Free et le filtrage de pubs par défaut: pour ceux qui n’ont pas tout compris).

Je vous suggère la lecture de ces deux articles afin de bien comprendre le problème de fond 🙂 l’article de Blogmotion donne, au passage, les détails techniques de ce filtrage, pour les curieux.

Lire la suite

Comprendre le nommage des fichiers vidéos de séries

Si vous avez un peu l’habitude de vous procurer des vidéos de séries sur Internet, vous aurez sûrement remarqué que le nom du fichier a un formatage bien particulier. Afin de mieux le comprendre, j’ai fait un petit guide, largement inspiré de celui de KooNDeLLiTcH paru il y a plusieurs années, et remis au goût du jour.

Le nom des vidéos

Prenons un exemple : Dexter.S07E10.720p.HDTV.x264-IMMERSE.[eztv]

  • Dexter : le nom de la série
  • S07E10 : la saison et l’épisode
  • 480p, 720p ou 1080p : qualité de la vidéo (essentiellement présent pour les vidéos HD)
  • HDTV : provenance de la source de la vidéo (voir ci-dessous)
  • x264 : codec utilisé (la manière dont le flux vidéo est encodé)
  • IMMERSE : le groupe qui a réalisé la récupération et l’encodage de la vidéo
  • EZTV : le groupe qui a posté la vidéo sur différents sites Internet

Le formalisme est toujours le même, toujours dans cet ordre. Cependant, le titre de l’épisode est parfois indiqué après la saison et le numéro de l’épisode. De plus, le tag de l’uploadeur (ici, EZTV) n’est généralement pas indiqué.

Il est important de conserver le nom complet d’un fichier vidéo. Plusieurs releases vidéo d’un même épisode peuvent exister, et si l’on ne conserve pas ce nom, on a par la suite peu de chances de trouver les sous-titres correspondants. Par exemple, pour l’épisode 3×08 de The Walking Dead, voilà quelques releases qui sont disponibles sur Internet (liste non exhaustive !) :

  • The.Walking.Dead.S03E08.HDTV.x264-2HD
  • The.Walking.Dead.S03E08.720p.HDTV.x264-EVOLVE
  • The.Walking.Dead.S03E08.Made.to.Suffer.720p.WEB.DL.DD5.1.H.264-BTN
  • The.Walking.Dead.S03E08.Made.to.Suffer.1080p.WEB.DL.DD5.1.H.264-BTN

Le site Pre-Search permet de lister toutes les releases existantes pour un même épisode. Par exemple, en saisissant « the.walking.dead.s03e08 » et en tapant sur Entrée, on pourra voir toute la liste des releases disponibles pour cet épisode. En cliquant sur le R vert présent à droite d’une release, on peut lister les trackers BitTorrent l’ayant proposé, par ordre d’apparition.

On peut donc voir quelle plateforme est la plus rapide à proposer un fichier. Toutefois, le nom des plateformes est sous forme raccourcie (exemple : SCC = SceneaCCess, GFT = GFTracker, etc).

Les groupes de releaseurs

Loin de vouloir faire une liste exhaustive tellement il y en a, voilà quelques groupes que l’on est souvent amenés à voir ; ce sont les groupes les plus influents de la Scene.

  • HDTV standard : LOL, AFG, 2HD, ASAP, CRiMSON, LMAO, BAJSKORV, KILLERS, FTP, BiA, FoV
  • HDTV 720p : DIMENSION, EVOLVE, IMMERSE, BAJSKORV, KILLERS, FTP, BiA, FoV
  • Web-DL : CtrlHD, KiNGS, ECI, NTb, BTN, iT00NZ, BS, POD
  • DVD : REWARD, SAiNTS, SPRiNTER, DEMAND, iNGOT, HAGGiS

Les groupes sont généralement propres à des régions données (exemple : LOL et DIMENSION sont américains car ils diffusent des séries américaines, tandis que BiA ou FoV s’occupent plutôt de séries britanniques ; REWARD et SAiNTS quant à eux traitent surtout les DVD, etc).

La qualité des vidéos

À quoi correspond la qualité d’une vidéo ?

  • HDTV : le flux standard diffusé à la télévision américaine ; présence du logo de la chaîne, pubs en bas de l’écran. Parfois, présence de défauts de son ou de vidéo.
  • 720p HDTV : le flux HD diffusé à la télévision américaine ; présence du logo de la chaîne, pubs en bas de l’écran, qualité HD de l’image. Parfois, présence de défauts de son ou de vidéo.
  • Web-DL : la vidéo disponible sur iTunes US ; pas de logo, pas de pubs, qualité HD de l’image, son 5.1. Souvent, pas de Previously in… (dépend des séries).
  • DVDRiP : la même qualité que la HDTV standard, sans le logo, la pub ou les défauts.
  • BDRip ou Blu-Ray : qualité similaire au Web-DL.

Notez que les vidéos Web-DL ont cependant tendance à être un poil plus pâlottes.

Lorsque les releases sont diffusées avec un défaut de son ou d’image, elles sont généralement suivies d’un REPACK (le même groupe diffuse une vidéo propre et exempte de défauts) ou d’une PROPER (un autre groupe diffuse une version propre et corrigée).

Autrefois, on trouvait beaucoup de DSR ou de PDTV. Ces qualités ont aujourd’hui disparu, étant donné l’augmentation de la taille des supports de stockage et ainsi que des débits Internet.

Les caractéristiques des fichiers vidéo

Faisons d’abord le point sur la différence entre codec et conteneur.

Un codec est la façon d’encoder les flux. Pour la vidéo, on a principalement le XviD, le x264, l’AVC1 (MPEG4) ou l’AVC. Pour l’audio, il y a le MP3, mais aussi l’AC3 (aussi appelé Dolby Digital) en 5.1 ou l’AAC en 2.0. Dire qu’une vidéo est « encodée en AVI » est donc faux : elle sera encodée par exemple en XviD, et intégrée dans un conteneur AVI.

Un conteneur, c’est comme son nom l’indique, la façon de contenir le flux vidéo et le flux audio dans un même fichier. Très connu pendant un temps, l’AVI fait place au MP4 et au MKV.

Le conteneur le plus avantageux aujourd’hui est sans aucun doute le MKV. Il permet d’avoir, au sein d’un même fichier, différentes pistes audio (anglais, français et français québécois, par exemple) et différentes pistes de sous-titres (VO et VF, voire même d’autres langues). Et surtout, il est alors facile de switcher entre les unes et les autres : à l’aide du bouton droit de la souris, lorsque l’on est sur VLC, ou à l’aide du menu de langues des lecteurs DVD et box Internet.

Au secours, mes sous-titres sont décalés !

Je laisse cette fois la parole complète à KooNDeLLiTcH, qui explique dans cet article comment réparer des sous-titres décalés. Deux liens de Comment Ça Marche peuvent également être intéressants pour corriger un décalage constant ou un décalage progressif.

En espérant que ce petit guide vous permettra d’y voir plus clair 🙂

Lire la suite

La sécurité des formulaires PHP

Il est un domaine que l’on ne doit pas oublier lorsque l’on réalise des formulaires en PHP, c’est la sécurité. En effet, les formulaires sont très souvent liés à une adresse mail ou à une base de données ; il est donc judicieux de protéger ces éléments-clé d’un système d’information.

Loin d’être un guide absolu dans le domaine, cet article regroupera quelques bonnes pratiques pour sécuriser un formulaire que j’ai glanées au fil du web.

Choisir la méthode du formulaire

Le premier choix qui s’impose lors de la réalisation d’un formulaire, c’est la méthode de transmission des données d’une page à une autre. Il en existe deux : GET, et POST. Alors que la méthode GET transmet les variables récupérées dans un formulaire par l’URL, la méthode POST les transmet de façon masquée.

Il vous faudra donc choisir, au cas par cas, si les variables récupérées peuvent être affichées au visiteur dans l’URL, ou non. Notez que ce n’est pas parce que les variables sont transmises en POST qu’elles sont totalement invisibles, chiffrées ou sécurisées ; il reste possible de les afficher (ou plutôt, de les intercepter) avec des outils.

Les failles XSS (Cross Site Scripting)

Pour profiter d’une faille XSS, l’attaquant va tenter d’insérer un code (JavaScript, le plus souvent) dans un input d’un formulaire non protégé, ceci afin de modifier le fonctionnement de la page. Prenons le cas d’un forum ; un attaquant pourrait, en exploitant une faille XSS, faire en sorte de subtiliser le cookie de connexion de chaque utilisateur qui se connecterait à ce forum. Ou alors, rediriger tous les utilisateurs vers une page de connexion ressemblant trait pour trait à la charte graphique du forum, mais qui en fait ne servirait qu’à récupérer leurs identifiants de connexion.

Les injections SQL

Pour exécuter une injection SQL, l’attaquant va tenter d’insérer un code dans un input d’un formulaire non protégé qui est relié à une base de données. Ce code peut servir à supprimer tout ou partie de la base de données ! Mais dans le pire des cas, une injection SQL peut permettre d’outrepasser le système d’authentification d’un site, afin d’y entrer sans autorisation (et voir, d’y entrer avec les privilèges de l’administrateur).

Insertion dans une base de données

Pour être sûr que des attaquants n’exécutent pas des injections SQL sur notre base de données, nous devons protéger l’insertion d’une saisie utilisateur grâce aux fonctions :

  • mysql_real_escape_string() : échappe les caractères spéciaux (notamment ‘  » et NULL) par un antislashs ; étant donné que c’est une fonction de MySQL, vous aurez besoin de vous connecter à votre base avec un mysql_connect() avant de pouvoir l’utiliser
  • addslashes() : réalise la même chose que mysql_real_escape_string(), mais n’est à utiliser que si vous utilisez un type de base de donnée qui ne propose pas ce genre de fonction

Dans le cas où le site que vous développez ne requiert pas que les utilisateurs aient un jour à saisir du code informatique dans leurs messages, on peut utiliser la fonction strip_tags() afin de purement et simplement supprimer les balises de code HTML ou Javascript des messages des utilisateurs.

Affichage depuis une base de données (ou saisie utilisateur)

Trois fonctions s’offrent à nous pour éviter les attaques XSS. Avant de les utiliser, vous devrez vous demander si vous souhaitez que les utilisateurs puissent stocker du code source dans votre base, ou si vous considérez que rien de ce qui n’entre dans votre base n’a besoin d’être du code. Dans le cas d’un forum par exemple, un utilisateur peut légitimement poster un message avec du code sain (utilisez alors l’une des deux premières fonctions).

  • htmlspecialchars() : encode les caractères < > ‘  » & pour qu’ils soient affichés mais pas exécutés
  • htmlentities() : la même chose que htmlspecialchars(), à la différence qu’elle encode beaucoup plus de caractères ; par exemple, le symbole €, les lettres accentuées é à ù…
  • strip_tags() : supprime carrément toutes les balises contenant < et > qui ne seront pas affichées

Enfin, si vous souhaitez récupérer des données qui ont été insérées en étant protégées par htmlspecialchars(), htmlentities() ou addslashes(), il vous faudra utiliser respectivement htmlspecialchars_decode(), html_entity_decode() et stripslashes().

Exemple concret

Pour finir, voilà un exemple d’un formulaire, avec dessous, la partie « sécurisation » (remarque : ce code sera prochainement obsolète car PHP pousse à l’utilisation de la « PDO » ; voir mon commentaire plus bas pour un exemple d’utilisation) :

<form id="mon_formulaire" method="POST" action="formulaire.php">
	<input name=premier_champ type=text placeholder="Premier champ" required>
	<input name=second_champ type=number placeholder="Second champ" required>
<button type=submit name=envoi>Envoi</button>

<?php
if (isset($_POST['envoi']))
{
	// Connexion à la base de données
	mysql_connect($dbhost, $dbuser, $dbpass);
	mysql_select_db($dbname);
	
	// Sécurisation des données reçues
	$premier_champ = mysql_real_escape_string($premier_champ);
	$second_champ = mysql_real_escape_string($second_champ);
	
	// Création et envoi de la requête
	$sql = 'INSERT INTO ma_table VALUES("'.$premier_champ.'","'.$second_champ.'")'; 
	mysql_query ($sql) or die ('Erreur SQL !'.$sql.'<br />'.mysql_error());  
	
	//Clotûre de la connexion à la base de données.
	mysql_close (); 

	// Affichage des résultats à l'utilisateur
	echo 'Vous avez inséré '.htmlspecialchars($premier_champ).'.';
}
?>
</form>

Voilà donc quelques méthodes simples pour éviter que votre formulaire soit une passoire 🙂 n’hésitez pas à m’indiquer dans les commentaires si vous avez d’autres astuces pour la sécurisation simple des insertions et lectures de base de données.

XKCD - Exploits of a mom

Pour aller plus loin
StackOverflow – How to prevent code injection attacks in PHP (EN)
Webmaster Hub – Sécurité et formulaires PHP
Apprendre PHP – Traitement des formulaires
Chez Neg – Sécurité d’un formulaire PHP
Bastien Rossi – Les injections SQL
Le blog de maniT4c – Protection de formulaire contre les robots

Lire la suite