MySQL et des Add-ons propriétaires?

Publié le 28 April 2008, par Babozor

mysql_end.jpg

Voilà une annonce plus que déroutante, après tous les efforts de Sun pour tenter que le rachat de MySQL ne changera pas la politique de release de son moteur de donnée, voilà qu’ils lâchent une bombe: Certaines nouvelles fonctionnalités ne seront désormais disponible que dans la version entreprise (avec support repackagagée et donc payante)

Les réactions n’ont pas tardé (y’en a plein, mais on peut voir ici et quelques bons exemples de réactions offusquées)… moi je ne sais pas trop quoi en penser, je suis juste déçu (mais en même temps ça se sentais un peu)

Et vous?

MySQL/Sun

Publié le 15 April 2008, par Babozor

mysql_shirt1.jpg

Aujourd’hui un tshirt manche longue double face piqué à l’occasion de la présentation du rachat de MySQL par Sun… donc objet introuvable, donc ultra collector (d’où ma joie incommensurable)

mysql_shirt2.jpg

TDW @ Présentation MySQL/Sun

Publié le 5 April 2008, par Babozor

J’étais mercredi dernier (le 2 avril) avec Jorge et Julien (respectivement dev et co-CEO de findawine.com) à une présentation post achat de MySQL par Sun. Ambiance décontractée et OpenBar qui nous a permis entre autre de rencontrer certains des responsables de MySQL, dont le Community Manager, très sympa, accessible et plein de bons conseils…

Combattre l’injection SQL

Publié le 17 January 2008, par Babozor

injection.jpg

Quoi? Mais keskecé que l’injection SQL?
Pour ceux qui ne le sauraient pas, l’injection SQL pour une application web est un équivalent à la grippe, un truc pas cool, qui fait bobo et qu’on pourrait simplement éviter (comme en se vaccinant par exemple, alors que le violent hacking brut-force pourrait trouver son analogie dans un bon vieux cancer du colon)…
L’injection SQL est le fait de rajouter un bout de code dans un champs d’un formulaire, de sorte qu’il soit interpréter par le moteur de base de données… c’est pas très dur à faire et aujourd’hui 90% (au moins) des sites sont complètement démuni contre ce type d’attaque.

Quels sont les risques?
Vous pouvez perdre une partie ou la totalité de vos données (suivant les cas, ce qui est déjà pas mal, avouez le…) ou voir vos données modifiées (comme un utilisateur standard passé en administrateur par exemple).

Comment se protéger
Il y a plusieurs moyens, l’idéal étant d’en cumuler certains pour assurer une sécurité maximale
utilisez un utilisateur spécifique, qui a des droits restreints et ne pourra pas vider ou supprimer votre table de la base de données (mais cela ne l’empêche pas d’avoir dans certains cas les droits en suppression sur les données)
utilisez des préfixes pour vos tables, pour éviter que votre table d’utilisateurs ne s’appelle user ou users, en ajoutant un prefix par exemple my_users, le nom de la table est beaucoup moins évident et donc un peu plus sûr. (pensez aussi quand vous installez des applications OpenSource type WordPress de ne pas laisser le préfixe standard toujours pour plus de sécurité)
vérifiez et échappez toutes les données provenant des utilisateurs, en utilisant par exemple la fonction bien pratique mysql_real_escape_string en PHP… ne laissez aucune donnée brute, vérifiez au besoin, via une expression régulière…
activez les protections internes (comme magic_quotes_gpc pour le PHP)
utilisez des procédures stockées, là plus de soucis (ou presque) puisque les données sont passées en paramètres à votre moteur de base de données et non plus une requête dynamique.

C’est un type d’attaque trop souvent sous-estimé mais qui peut être dévastateur (et dramatique) pour votre système d’information.
C’est d’autant plus dangereux que c’est une attaque de bas niveau, tout le monde ou presque peut tenter sa chance, donc beware!
Si vous avez d’autres conseils ou anecdotes, n’hésitez pas, les commentaires vous sont ouverts…