Hello,
La faille dont tu parles à été fixée depuis rails-3.0.20 :
http://weblog.rubyonrails.org/2013/1/28/Rails-3-0-20-and-2-3-16-have-been-released/
Pas de problème donc si tu utilises quoi que ce soit de plus récent.
L'idée d'automatiser les tests de sécurité, même si séduisante, me semble
être
une chimère, et cela pour deux raisons :
1. rails étant un framework, il est fort à parier que le plus grand nombre
de
failles relèvent de code spécifique à l'application implémentée
2. il s'agirait de tester ce qui ne fonctionne pas, et non pas ce qui
fonctionne
Les failles relevant de rails lui-même ne sont pas celles qui sont le plus à
craindre : une bonne politique d'update de l'application suffit à s'en
mettre à
l'abris sans même avoir à connaître les problèmes. Évidemment, il y a le
problème de la faille fraichement rendue publique, mais il se poserait de
toutes façons aussi avec un framework automatisé de tests de sécurité. Quant
aux failles spécifiques à ton application ... utiliser les payloads de
metasploit ne t'aiderait juste pas à les trouver.
Si tu veux automatiser les tests de sécurité pour les problèmes spécifiques
de
ton application, il faut d'abord que tu les connaisses. Ça peut à la rigueur
avoir du sens afin de tester les regressions, mais l'intérêt est limité, du
fait qu'on test le problème et non pas le fonctionnement normal (c'est quand
même beaucoup plus courant qu'une fonctionnalité casse, dû à 1000 raisons
possibles, que le fait qu'un bug très spécifique soit introduit à nouveau).
À cela s'ajoute également un problème d'intégration. La dernière fois que
j'ai
regardé metasploit, il utilisait une version très obsolète de ruby, et ne
fonctionnait pas avec les versions plus récente. Si c'est toujours le cas,
ça
implique de faire rentrer rvm / rubyenv / docker / whatever dans le process
de
test. Un beau cauchemar en perspective :)
En matière de sécurité, je me repose sur deux pilliers : les mises à jour et
les notifications d'exception.
La plupart des attaques viennent d'applications qui testent des range d'ip
sur
les failles les plus courantes. Avoir une application et des serveurs à jour
permettent de le prévenir. Même si quelqu'un devait attaquer spécifiquement
ton
serveur, il lui faudra beaucoup de recherche avant de trouver quelque chose
d'exploitable.
Et généralement, durant ces recherches, ils génèrent des exceptions. L'idée
générale de l'exploit étant de tordre ton application pour lui faire faire
quelque chose d'imprévu, une 500 finit toujours par arriver. C'est à ce
moment
là qu'il faut être attentif. Je me suis fait un script pour les très rares
occasions :
$ cat /usr/local/bin/block_ip
#!/usr/bin/env bash
iptables -I INPUT 3 -p all -s "$1" -j DROP
Ça permet de pouvoir bloquer une ip instantanément via iptables sans
hésiter en
se disant "attend, c'est quoi la syntaxe, déjà ?".
Évidemment, tout cela n'est pas bulletproof (et rien ne le sera,
probablement),
mais ça suffit probablement à inciter l'attaquant à chercher un fruit pendu
plus bas.
Ah oui, et juste pour le troll, j'aime bien modifier les numéros de version,
voir les noms d'application, que reportent les applications sur mes
serveurs :)
On Thursday, February 12, 2015 at 3:28:38 AM UTC+1, Florian Dutey wrote:
>
> Bonjour a tous,
>
> Une question m'est venue a l'esprit aujourd'hui.
> Je fais une migration de rails 3 vers rails 4 et je cleane donc tous les
> initializers / config files.
> Un de mes initializers desactive le parsing du XML dans les controllers
> (fix pour CVE-2013-0156) et je n'ai aucune idee si cela a ete fixe dans
> rails 4. Aucune doc n'en parle, je suppose que oui mais je ne peux pas me
> permettre de ne pas etre sur.
>
> J'ai trouve un article qui parle de tester ce bug avec le fw metasploit (
> http://blog.endpoint.com/2013/01/rails-CVE-2013-0156-metasploit.html) et
> cela a entraine la fameuse question.
>
> Comment tester de maniere automatique la securite d'une application?
> J'ai trouve quelques outils qui analysent le code de maniere statique mais
> ce n'est pas suffisant.
>
> Je me demandais si il n'existait pas un integration metasploit <=> rspec |
> travis specifique pour rails, qui essaierait par exemple de defoncer mon
> appli avec tous les exploits connus integre dans le framework.
>
> Ou autre chose... Mais dans l'idee, un truc qui va vraiment taper sur un
> serveur (de test) comme un acharne pour reveler d'eventuelles failles de
> secu.
>
> Merci de vos retours :)
>
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse
railsfrance-unsubscr...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant,
envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .
