> Ok merci. C'est ce que je pensais. Je n'aurais pas du faire ce script qui > reconnais "passwd" dans l'url et donne tout les mots de passes...
Mince, maintenant tout le monde sait que mon mot de passe est 12345 ! > Ça ne vous dérange vraiment pas plus que ça de mettre des ID dans les > paramètre de l'url? Au niveau des droits, j'utilise Cancan, de Ryan Bates > (reviens Ryan!). C'est marrant, c'est la troisième fois que je vois cette question posée en 6 mois. À vrai dire, je ne comprends pas ce qui dérange dans le fait d'utiliser des ids, c'est parfaitement standard, concis, et approprié (pas besoin d'avoir un second identifiant unique). En général, les inquiétudes se range dans deux familles, issues toutes deux de la nature séquentielle des ids : * le problème de la transparence du nombre d'items * le problème de la prédictibilité des ids existants Pour le premier problème, l'inquiétude est généralement : "les concurrents et les investisseurs potentiels vont savoir combien nous avons de produits !" À cela, je réponds toujours : "Et alors ?". C'est une info que je donnerais volontier si des concurrents ou investisseurs potentiels me la demandait, je ne comprends pas quel cadavre dans le placard pourrait m'inciter à vouloir dissimuler ça. Mais après tout, je ne suis pas CEO. Peut-être y a-t-il des raisons business stratégiques qui m'échappent. Sur le second problème, en revanche, je suis beaucoup plus catégorique. Le fait qu'on puisse deviner les id existants ne devrait pas être un problème, parce qu'il ne faut de toutes façons pas compter sur le fait que quelqu'un ne peut pas les trouver - comme le signalait Guillaume. Peu importe si l'identifiant est trouvé ou non, il doit y avoir un système d'autorisation qui détermine si l'utilisateur à le droit d'accéder à la ressource ou non. La seule exception que je vois à cela est le cas des urls semi publiques, comme par exemple les private gist ou les shared link dropbox. Dans ce cas, je veux une url accessible par n'importe qui mais qui ne peut être devinée, et j'utilise un md5 en tant qu'identifiant. Mais ça reste une exception. On Thursday, July 31, 2014 1:38:23 PM UTC+2, Guirec Corbel wrote: > > Ok merci. C'est ce que je pensais. Je n'aurais pas du faire ce script qui > reconnais "passwd" dans l'url et donne tout les mots de passes... > > Ça ne vous dérange vraiment pas plus que ça de mettre des ID dans les > paramètre de l'url? Au niveau des droits, j'utilise Cancan, de Ryan Bates > (reviens Ryan!). > > > Le 31 juillet 2014 06:42, Florian Dutey <[email protected] <javascript:>> > a écrit : > >> A moins de le faire expres, aucun risque que ca tarrives avec rails. >> >> Mais c classique en php. Je ne dirai pas pourquoi, je te laisse deviner >> :)))) >> On Jul 31, 2014 6:27 PM, "Olivier El Mekki" <[email protected] >> <javascript:>> wrote: >> >>> Hello, >>> >>> Ça s'appelle un LFI (pour Local File Inclusion) : >>> https://en.wikipedia.org/wiki/File_inclusion_vulnerability >>> >>> Ça ne devrait pas poser de problème, tu n'y est vulnérable que si tu >>> essaie de loader des fichiers depuis les paramètres de l'url, du genre: >>> >>> require params[ :my_param ] >>> >>> >>> C'était une attaque dangereuse au début de l'histoire de php, quand les >>> sites étaient architecturés de manière à décider quel fichier loader sur >>> la base d'un paramètre, avant qu'on ne fasse de la réécriture d'url et >>> des routes. Du genre : >>> >>> # index.php >>> load( "pages/" . $_GET[ 'page' ] ); >>> >>> >>> Ça ne devrait pas être un problème pour toi. >>> >>> >>> On Thursday, July 31, 2014 12:21:15 PM UTC+2, Guirec Corbel wrote: >>>> >>>> Bonjour, >>>> >>>> Hier soir, un de mes sites a été victime d'une attaque. Le programme >>>> voulant hacker essai d'accéder à "/etc/passwd" en essayant des url de >>>> ce >>>> type : >>>> "/provider_profiles/new?service_id=../../../../../../../../../../etc/passwd%00" >>>> >>>> >>>> ou >>>> "/index.php?page=/../../../../../../../../../../etc/passwd%00&artiste_id=12". >>>> >>>> >>>> >>>> Avez-vous déjà été victime de ceci? Comment bien le gérer? >>>> >>>> Cette attaque me fait poser une question. J'imagine que ce n'est pas >>>> génial d'utiliser les paramètres du type "artist_id=12". Est-ce un >>>> bonne >>>> pratique d'utiliser un token ou friendly id à chaque fois? >>>> >>>> Bonne journée à tous, >>>> Guirec. >>>> >>> -- >>> -- >>> 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 >>> [email protected] <javascript:> >>> Pour résilier votre abonnement envoyez un e-mail à l'adresse >>> [email protected] <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 >>> [email protected] <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 >> [email protected] <javascript:> >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> [email protected] <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 [email protected] >> <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 [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- 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 [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
