Analyseurs statiques et revues de code devraient tout de même en spotter
pas mal. Pourquoi ne pas filer l’accès à un serveur de staging aux outils
3rd party?
Dernièrement, j’ai découvert que render "index" est l’équivalent de render
file: "index" sous Rails < 4.2. Cela est fixé à partir de Rails 4.2 pour render
template: "index".
Bref, render params[:section] avec la route /settings/:section permettait
de facilement afficher ../../config/secrets.yml. Heureusement qu’on a un
rails core team member dans l’équipe pour voir cela en revue de code.
On Thu Feb 12 2015 at 7:28:57 PM Florian Dutey <fdu...@gmail.com> wrote:
> 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 recevez ce message, car vous êtes abonné au groupe Google Groupes
> "RubyLyon".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le
> concernant, envoyez un e-mail à l'adresse
> rubylyon+unsubscr...@googlegroups.com.
> Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse
> rubyl...@googlegroups.com.
> Visitez ce groupe à l'adresse http://groups.google.com/group/rubylyon.
> 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 .
