Porn Sex Viagra Casino Spam

Encore une classe éxotique qui sert surtout à montrer qu’on peut le faire, mais dont l’utilité n’est pas évidente Enfin, moi j’en avais besoin dans le cadre d’un projet plus vaste…

Les seuls pseudo-proxies que j’avais trouvé en PHP étaient en général des usines à gaz qui scrappaient une page pour essayer ensuite de réécrire les liens, bref pas ce que j’appelle un proxy. Je me suis donc inspiré de ce qui existe en Python pour coder un proxy basé sur les Sockets. J’avais commencé par utiliser curl pour retranscrire les requêtes du client, mais il est apparu assez rapidement que c’était bien inutile : un code 100% socket étant plus fiable, plus léger et sans doute plus rapide (quoique la performance est loin d’être la marque de fabrique de ce script, PHP n’étant pas du tout adapté à ce genre d’usages).

Le script consiste en une classe de base, qui peut fonctionner telle quelle, il suffit de le lancer, idéalement en ligne de commande :

php proxy.php [host port]

Si le script est appelé sans paramètres, il se lance sur l’adresse 0.0.0.0, port 8000. Pratique pour le tester en local, il suffit alors de configurer le proxy dans votre navigateur (proxy HTTP / HTTPS, adresse 0.0.0.0, port 8000, et c’est tout !).

Ce proxy implémente la méthode CONNECT, c’est à dire que vous pouvez l’utiliser même sur des pages sécurisées (HTTPS). Il supporte à priori toutes les méthodes possibles : GET, POST, HEAD, PUT, DELETE. Tel quel, il agit comme un proxy 100% anonyme, c’est à dire que si vous éxécutez le script sur votre serveur et que vous l’utilisez comme proxy, vous pourrez surfer avec l’IP de votre serveur. Pour le vérifier vous pouvez consulter cette page : http://whatismyipaddress.com/staticpages/index.php/advanced-proxy-test qui vous indiquera que vous n’utilisez pas de proxy mais affichera bien l’IP de votre serveur et non la votre !

Comme indiqué plus haut, pour les perfs il faudra repasser Pour améliorer ça, j’ai utilisé la fonction pcntl_fork() pour simuler le multithreading qui n’existe pas en PHP. Si les fonctions pcntl donc ne sont pas activées dans votre configuration PHP, le programme s’éxécute normalement et les requêtes se font donc une par une, à la chaine, ce qui donne une idée de ce à quoi doit ressembler le net en Afrique ou peut rappeler de vieux souvenirs à ceux qui sont nés avant l’invention de l’ADSL !

J’ai bien introduit une vague limitation du nombre de clients, mais il faudrait plutôt modifier ça pour limiter le nombre de processus fils engendrés simultanément si on veut éviter une catastrophe, ce qui n’est pas dur à faire, mais de toutes façon je vous rappelle pour ceux qui ne l’auraient pas compris qu’il ne faut pas utiliser ce proxy en PROD ou le laisser en accès libre sur votre serveur ! Le script est avant tout expérimental et il n’est pas sécure du tout en l’état. Si vous voulez utiliser votre serveur pour offrir des services de proxy au public, il existe de vraies solutions pour cela (SQUID par exemple). Si vous voulez juste l’utiliser pour vous même, je vous conseille au moins d’étendre la classe pour y ajouter un contrôle des clients (n’autoriser que certaines IP à utiliser le proxy, ou y ajouter un login/password).

Voilà le script, vous pouvez aussi le récupérer avec le show_source() de la dernière version ici : http://fbparis.com/proxy.php.

Continue reading « Un Proxy HTTP multithreads en PHP ! »

En fait cet article aurait dû s’appeler : sécuriser une session à la façon d’un gros parano. Mais bon, c’est une petite classe très simple d’utilisation et bien pratique, surtout si votre site est hébergé sur un mutualisé où n’importe lequel de vos collocataires peut espionner et modifier vos fichiers de sessions.

Il s’agit donc d’une classe qui va se substituer à la fonction « session_start() » de PHP. Par la suite il n’y a absolument rien à changer dans votre code. Juste remplacer les « session_start() » par des « $sess = new Session(); » et vos sessions sont dignes de la NSA !

Que fait exactement cette classe ?

Cette classe permet deux choses :

1. Signer la session en fonction de son contenu, d’une clef secrète et de variables qui identifient l’utilisateur (identifiant de session, adresse IP et useragent). Ceci permet d’éviter ce qu’on appelle le « Session Hijacking » ou le fait qu’en récupérant l’identifiant de session de quelqu’un d’autre on puisse se faire passer pour lui.
   Dans le cas où la signature ne correspond pas au contenu de la session, celle-ci est donc détruite (contenu et identifiant).
2. Chiffrer le contenu de la session si vous le souhaitez (il suffit alors d’initier la session avec « $sess = new Session(true); »). Dans ce cas de figure, avant d’être signée la session est encryptée à l’aide d’un algo RIJNDAEL_256, et sera automatiquement décryptée à la réception !

Les variables de session utilisées sont totalement invisibles, vous pouvez faire un « print_r($_SESSION); » pour le vérifier, car elles sont automatiquement supprimées à l’initialisation de la classe, et recréées juste avant sa fermeture. Pas non plus de conflit possible avec vos autres variables de session, c’est vraiment tranquille !

Pour personnaliser la clef utilisée pour l’encryption et la signature, vous êtes invités à definir une constante SESSION_SECRET avant d’appeler la session.

Enfin, pour savoir si la session est passée correctement ou si elle a été réinitialisée vous pouvez regarder la valeur de « $sess->valid » (true si tout va bien, false sinon).

Continue reading « Sécuriser une session PHP »

Pour ma première application Twitter avec oAuth j’ai fait simple.

Le constat : n’importe quel service à qui vous avez donné vos codes d’accès Twitter (ce qu’on ne devrait jamais faire) où n’importe quelle application à laquelle vous avez accordé les droits en lecture et écriture via oAuth peut en quelques secondes s’accaparer votre compte Twitter !

Pourquoi ? Parceque Twitter autorise la modification de l’adresse email via l’API et qu’il est ensuite enfantin de déclencher une procédure de changement de mot de passe, même de façon totalement automatisée (aucun captcha ou autre protection anti-robot n’étant utilisés lors de cette procédure).

C’est d’ailleurs un peu comme cela que fonctionne mon application, mais avec l’objectif de vous rendre votre compte en cas de vol plutôt que pour vous le voler. Et je n’ai pas pousser l’automatisation du processus jusqu’au bout : lors d’une tentative de récupération de votre mot de passe, l’application va jusqu’à déclencher l’envoi du lien adequat par twitter et c’est à vous de faire le reste (à savoir : choisir un nouveau mot de passe).

A cause de cette possibilité de modifier l’adresse email d’un utilisateur, la sécurité du « login avec twitter » ne repose pas seulement sur les serveurs de twitter, mais dépend également de TOUS les services que vous avez autorisés en lecture / écriture via oAuth ou en filant vos codes d’accès ! Il suffit qu’un seul se fasse hacker pour pouvoir récupérer votre compte et par effet de dominos tous les comptes avec lesquels vous vous identifiez avec twitter… C’est assez embêtant je trouve.

Petits conseils si jamais vous vous faites voler votre compte Twitter et que par chance vous utilisiez mon application :

• Ne remettez pas le même mot de passe qu’avant ! (ça parait évident mais bon, il y a sûrement quelques abrutis parmi vous)
• Allez directement dans « Settings / Connections » et révoquez les autorisations de tous les services qui ont un accès en écriture (update), sauf mon appli bien sûr !

Pour info avec mon application, une adresse email ne peut etre utilisée qu’une seule fois (donc si vous avez plusieurs comptes twitter il vous faudra aussi plusieurs adresses email) et un compte twitter ne peut être protégé que par une seule adresse email (ça vaut mieux hein !).

Notez aussi que si la personne qui vous a volé votre compte s’empresse de révoquer l’autorisation de mon application (comme devrait le faire un hacker efficace), ça ne fonctionnera pas.

L’application est ici : Recover Stolen Account

Edit : Twitter a bien reçu le message via le groupe de support pour l’API et envisage de remédier à ce problème ! Bonne nouvelle donc.

…ou du moins pour limiter la casse j’imagine. Vous pouvez toujours protéger le dossier /wp-admin avec un .htaccess maison, ce qui devrait calmer de façon radicale les ardeurs des bots !

C’est assez simple :

Dans votre dossier wordpress/wp-admin/ vous créez un fichier .htaccess en lecture seule et avec le contenu suivant :

AuthType Basic
AuthName "Admin WORDPRESS"
AuthUserFile /home/wpadmin.pwd
Require valid-user

Dans cet exemple, le fichier contenant les acces autorisés se trouve dans /home/wpadmin.pwd mais vous pouvez très bien le mettre ailleurs.

Pour créer ce fichier wpadmin.pwd c’est très simple, dans une console ssh tapez la ligne suivante :

htpasswd -cb /home/wpadmin.pwd login password

Et pour ajouter d’autres utilisateurs :

htpasswd -b /home/wpadmin.pwd login password

Vous pourrez aussi modifier un mot de passe ou supprimer un acces, je vous laisse lire la doc de la commande htpasswd hein !