Hello, Tu peut regarder du coté des WAF
https://www.owasp.org/index.php/Web_Application_Firewall En gros ca filtre en entré et si sa sort des patterns connus la requête est rejeté. Par exemple si ton applis reçoit jamais de XML sur un endpoint et qu'elle en reçoit brusquement le waf peut la rejeter. Le vendredi 13 février 2015 04:28:59 UTC+1, Florian Dutey a écrit : > > 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 <oelm...@gmail.com > <javascript:>> 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 >> rails...@googlegroups.com <javascript:> >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> railsfrance...@googlegroups.com <javascript:> >> --- >> 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...@googlegroups.com >> <javascript:>. >> 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 .
