Je n'ai pas le courage de vous faire une version française complète, donc voici déjà le post sur leur blog :
[https://blogs.apache.org/infra/entry/apache_org_04_09_2010]
Maintenant pour résumer :
- quelqu'un a posé un lien tinyurl.com/xxxx dans une description de bug sur le bugtracker
- des admins ont cliqué dessus
- ça passait des choses méchantes, c'est à dire une attaque XSS sur le bugtracker JIRA
- vol de session, le méchant devient admin
- ... pas mal de choses se passent, le méchant pose des backdoor
- ... le formulaire de login est changé, donc des mots de passe sont volés
- un admin utilisait le même mot de passe pour un compte root sur une machine, et c'est le drame.
Au final :
- des hash de pass volés
- certains pass en claire volés
- une machine compromise
Conclusion :
- toujours se méfier avant de naviguer alors qu'on est connecté sur un service web
- toujours se méfier des tinyurl, ça devrait être utilisé UNIQUEMENT sur twitter, le reste du net gère plus de 140 caractères...
Tout n'est pas la faute du tinyurl, sans :
- certaines failles dans JIRA
- certains autres failles dans JIRA
- des admins avec le même mot de passe de partout
- une config de ssh un peu négligée
l'attaque n'aurait pas été si méchante.
Mais il ne faut pas oublier la loi de Murphy. Donc puisqu'il y aura toujours une merde quelque part, évitons de les cumuler.
Journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.
14
avr.
2010
# Tendance de fond ?
Posté par eastwind☯ . Évalué à 8.
Après l'annonce précurseur de la compromission de serveur maitre debian en 2003 : ( http://linuxfr.org/2003/11/21/14650.html )
Puis l'attaque sur Berlios le 14 janvier 2010
(http://cyberinsecure.com/berlios-open-source-project-portal-(...)
Ensuite les serveurs du projet Tor le 20 Janvier 2010:
http://linuxfr.org/~patrick_g/29297.html
Maintenant les serveurs Apache
Aujourd'hui j'entend aussi que des DDOS ont été lancé aussi contre le site officiel auto-heberger d'un projet de jeux libre nommé projet Diaspora . (l'auteur a aussi un miroir sur sourceforge : http://sourceforge.net/projects/pdiaspora/ )
Je ne parles meme pas des attaques contre la webradio demoscene qui a fait quasi perdre tout la DB . Ainsi que les attaques subit contre Zzone , la communauté du jeux Z (des Bitmaps Brothers ) , qui développe un jeux libre basé sur Z .
J'avais aussi un moment vue que le site officiel du jeux libre Attal avait été défacé au alentour de 2006 - 2007 si je me souviens ...
Est ce que je deviens parano ou bien c'est un vrai tendance de fond ?
Et si c'est une tendance de fond , pour quel raisons les black hats attaques t-il des projets libres ? A qui profite ces attaques ? dans quels buts ?
J'ai l'impression que ces attaques ciblés ne sont pas anodins , et semblent faire partie peut etre d'une campagne plus large de FUD ... ou bien ok je deviens vraiment parano...
[^] # Re: Tendance de fond ?
Posté par pasBill pasGates . Évalué à 10.
La rancon du succes
Plus tu deviens connu, plus tu es cible. Dans le cas d'Apache, imagines si le gars avait reussi a mettre une backdoor dans le produit lui-meme, a part le fait qu'il pourrait se faire un fric fou en interceptant toutes les transactions avec carte de credit des nombreux sites utilisant Apache ainsi que username/mot de passes, il aurait son nom(ou son nick) en 1ere page des journaux. Et si ca se trouve, la raison etait tout simplement d'utiliser les serveurs pour du spam.
Quand a la soi-disant campagne de FUD, c'est de la parano a mon avis, je crois que tu ne te rends pas compte du nombre d'attaques qui sont effectuees tous les jours sur le reseau, il te faudrait un nombre enorme de mains pour les compter sur les doigts, que certaines visent les projets libres a succes, c'est un peu normal.
[^] # Re: Tendance de fond ?
Posté par gorva . Évalué à 10.
Et parmi celles qui le font, encore moins donnent autant de détails que la fondation Apache, et je les en félicite.
Au moins, on aura désormais un exemple concret et marquant d'une utilisation d'URL raccourcie lors d'une attaque ciblée. Cela fait des mois que les sociétés antivirus (entres autres) mettent en garde [1] contre les utilisations potentielles de ces services, que ce soit pour du XSS ou plus simplement pour rediriger vers une page malveillante exploitant des failles au sein des navigateurs. En effet, il suffit aujourd'hui de se rendre sur un site pour "se faire infecter" (en gros, pour exécuter du code arbitraire), et ce n'est pas valable que pour IE (exemple d'une faille récente sur Firefox 3.6 [2] ).
[1] exemple au hasard : http://www.eset.com/blog/2009/02/25/tinyurl-the-tiny-terror
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=552216
[^] # Re: Tendance de fond ?
Posté par B16F4RV4RD1N . Évalué à 10.
chapeau aussi pour la technicité de l'attaque, je n'arrive pas trop à me rendre compte, mais il faut sans doute être très fort pour arriver à planifier et réussir ce genre d'attaque...
Enfin, je voulais réagir sur le "toujours se méfier des tinyurl, ça devrait être utilisé UNIQUEMENT sur twitter" : avec des millions de ces m**** de tinyurl échangées sur twitter, on devrait justement se méfier et éviter ce genre d'âneries. Je serais curieux de connaître le pourcentage de posts (pardon, de tweeeeeets) uniquement composés d'un lien à la con vers un autre truc déjà "buzzé" des milliers de fois. Ce n'est même pas une limitation technique qui impose cela (à part pour une vague histoire de sms, lesquels sms utilisent une technologie obsolète qui n'a qu'un but c'est de faire raquer le client), c'est une vraie connerie.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Négligence des admins
Posté par Bruno Michel (site web personnel) . Évalué à 7.
[^] # Re: Négligence des admins
Posté par Krunch (site web personnel) . Évalué à 2.
Toujours tester les modifications.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Mesures anti-phishing.
Posté par zerkman (site web personnel) . Évalué à -8.
[^] # Re: Mesures anti-phishing.
Posté par B16F4RV4RD1N . Évalué à 5.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
ce n'est pas du phishing. Le lien ne redirigeait pas vers un autre serveur (un serveur des attaquants ou déjà corrompu par ces derniers par exemple). Cela redirigeait vers le serveur Apache lui-même. Il y a apparemment une faille de cross scripting (script croisé serait une trad adéquate) dans le logiciel Jira qui — à une certaine page — accepte donc un script externe en url (le post n'en dit pas plus sur ce point, mais j'imagine car ils l'ont rapporté à Atlassian et la faille exacte ne sera divulguée qu'une fois corrigée).
En gros, pour expliquer, dans l'url même, ils ont écrit un script (dans une quelconque variable probablement) — ce pourquoi le tinyurl était notamment intéressant pour cacher la longueur de l'url fort probablement, ainsi que son contenu évidemment aussi bien que, redirigeant sur Jira, ça puisse ne pas éveiller de soupçon sur un rapide coup d'œil — puis ce script a donc été intégré dans la page web comme s'il faisait partie normale du site, et donc le script avait accès au cookie de session. Le navigateur n'a donc aucune raison de refuser à ce script d'accéder au cookie de session correspondant à l'url du bugtracker Apache a priori. Ce pourquoi je pense que même Firefox ferait l'erreur. D'ailleurs les gars de la fondation Apache ne donnent pas de détails sur les navigateurs touchés ou non, donc je pense que tous le sont.
Le seul truc que peut faire le navigateur, c'est détecter un comportement étrange et peut-être générer un avertissement, j'imagine. En effet, comme le script est côté client, le navigateur voit peut-être qu'il est intégré de l'url (mais ce n'est pas sûr, ça doit dépendre comment il est intégré, si l'intégration est en PHP, elle est faite par le serveur à partir de l'url).
Enfin bon... le bug vient de Jira, pas du navigateur en l'occurrence (même si ces derniers peuvent peut-être être améliorés pour détecter des comportements étranges et des failles potentielles).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Psychofox (Mastodon) . Évalué à 0.
[^] # Re: Mesures anti-phishing.
Posté par zerkman (site web personnel) . Évalué à 4.
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Le script est injecté dans la page (par une url dans ce cas, mais d'autres méthodes sont envisageables), de sorte qu'il est tout à fait envisageable que le serveur lui-même sert la page avec le script inclus dedans. Là encore, les deux sont possibles. On pourrait aussi imaginer que le script est inséré côté client, par exemple si les variables url sont parsées par du javascript, qui à son tour exécute des scripts qui y sont passés. Mais le cas où l'url est parsée côté serveur et donc que ce dernier sert une page avec le script dedans est tout à fait probable. Dans l'attaque en question, rien n'est précisé sur la méthode exacte du cross scripting (encore une fois, ils attendent probablement que la faille soit comblée).
Par conséquent, d'un point de vue purement basique techniquement, le script ne vient pas d'une autre machine: il vient du serveur.
Cependant il est clair que toute méthode impliquant un script (donc une exécution sur machine) passable par url est mauvaise par design (franchement! Non?). Et comme je soulignais, le navigateur peut sûrement détecter ce genre d'anomalie, mais ce n'est pas du tout un truc évident, car de manière générale, il n'y a pas de bug technique, mais un "bug humain". On demande au navigateur là de repérer et protéger une grosse erreur du développeur (= accepter du code exécutable dans l'url sans protection particulière, l'équivalent d'utiliser la fonction "system" dans un programme sans aucune vérification, et pour une exécution de code très sensible). Néanmoins comme dans ce cas, il y a peu de chances que ça soit bien utilisé, on peut essayer...
Perso, je vois ca ainsi:
1/ si le script est intégré côté client, on peut repérer ça facilement et donc bloquer un tel script.
2/ sinon (intégré côté serveur), on peut essayer de repérer des familiarités entre les scripts intégrés dans la page et ce qui est passé en url. C'est apparemment ce que fait IE8beta2 par exemple (lien très intéressant donné par PasBill PasGate ci-dessous).
3/ de manière générale et plus simple, je me demande s'il ne faut pas virer de l'url tout ce qui ressemble à un script avant même de faire la requête au serveur. Comme je disais, je ne vois pas de bon usage, et même si le script n'est pas intégré dans la page en réponse, rien ne dit qu'il n'est pas exécuté sur le serveur lui-même et peut donc s'avérer très dangereux là-bas.
Néanmoins cela pose la question: jusqu'où «l'intelligence» (au sens IA) du navigateur doit aller pour protéger les erreurs de développement? Et qui sait si — en faisant cela — on ne bloque pas aussi des requêtes légitimes (contre toute attente, il existe peut-être de bons usages, même si je ne les vois pas dans l'immédiat, avec des serveurs qui vérifient et traitent le script au préalable par exemple pour en faire quelque chose d'adéquat, ou le supprimer si dangereux).
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par phoenix (site web personnel) . Évalué à 2.
Comment le navigateur va-t-il faire la différence ?
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Donc en ce cas, la solution 3/ est à bânir. Le navigateur peut juste filtrer par les méthodes 1/ et 2/ (même si le script est intégré dans la page "graphiquement", il n'est pas exécuté, juste affiché, donc le navigateur peut faire la différence et la méthode 2/ ne bloque donc pas ce type d'utilisation).
Mais je vois d'autres problèmes.
Par exemple, imaginons qu'on veuille justement désactiver, mais partiellement seulement, certaines parties d'un script inclus dans une page et que cela permette d'en changer le sens (et obtenir même un usage néfaste), on pourrait alors:
- inclure dans une url une variable contenant la copie de la partie du script à virer (que l'on sait sera incluse dans la page retournée).
- Le serveur lui en réalité ne connaît pas cette variable bidon, n'en prendra pas compte et retournera la page normalement.
- Le navigateur ne sait pas ce que fait ou non le serveur en interne, bien évidemment, par contre il reconnaît que le bout de script qu'il a vu dans l'url se retrouve dans la page comme code à exécuter. Il en conclut "intelligemment" qu'il s'agit sûrement d'une faille de cross scripting et que ce code a été injecté (alors qu'il n'en est rien, il n'y a aucune corrélation réelle entre l'url et ce script).
- Le navigateur retire ce bout de script, mais s'il exécute le reste, ça peut devenir dangereux (si ça a été pensé pour l'être).
Donc ici on a généré une attaque en faisant croire au système de protection qu'il y avait une autre attaque! Ainsi il faut faire très gaffe aussi avec ce genre de sécurité intelligente qui peuvent elle-même créer des failles là où il n'y en avait pas auparavant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par Psychofox (Mastodon) . Évalué à 2.
Mais pour moi c'est tout aussi con d'accepter d'exécuter ça. Je pense qu'à vouloir être trop souple au niveau du développement web, on fragilise trop ces technologies.
[^] # Re: Mesures anti-phishing.
Posté par tyoup . Évalué à 1.
la page fournie par tinyurl n'aurait jamais dû pouvoir faire quoi que ce soit sur l'application JIRA (transmettre le cookie de session de l'admin en tout cas). D'ailleurs dans la spec des cookies, il est stipulé que les cookies ne doivent pas être transmis en cas de cross domain... mais visiblement tout le monde s'en fout !!!!
[^] # Re: Mesures anti-phishing.
Posté par Jehan (site web personnel, Mastodon) . Évalué à 1.
non si tu lis le post de la fondation, ou mon explication plus haut, tu verrais que le tinyurl pointe sur le site Jira lui-même. Il n'y a pas d'autre machine impliquée ici. Le tinyurl très probablement ne devait servir qu'à cacher la taille de l'url (ainsi que le fait qu'elle contienne un script pour ceux qui l'auraient lu). Mais le domaine de l'url n'aurait rien eu de suspicieux par contre.
Bye.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mesures anti-phishing.
Posté par tyoup . Évalué à -1.
et si j'ai bien lu il était question de vol de session... j'ose espérer que sans session en cours l'exploit ne soit pas possible.
GET /5dzzw HTTP/1.1
Host: tinyurl.com
HTTP/1.1 301 Moved Permanently
X-Powered-By: PHP/5.2.12
Location: http://linuxfr.org
Content-type: text/html
Content-Length: 0
Connection: close
Date: Mon, 19 Apr 2010 20:34:29 GMT
Server: TinyURL/1.6
là il faut un peu d'imagination et imaginer que tinyurl renvoie un lien sur jira avec les paramètres qui vont bien pour exécuter un action dans la session de l'admin qui exploite une faille gzeusseusseu. j'avoue l'attaquant aurait pu balancer direct le lien vers jira mais bon ça aurait été un chouïa suspect, non ?
si le navigateur avait fait son boulot, il n'aurait pas transmis les cookies, jira aurait envoyé bouler le navigateur de l'admin et l'attaquant n'aurait pas profité de la session de l'admin.
je n'ai pas la moindre idée de ce que je lis et ce que je raconte !
[^] # Re: Mesures anti-phishing.
Posté par Romeo . Évalué à 3.
Ne tiens pas compte de tinyurl, dis toi juste que les mecs sur le bugtrack ont cliqués sur un lien du genre : http://bugtraker/admin?changepassword=nouveaupassword
Tinyurl a juste fait en sorte de masquer l'url pour que des admins cliquent dessus.
[^] # Re: Mesures anti-phishing.
Posté par tyoup . Évalué à 0.
[^] # Re: Mesures anti-phishing.
Posté par Gof (site web personnel) . Évalué à 1.
[^] # Re: Mesures anti-phishing.
Posté par pasBill pasGates . Évalué à 6.
Selon les cas c'est possible, IE8 le fait(ainsi que le session hijacking), et il ne met pas d'avertissement, il bloque la requete tout simplement. cf. http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-par(...) pour plus d'infos
[^] # Re: Mesures anti-phishing.
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Mesures anti-phishing.
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
# Web à tout faire.
Posté par Grunt . Évalué à 10.
- toujours se méfier des tinyurl, ça devrait être utilisé UNIQUEMENT sur twitter, le reste du net gère plus de 140 caractères...
C'est la conséquence d'une tendance catastrophique qui consiste à vouloir transformer les navigateurs Web en machines virtuelles censées exécuter de plus en plus de code et faire de plus en plus de chose.
Une "URL mail" ou "URL Jabber" ou "URL IRC" raccourcie, ça ne pose aucun problème de sécurité. Pourquoi le Web en pose? Parce qu'on a totalement oublié ce à quoi il servait le Web (diffuser des informations), et qu'on en attend autre chose maintenant: exécuter des applications.
Les problèmes de sécurité ne sont que le revers de la médaille: forcément, en acceptant de nourrir une machine virtuelle avec à priori n'importe quel code (javascript, Flash..), on prend un risque. À peu de choses prêts, ça revient à accepter de télécharger et lancer n'importe quel binaire.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Web à tout faire.
Posté par kowalsky . Évalué à 7.
Ba oui mais non... A part les grosses usines à gaz en javascript genre webos (que j'adore d'ailleurs :)), le web, ça sert à diffuser de l'information.
Le "problème" c'est la méthode de diffuser les informations qui à changé. On est passé de la page à papy, écrite directement en html sous un éditeur de texte à des pages généré depuis une base de donnée avec des scripts créée aussi parfois coté serveur. C'est sale ou pas, la n'est pas la question, mais ça se fait. JavaScript, que tout le monde l'aime ou pas, c'est bien utile, pour l'utilisateur et le développeur.
Prenons linuxfr par exemple. Le bouton pertinent, c'est du js, qui appelle le programme coté serveur score (dont le retour est rigolo d'ailleurs...). ça évite de recharger toute la page et ça fait gagner du temps coté serveur et coté client. Et c'est tout. Après que les choses se complexifie un peu ça ne transforme pas ton navigateur en VM. Et si certain navigateur implémente un VM pour javascript, cela ne change rien au navigateur en lui même, c'est juste un choix d'implémentation.
La le problème, et dans la plupart des cas, il n'est pas coté navigateur, mais coté serveur. Que l'on veuille mettre une interface web pour tout et n'importe quoi et mettre à la vue de tout le monde (littéralement) de quoi contrôler son bugtracker ici, mais ça peut être son autocom, son système de surveillance video, ou peut être une centrale nucléaire. Donc forcement, ça fait que ça complexifie un peu les choses coté serveur, on fait tout et n'importe quoi, on mélange métier et présentation, etc...
Mais bon, moi je trouve cela très bien de tout faire par le web, si ça n'était pas fait à travers le navigateur, chaque application développeraient son système d'interface graphique qu'il faudrait installer avec son lot de faille, et etc.
Finalement, cela serait surement pire...
[^] # Re: Web à tout faire.
Posté par Grunt . Évalué à 8.
Finalement, cela serait surement pire...
Ben non, ça serait pareil. On se mettrait d'accord sur une API commune, on aurait une VM qui lancerait des petites applications 'volatiles', avec des droits limités, comme le font déjà les navigateurs Web. Sauf que maintenant on leur demande, et de faire tourner des applications en JS, et de gérer des plugins tiers, et d'avoir un rendu qui va bien, et de faire gaffe à la sécurité sur tout ça, et de le faire le plus vite possible.
Si on regarde de près, la plupart des applications Web sont terriblement redondantes: forum avec j'aime/j'aime pas (Facebook propose aussi un truc du genre, non?), 36 000 applis Flash pour lire des vidéos, interfaces JS/Java/Flash de clavardage, webmails..
Ça serait vraiment plus propre d'utiliser un protocole dédié à chacun de ces types d'application (XMPP ou IRC pour le clavardage en direct, RTSP pour la vidéo, pourquoi pas une extension de NNTP pour gérer le plussage/moinssage sur les forums). D'avoir une application choisie, fiable, codée en dur, optimisée pour l'usage auquel elle est destinée, sécurisée car elle sait ce qu'elle devra gérer et sait ce qu'elle ne devra pas gérer (inutile de gérer la webcam sur un forum, par exemple).
Quand tu tombes sur des sites Web qui te disent "Viendez sur notre IRC" en te proposant une application javascript, et que tu dois fouiller pour trouver le nom du serveur et du canal, afin de les donner à ton client IRC, celui-la même qui ne pose pas trop de problèmes de sécurité, car il ne parle que l'IRC et n'a pas à interpréter un code non connu à l'avance comme c'est le cas avec du JS, tu te dis que y'a quelque chose de pourri au royaume du Web.
Donc, faire exécuter pleins d'applis différentes, que ce soit en natif ou via le navigateur, bof. Regrouper des usages similaires ou identiques, et les faire faire par une seule application native côté utilisateur, oui! :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Web à tout faire.
Posté par kowalsky . Évalué à 0.
Tu veux dire une interface en (qt/gtk/cocoa/windows) pour chaque site ? Avec la logique métiers coté serveur en un langage (comme aujourd'hui) et coté client en un autre langage ?
Et à chaque modif de ton site, il faut mettre à jour tout les clients ?
Maintenir une compatibilité pour chacun des à peu prêt 20 OS présent (avec les téléphones qui représente une part non négligeable des visites) ?
Toi, tu va relancer les métiers du web :)
Aujourd'hui, si ton client possède une navigateur web récent, roule ma loutre, c'est bon.
Ça serait vraiment plus propre d'utiliser un protocole dédié à chacun de ces types d'application (XMPP ou IRC pour le clavardage en direct, RTSP pour la vidéo, pourquoi pas une extension de NNTP pour gérer le plussage/moinssage sur les forums).
Déjà, premier problème, le réseau. HTTP, c'est du "non connecté". Tu envois ta requette, le serveur repond, ok merci bye. Il y a des petits mecanisme en plus pour faire du keep-alive, mais l'idée est la. Donc, niveau sécurité et ouverture de flux, c'est simple. Tu ouvre le 80 dans un sens, et roule ma loutre. Si tu rajoute tout un tas de protocol avec tout un tas de port dans tout un tas de direction, déjà, pour le nat/pat, c'est foutu et ensuite pour la sécurité réseau, c'est un peu plus poilu (mais on s'en fou, je te l'accorde).
fiable, codée en dur, optimisée pour l'usage auquel elle est destinée, sécurisée car elle sait ce qu'elle devra gérer et sait ce qu'elle ne devra pas gérer
Si tu sais faire ça pour 20 OS, tu dois être riche ou sous payé :)
Quand tu tombes sur des sites Web qui te disent "Viendez sur notre IRC" en te proposant une application javascript, et que tu dois fouiller pour trouver le nom du serveur et du canal, afin de les donner à ton client IRC, celui-la même qui ne pose pas trop de problèmes de sécurité, car il ne parle que l'IRC et n'a pas à interpréter un code non connu à l'avance comme c'est le cas avec du JS, tu te dis que y'a quelque chose de pourri au royaume du Web.
J'aurais plus confiance en la sécurité d'un client xml/javascript qu'en un client (autre que les grosses pointures connu) IRC. Le site web qui fait de l'IRC va juste envoyer les messages au client et recevoir les messages du client. Le client n'interprète rien (à part les styles, les smiley et autre conneries) et de plus personne ne peut connaitre son adresse IP (à part le serveur).
Mais bon, je te dis pas que tu à tord ou que j'ai raison, c'est une question de point de vue.
Écrire un chat (par exemple) pour la vingtaine d'OS sur le marché ou un équivalent en web.
Avec le couple tomcat/java/postgres coté serveur, XML entre le client et le serveur et javascript/html coté client,je pense que j'aurais fini en un mois. Si je dois me faire un truc dans un langage supporté partout, ça sera en je ne quelle langage... Et niveau sécurité, ce sera surement une passoire...
[^] # Re: Web à tout faire.
Posté par Grunt . Évalué à 3.
Une application dédiée à un usage, qui tourne sur plein d'OS? Ben.. y'a qu'à regarder le nombre de plateformes sur lesquelles VLC, Gajim ou irssi sont portés.
Je parlais bien de 'une application pour une utilisation' et pas 'une VM pour va savoir quoi', hein :)
J'aurais plus confiance en la sécurité d'un client xml/javascript qu'en un client (autre que les grosses pointures connu) IRC.
Je parle bien de choisir son client. Actuellement, on te dit "Va sur notre page et laisse javascript faire ce qu'il veut". Je préfère "Prends le client IRC de ton choix, et dis lui de te connecter au salon machin du serveur truc."
Le client n'interprète rien (à part les styles, les smiley et autre conneries) et de plus personne ne peut connaitre son adresse IP (à part le serveur).
Le client que je choisis interprète ce que je lui demande d'interpréter. Va désactiver les smileys sur une interface Web.
Et qu'on connaisse mon IP, franchement.. m'en tamponne le coquillard. Au contraire, ça fait connaître FDN.
Écrire un chat (par exemple) pour la vingtaine d'OS sur le marché ou un équivalent en web.
Avec le couple tomcat/java/postgres coté serveur, XML entre le client et le serveur et javascript/html coté client,je pense que j'aurais fini en un mois. Si je dois me faire un truc dans un langage supporté partout, ça sera en je ne quelle langage... Et niveau sécurité, ce sera surement une passoire...
Tes clients sont déjà écrits, ce sont des clients IRC (ou XMPP). Niveau sécurité y'a déjà du monde dessus. Toi t'as juste à ajouter le nom du serveur et du salon sur ton site, ça te prendra quelques minutes.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Web à tout faire.
Posté par kowalsky . Évalué à 2.
ça tourne sur tout les téléphones portables qui ont un navigateur web ?
Le client que je choisis interprète ce que je lui demande d'interpréter. Va désactiver les smileys sur une interface Web.
La on parle d'un site mal fait ou qui ne propose pas asser d'option. Pour avoir fait un système de chat en web, on pouvait desactiver les smileys et changer les styles, etc.
Tes clients sont déjà écrits, ce sont des clients IRC (ou XMPP). Niveau sécurité y'a déjà du monde dessus. Toi t'as juste à ajouter le nom du serveur et du salon sur ton site, ça te prendra quelques minutes. Oui mais si en plus je veux pouvoir voir le profils, parler en privé, envoyer des messages depuis le profil, etc, on va vite sortir du cadre d'IRC et il faudra tout recoder ou presque et ce pour tout les OS...
Sans compter faire la présentation exact que l'on veut...
[^] # Re: Web à tout faire.
Posté par El Titi . Évalué à 2.
ça tourne sur tout les téléphones portables qui ont un navigateur web ?
Tu veux dire que toutes les applis sur les stores dédiées à chaque site, c'est pour le chichi ?
[^] # Re: Web à tout faire.
Posté par kowalsky . Évalué à 2.
[^] # Re: Web à tout faire.
Posté par El Titi . Évalué à 2.
T'as déjà essayer de surfer sur un site quelconque plus de 10 mn sans piquer une crise de nerf.
Pourtant il existait un certain WAP qui devait régler le pb et la sauce n'a pas pris.
Serait-ce que le web for the masses, c'est pas ce qu'on croit ?
[^] # Re: Web à tout faire.
Posté par El Titi . Évalué à 7.
Déjà, premier problème, le réseau. HTTP, c'est du "non connecté". Tu envois ta requette, le serveur repond, ok merci bye. Il y a des petits mecanisme en plus pour faire du keep-alive, mais l'idée est la. Donc, niveau sécurité et ouverture de flux, c'est simple. Tu ouvre le 80 dans un sens, et roule ma loutre. Si tu rajoute tout un tas de protocol avec tout un tas de port dans tout un tas de direction, déjà, pour le nat/pat, c'est foutu et ensuite pour la sécurité réseau, c'est un peu plus poilu (mais on s'en fou, je te l'accorde).
Du coup on préfère encapsuler son propre protocole transactionnel à l'intérieur du seul protocole qui n'est pas prévu pour ca mais que les admins réseau le laisse passer ... comme il est ... simple : appelons le SOAP
Du coup on réimplémente tout ce qui existe déjà sur le desktop avec des frameworks imbitables dans leur conception qui tourne avec le seul langage autorisé et qui n'est pas prévu pour ça à l'origine. Appelons le AJAX
Riche idée !
Ca crée des emplois et ca fait tourner l'économie.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.