Hello,
Pour faire plaisir à mon cher RSSI, je voudrais valider le comportement d'une application vis à vis des flux RSS qu'elle consulte. La récupération du flux est faite par le serveur et non au niveau du client. Mon RSSI ne souhaitant pas par défaut autoriser l'accès internet à ce serveur, je dois avancer sur la capacité de la solution à ne pas être comprise si par hasard un utilisateur mettrait un flux RSS malveillant...
Existe-t-il des ressources de ce type sur internet ? Le but étant de pouvoir déposer ses flux RSS sur un de nos serveurs en interne et tester l'appli en mode "isolé".
Si vous avez la même chose pour des gadgets opensocial, je suis aussi preneur.
S'il s'avère que l'appli nettoie suffisamment le code qu'elle injecte, je pourrais peut être faire réévaluer cet accès internet. Sinon ce sera tant pis pour les utilisateurs.
Merci d'avance, Nicolas
2011/1/24 Nicolas Steinmetz nsteinmetz@gmail.com:
Hello, Pour faire plaisir à mon cher RSSI, je voudrais valider le comportement d'une application vis à vis des flux RSS qu'elle consulte. La récupération du flux est faite par le serveur et non au niveau du client. Mon RSSI ne souhaitant pas par défaut autoriser l'accès internet à ce serveur, je dois avancer sur la capacité de la solution à ne pas être comprise si par hasard un utilisateur mettrait un flux RSS malveillant... Existe-t-il des ressources de ce type sur internet ? Le but étant de pouvoir déposer ses flux RSS sur un de nos serveurs en interne et tester l'appli en mode "isolé". Si vous avez la même chose pour des gadgets opensocial, je suis aussi preneur. S'il s'avère que l'appli nettoie suffisamment le code qu'elle injecte, je pourrais peut être faire réévaluer cet accès internet. Sinon ce sera tant pis pour les utilisateurs. Merci d'avance, Nicolas
-- Nicolas Steinmetz http://www.steinmetz.fr - http://nicolas.steinmetz.fr/
Salut, Je pense que la question est mal posée. Tu trouveras des exploits pour tous les programmes qu'il y a un intérêt à hacker, et même pour ceux qui ne présentent pas particulièrement d'intérêt. Compte tenu qu'on peut considérer qu'il existe des failles dans tous les programmes (quasi un axiome, même si DJB s'est démené pour essayer de prouver le contraire , mais on est pas vendredi :p), si ton serveur exécute un programme pour récupérer des RSS, des MP3, ou peu importe, il existera un jour ou l'autre des exploits pour poutrer ton programme.
Sans nous dire quelle application tu comptes utiliser, sans nous donner la version, et sous réserve qu'il y ait des spécialistes en sécurité applicative ici qui comptent y passer du temps, ta seule piste, c'est le history record de l'application que tu comptes utiliser, et éventuellement un fuzzer, parce que chaque application est différente, chaque compilation peut être différente, et donc chacun exploit doit être différent.
Autrement dit, si ta question est bien "Il y a t il des RSS malveillants "in the wild" ?", je répondrai : "s'il n'y en a pas encore, il y en aura s'il y a un gain quelconque à avoir (qui peut n'avoir rien à voir avec ta société, comme l'envie de se faire de la publicité pour un étudiant)."
Autrement dit, je pense que ton RSSI pourrait bien t'avoir servi une réponse du genre "va te faire voir" déguisée, à moins qu'il ait vraiment le budget pour faire faire une analyse du logiciel en question par des experts :)
Amicalement, Florian MAURY
Le Mon, 24 Jan 2011 12:54:45 +0100, Florian MAURY a écrit :
intérêt à hacker
^"à cracker" STP
hacker je fais çà souvent et çà n'a rien à voir avec un quelconque piratage.
a +.
Salut,
Lorsque tu dis malveillant tu parles d'exploit sur le poste du visiteur type XSS ou tu penses plutôt à une chaine capable de faire un buffer overflow ou autre visant explicitement le logiciel qui récupère le rss?
Dans le premier cas, ca doit pas être dur à trouver mais bien sur cela dépend des logiciels en présence pour consulter le flux. Pour le second il faut regarder et surveiller le logiciel en question, si c'est du dev interne, le faire auditer par d'autres personnes que l'équipe de dev.
-- Pierre-Henry Muller
Bonsoir,
Le 24 janvier 2011 14:18, Pierre-Henry Muller wallace@morkitu.org a écrit :
Salut,
Lorsque tu dis malveillant tu parles d'exploit sur le poste du visiteur type XSS ou tu penses plutôt à une chaine capable de faire un buffer overflow ou autre visant explicitement le logiciel qui récupère le rss?
La crainte de mon RSSI, c'est la compromission du serveur vu que c'est le serveur qui agit comme client pour récupérer les flux RSS et autres widgets.
Ce qui me surprend, c'est que si la récupération se faisait au niveau du client, il n'est pas contre, alors que si c'est le serveur, il hurle.
Le produit est une solution commerciale (Jive SBS). J'ai questionné l'éditeur sur le sujet et leur réponse ne va pas loin.
Il aurait pu exister une sorte de référentiel des attaques XSS / CSRF / ... pour notamment des flux RSS dans mon cas et qu'on puisse les soumettre à une appli pour voir le résultat. Un peu comme les éditeurs d'antivirus qui proposent des faux virus pour tester le niveau de détection de l'antivirus.
Sans nier le risque potentiel, va falloir que je la joue fine avec mon grmbl de RSSI ; surtout que déjà, pour accéder à internet, il faut passer par un proxy filtrant mais il ne veut pas donner un accès en * pour les frontaux de mon application.
Merci pour vos commentaires, Nicolas
Il faudrait sans doute rappeler à ton RSSI que la compromission d'un élément du réseau peu suffire à tout casser. Qu'une ip avec un soft qui se fait casser les pattes soit sur un serveur ou un poste ca ne change pas souvent grand chose modulo quelques règles firewall et encore.
Si ton processus tourne sur un serveur un minimum travaillé pour la sécurité et sur un utilisateur dédié c'est bien plus secure que sur un poste client où y aura des chances que l'utilisateur soit en plus admin sur son poste.
Je pense pouvoir me risquer de dire que ton RSSI vient soit de l'informatique avec un bagage faible soit a été parachuté à ce poste sans connaissances particulière. Un poste de travail qui pête c'est toujours moins grâve aux yeux de la direction qu'un serveur ...