Hey Olivier, merci pour ta reponse.
Pour les 3rd parties, aucun probleme. Nos applis tournent dans des
containers dockers separes.
Je comprends ce que tu veux dire, rails s'occupe de securiser rails et on
ne devrait pas ecrire de tests portant sur la securite de celui-ci. C'est
l'equipe rails qui s'en occupe (comme on n'ecrit pas de tests rspec pour
tester si un simple has_many sans fioritures fonctionne comme prevu). J'ai
compris, tu as absolument raison.
Pour ce qui est des notifs d'exception et des 500, il nous est arrive
recemment qu'un developpeur pose un "name = #{name}" dans une methode pour
construire des requetes complexes.
On l'a spote parce qu'un utilisateur avait fait un mauvais copier coller et
avait laisse un ' dans le champ de recherche. Effectivement, la notif
d'exception nous a permis de spotter le probleme et de le fixer
immediatement.
Cependant, si quelqu'un ou quelque chose de malveillant l'avait spotte
avant nous, en pleine nuit, il aurait eu quelques heures pour tout peter ou
recuperer des infos sensibles.
D'ou mon idee d'automatiser un certain nombre de choses, comme tester
systematiquement les url qui sont supposees recevoir des parametres contre
tout type d'exploits generiques et connus.
Un test simple pourrait consister a ecrire quelque chose du genre
describe SearchController do
# ...
describe "/GET" do
it "resists against sql injections" do
ExploitFW.scan_for_sql_inject(
:url => searches_path,
:http_method => :get,
:with_param_names => [:q]
)
end
end
end
C'est peut etre une mauvaise approche du probleme, je dis pas. Mais du
coup, je me demande comment teste-t-on de maniere automatisee la securite
d'une application et comment les grands acteurs (a la github) testent-ils?
J'ai du mal a croire qu'ils ne testent rien.
Et les scanners genre netsparker, c'est cool, mais filer des tokens d'auth
a un outil 3rd party qui va balancer des SQL injects sur la prod,
moyennement confiance. Quand aux analyseurs statiques, j'y crois qu'a
moitie.
Les recherches google en la matiere ne renvoient que sur des gems genre
brakeman et des scanners 3rd party :/.
Le 12 février 2015 17:37, Olivier El Mekki <oelme...@gmail.com> a écrit :
> Ah, un autre point important pour les applications qui ne sont pas sur du
> cloud (sorry pour le double post).
>
> Sécuriser au maximum son application principale, c'est bien, mais ce n'est
> pas
> de là qu'arrive en général les problèmes. La plupart du temps, l'attaquant
> s'introduit par une application de seconde zone qui tourne sur ton serveur
> (webmail, CI, frontend d'administration, etc).
>
> Pour cette raison, il est important de ne pas avoir d'application de
> "seconde
> zone". Si c'est accessible par internet, alors tu dois le considérer comme
> aussi important que ton application principale.
>
> Une bonne pratique pour limiter la casse consiste à avoir un utilisateur
> unix
> par application et de s'assurer qu'un utilisateur ne puisse pas avoir
> accès à
> la home des autres utilisateurs (`chmod o-x ~`). Cela évite que quelqu'un
> qui
> rentre par ton webmail outdated puisse récupérer les infos de connexion à
> la db
> de ton app principale.
>
>
> 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 obtenir davantage d'options, consultez la page
> https://groups.google.com/d/optout.
>
--
--
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 .
