Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre extrêmement actif
    Avatar de Bruno
    Homme Profil pro
    Enseignant
    Inscrit en
    mai 2019
    Messages
    144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : mai 2019
    Messages : 144
    Points : 10 419
    Points
    10 419
    Par défaut 50 % des sites web utilisent WebAssembly à des fins malveillantes
    50 % des sites web utilisent WebAssembly à des fins malveillantes,
    selon une étude de la Technische Universität Braunschweig

    Pour permettre aux sites web d’être rapides, efficaces, portables et sécurisés, les développeurs de site web ou d’applications web utilisent généralement WebAssembly (Wasm). Wasm est un standard du World Wide Web pour le développement d’applications, pouvant être exécuté dans les navigateurs modernes et fournissant de nouvelles fonctionnalités ainsi qu’une optimisation considérable du temps d’exécution. Il fournit également un moyen d'exécuter un code écrit dans divers langages (C, C ++ ou Rust). Malheureusement, la plupart des logiciels malveillants les plus sophistiqués sur le web ont des scripts malveillants dissimulés dans des iFrames (élément permettant aux développeurs de sites web d’intégrer dans une page HTML le contenu d'une autre page HTML).

    Nom : img1456.png
Affichages : 30868
Taille : 23,8 Ko

    Plus tôt cette année, une étude réalisée par les universitaires Marius Musch, Christian Wressnegger, Martin Johns et Konrad Rieck de l’université technique de Brunswick en Allemagne, a révélé que plus de 50 % des sites utilisant Wasm ont des motivations malintentionnées, telles que l'extraction de crypto-monnaie et l'obscurcissement du code malveillant. L'injection d'iFrames malveillants dans des sites web fiables est devenue une technique d'attaques bien appréciée des acteurs de la menace.

    L’acteur de la menace peut utiliser l’injection SQL pour injecter l'iFrame malveillant dans la base de données principale du site web de la victime. Une attaque par injection SQL consiste à insérer une requête SQL via les données d'entrée du client dans l'application. La présence d’une page web malveillante chargée avec iFrame peut être rendue invisible en utilisant le moins de pixels possible. Quelquefois, non seulement la page d'accueil du site web légitime est infectée, mais toutes les autres pages du site web peuvent également être infectées. Dans la capture d'écran de Wireshark ci-dessous, un paquet HTTP entre le site web compromis et l'hôte de la victime contient un iFrame avec <iframe src = 'lien' style =' width: 10px; hauteur: 10px frameborder = 'no'> </ iframe> en tant que source iFrame.

    Nom : IMG2456.png
Affichages : 3535
Taille : 186,2 Ko
    Dans cet exemple, le logiciel malveillant était un kit d’exploitation


    L'équipe de recherche de l’institut pour la sécurité des applications et l'institut de la sécurité des systèmes de l’université technique de Brunswick a examiné un certain nombre de sites web sur une période de quatre jours. Les conclusions de ses travaux ont révélé que : 950 modules Wasm ont été trouvés sur 1 639 sites, soit environ un site sur 600. Une partie importante de ces modules n'était pas chargée sur la page d'accueil du site, mais sur des sous-pages, souvent via un script tiers ou une iframe provenant d’un tiers (795 sites de l'échantillon étaient concernés). Alors que 87 modules Wasm se trouvaient sur un unique site (indiquant un développement personnalisé pour ce site web particulier) certains modules Wasm pouvaient se retrouver sur plusieurs sites à l’exemple d’un module qui a été trouvé sur 346 sites différents.

    En outre, l'étude a également fourni des données sur l'étendue de l'utilisation de Wasm dans des sites web pertinents, en utilisant deux indicateurs à cet effet. Le premier est la taille du module Wasm, allant de 8 octets à 25,3 Mo, avec une valeur médiane de 100 Ko par module. L'étude indique que certains sites testaient simplement si le navigateur pouvait prendre en charge Wasm, alors que d'autres sites s'appuient essentiellement sur les fonctionnalités exposées par le module.

    Sources : Technische Universität Braunschweig - New Kid on the Web: A Study on thePrevalence of WebAssembly in the Wild

    Et vous ?

    Saviez-vous que des sites fiables pouvaient être des vecteurs d'attaques contre vous ?

    Selon-vous, comment se protéger de cette technique d'attaque ?

    Quelle est la valeur réelle de cette étude ? Pertinente ou pas ?

    Voir aussi :

    Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude

    RustPython, un interpréteur Python écrit en Rust et compatible avec WebAssembly, est disponible, pourrait-il rivaliser avec CPython ?

    Avec WASI, une interface système pour exécuter WebAssembly en dehors du Web, Mozilla voudrait apporter un nouveau standard à l'industrie
    Bien avec vous.

  2. #2
    Nouveau Candidat au Club
    Homme Profil pro
    historien & product owner
    Inscrit en
    mai 2018
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Algérie

    Informations professionnelles :
    Activité : historien & product owner

    Informations forums :
    Inscription : mai 2018
    Messages : 605
    Points : 0
    Points
    0
    Par défaut
    Merci pour l'article tres interessant.

    webassembly semble etre encore pas assez mature et présente des failles, il vaut mieux ne pas l'utliser pour l'instant et attendre encore quelque sannées.

    de toute façon cette techno n'a peu d’intérêt aujourd'hui, je veux dire celui qui fais de grosses applies lourde sur une page web sa court pas les rue non plus.... et es ce une bonne pratique quand on peut utiliser des clients lourds qui ont des api bas niveau permettant l'exploitation du matériel ? par rapport à un ersatz bricolé comme web assembly.

  3. #3
    Membre régulier
    Homme Profil pro
    Lycéen
    Inscrit en
    août 2018
    Messages
    37
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 16
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : Lycéen

    Informations forums :
    Inscription : août 2018
    Messages : 37
    Points : 108
    Points
    108
    Par défaut
    Miner des cryptomonnaies avec un CPU ?? Ben il y en a qui ont du temps à perdre ! Surtout que quand un module wasm tourne en arrière plan, il empêche tout rafraichissement de la page et fait planter l'onglet (le fait hang) si il tourne trop longtemps ! Il est clairement impossible de faire un mineur de cryptomonnaies.
    Comment est il possible d'injecter un code malveillant dans un site fiable ?? Wasm est soumis aux politiques de sécurité des navigateurs. De la même manière que javascript. Il ne peux RIEN faire de plus que javascript ! Injecter du code dans un iframe est IMPOSSIBLE dans les navigateurs modernes (le navigateur le bloque tout simplement).
    Il me semble que ceux qui ont fait l'étude ait tendance à crier au loup dès qu'ils ont des résultats. Ils feraient bien de les vérifier.
    J'ai beaucoup beaucoup tryhard sur wasm ces derniers temps. Il peux très difficilement être utilisé d'une manière qui nuit à l'utilisateur car l'attaquant ne peux pas faire grand chose d'utile en restant invisible.
    Wasm existe pour sa vitesse et son bas niveau. Wasm marche du tonnerre ! Ce n'est pas une évolution, c'est une révolution.

  4. #4
    Membre éclairé
    Homme Profil pro
    Consultant en technologies
    Inscrit en
    juin 2013
    Messages
    206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2013
    Messages : 206
    Points : 674
    Points
    674
    Par défaut
    Miner des cryptomonnaies avec un CPU ?? Ben il y en a qui ont du temps à perdre ! Surtout que quand un module wasm tourne en arrière plan, il empêche tout rafraichissement de la page et fait planter l'onglet (le fait hang) si il tourne trop longtemps !
    Bien sur que non, WebAssembly peut donner des instructions au GPU via WebGL (c'est ce qui est fait de base quand tu utilises emscripten). Et avec les workers en arrière plan je sais pas si c'est possible de donner des instructions GPU par contre, mais si tu fais ça bien tu peux largement faire tourner le script un moment sans faire planter l'onglet. Pdt un moment des sites presses donnaient la possibilité de lire les articles en minant de la crypto pendant la lecture, je trouvais que ça faisait un business modèle alternatif à la pub intéressant.

  5. #5
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 879
    Points : 11 209
    Points
    11 209
    Par défaut
    Citation Envoyé par ShigruM Voir le message
    Merci pour l'article tres interessant.

    webassembly semble etre encore pas assez mature et présente des failles, il vaut mieux ne pas l'utliser pour l'instant et attendre encore quelque sannées.
    Vous en avez compris que c'est WebAssembly qui causait des failles de sécurité alors qu'il n'en est rien.

    Les seules failles réelles abordées dans l'article sont des injections SQL. Une partie des hackers a choisi d'utiliser ces failles pour exécuter du WebAssembly, mais ils auraient tout aussi bien pu exécuter du JavaScript pour arriver au même résultat.

  6. #6
    Nouveau Candidat au Club
    Homme Profil pro
    historien & product owner
    Inscrit en
    mai 2018
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Algérie

    Informations professionnelles :
    Activité : historien & product owner

    Informations forums :
    Inscription : mai 2018
    Messages : 605
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par Uther Voir le message
    Vous en avez compris que c'est WebAssembly qui causait des failles de sécurité alors qu'il n'en est rien.

    Les seules failles réelles abordées dans l'article sont des injections SQL. Une partie des hackers a choisi d'utiliser ces failles pour exécuter du WebAssembly, mais ils auraient tout aussi bien pu exécuter du JavaScript pour arriver au même résultat.
    tu devrait relire l'article, tu raconte n'importe quoi

  7. #7
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 879
    Points : 11 209
    Points
    11 209
    Par défaut
    Tu pourrais être plus précis sur ce sur quoi tu n'es pas d'accord ?

    L'étude ne montre pas que WebAssembly crée des failles de sécurité en soi. L'article évoque les faille d'injection SQL qui ne sont pas dues au WebAssembly. Certes cela pourrait permettre d'en injecter dans une page, mais ça ne permet rien que l'on ne pouvait déjà faire avec du JavaScript. L’intérêt du WebAssembly pour les usages malicieux est surtout qu'il permet de faire des mineurs de cryptomonnaie plus efficaces. Mais techniquement il ne permet rien de plus dangereux qu'avant.

  8. #8
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    2 102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 2 102
    Points : 13 773
    Points
    13 773
    Par défaut
    Citation Envoyé par Uther Voir le message
    L'étude ne montre pas que WebAssembly crée des failles de sécurité en soi
    C'est pas ce que l'étude montre ça c'est ton interprétation

    Citation Envoyé par Uther Voir le message
    L’intérêt du WebAssembly pour les usages malicieux est surtout qu'il permet de faire des mineurs de cryptomonnaie plus efficaces
    C'est bien ce que dis l'étude, entre autres, mais l'étude est très longue et montre plein d'autres choses. En fait la news n'est même pas un résumé de l'étude, c'est l'étude qu'il faut lire, et qui est intéressante.

    Citation Envoyé par Uther Voir le message
    mais au techniquement il ne permet rien de plus dangereux qu'avant.
    Tu te rends compte que c'est trivial ce que tu écris ? c'est comme si tu écrivais que le C ne fait rien de plus que ce que tu peux faire en assembleur.
    C'est pas l'objet de l'étude, que tu as pas lu je suppose.

    L'étude fait juste un constat c'est tout.
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  9. #9
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 879
    Points : 11 209
    Points
    11 209
    Par défaut
    Citation Envoyé par Pierre Louis Chevalier Voir le message
    C'est pas ce que l'étude montre ça c'est ton interprétation
    Ça n'est pas de l'interprétation : l'étude montre juste que parmi les sites du top Alexa qui utilisent WebAssembly, 50% l'utilisent à des fin malhonnêtes. Mais elle cite les usages et il ne s'agit pas d'exploitation de faille de sécurité mais de choses tout aussi possible en JavaScript. Webassembly permet juste de le faire avec de meilleures performances.

    Citation Envoyé par Pierre Louis Chevalier Voir le message
    C'est bien ce que dis l'étude, entre autres, mais l'étude est très longue et montre plein d'autres choses. En fait la news n'est même pas un résumé de l'étude, c'est l'étude qu'il faut lire, et qui est intéressante.
    J'ai fait l'effort de lire l'étude, contrairement a vous visiblement vu que, non, elle ne montre pas grand chose de plus. Le plus gros de l'étude consiste a présenter WebAssembly et leur protocole de mesure.
    La principale chose qui en ressort c'est que actuellement, le principal usage honnête de WebAssembly est les jeux et que les principaux usages malhonnêtes sont la cryptomonnaie et l'obfuscation, des choses faisables en JavaScript. A aucun moment il n'est indiqué qu'il sert à briser la sécurité.

    Citation Envoyé par Pierre Louis Chevalier Voir le message
    Tu te rends compte que c'est trivial ce que tu écris ? c'est comme si tu écrivais que le C ne fait rien de plus que ce que tu peux faire en assembleur.
    La différence c'est qu'on est dans un environnement sandboxé. Le WebAssembly pourrait théoriquement ouvrir des failles qui n'existaient pas auparavant. Il semble que c'est ce que ShigruM a compris de l'article, mais ça n'est pas ce que dit l'étude.

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    avril 2012
    Messages
    200
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2012
    Messages : 200
    Points : 368
    Points
    368
    Par défaut
    Je ne voudrais doucher l'enthousiasme ce certains ou certaines mais https://github.com/stevespringett/disable-webassembly

    How to Disable WebAssembly (WASM)

    WebAssembly (WASM) is an effort to increase performance of in-browser Javascript execution by introducing a highly-optimized binary format that executes at near-native speed. The potential of WASM is quite exciting with enoumous potential. All major browser vendors have enabled WebAssembly by default.

    Security Considerations

    WebAssembly increases the attack surface of any browser that supports it. In security engineering, countermeasures are typically employed to reduce risk to potential threats. Here are a few concerning aspects of WebAssembly:

    Web server sends WASM modules to browser in binary format
    WebAssembly execution relies on browser sandboxing for safety
    Transmission and execution does not require TLS, HSTS, or any other transport layer security mechanism
    Integrity checking is not possible as WASM modules are not required to be signed by their author
    A primary WebAssembly goal is to: provide developers with useful primitives and mitigations for developing safe applications.
    Based on the above facts, here are some potential threats in using browsers that support WebAssembly:

    Static code analysis becomes increasingly difficult as source code may not be available
    Sandboxing is prone to breakouts and effectiveness varies largely by implementation. Adobe Flash is an example of a technology that was sandboxed after a series of exploits, yet exploits and breakouts still occurred.
    Transmitting a binary executable format over an insecure channel is susceptible to man-in-the-middle attack.
    Code signing, the process of verifying software has not been tampered with, is not currently possible with WASM. WASM is selling itself as the ability to run desktop-like applications in the browser, yet the operating systems it supports all have code signing requirements for installed software. Allowing random drive-by software to execute unsigned seems to be a 'feature' of WebAssembly.
    WebAssembly assumes that 'safe applications' can be derived from language subsets and a few rules to prevent specific type of behavior. This is similar to blacklisting in the security world, a technique that rarely works. The specification omits the possibility of misuse cases from their security dialog. Exploits can occur in 'safe applications' simply by using the application in a way it wasn't designed to run. Since static code analysis is not currently possible, automatically identifying potential performance, insider-threats, security, and misuse cases is not possible.
    The WebAssembly specification does not address any of the above threats. Therefore, I have disabled WASM on my personal browsers and have discountinued use of browsers that do not allow WASM to be disabled. To be fair, many of the threats above also apply to Javascript, which can be statically analyzed or outright disabled.

  11. #11
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    3 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 3 879
    Points : 11 209
    Points
    11 209
    Par défaut
    C'est pas sympa de balancer des pavés de texte brut comme ça, en anglais, alors je vais faire un effort de vulgarisation

    Citation Envoyé par jpiotrowski Voir le message
    WebAssembly increases the attack surface of any browser that supports it. In security engineering, countermeasures are typically employed to reduce risk to potential threats. Here are a few concerning aspects of WebAssembly:
    En effet comme, tout nouvelle fonctionnalité, si elle contient des vulnérabilité, elles peuvent être exploitées. Si vous voulez un navigateur sûr, le plus simple est d'avoir un navigateur qui ne fait rien. C'est vrai que désactiver WebAssembly limite la surface d'attaque.
    Mais dans ce cas là, pour être vraiment efficace, mieux vaut désactiver JavaScript qui est responsable de la majorité des faille constatées dans les navigateurs, énormément plus que WebAssembly en fait.

    Citation Envoyé par jpiotrowski Voir le message
    Web server sends WASM modules to browser in binary format
    WebAssembly execution relies on browser sandboxing for safety
    Webassembly nécessite en effet d'être sandboxé pour la sécurité... comme JavaScript depuis plus d'une quinzaine d’années vu qu'il est compilé en JIT.

    Citation Envoyé par jpiotrowski Voir le message
    Transmission and execution does not require TLS, HSTS, or any other transport layer security mechanism
    Integrity checking is not possible as WASM modules are not required to be signed by their author
    WebAssembly n’intègre pas en son sein de mécanisme de contrôle d'intégrité, ... comme JavaScript depuis toujours.

    C'est le https qui gère ça. C'est vrai qu'il n'est pas obligatoire mais il devient la norme heureusement.
    Les systèmes avec leur propre système de signature comme les applet Java ou l'ActiveX, on a bien vu à l'usage que c'était un échec. Sur le web, il est normal de s'appuyer sur les mécanismes du navigateur.

    Citation Envoyé par jpiotrowski Voir le message
    Static code analysis becomes increasingly difficult as source code may not be available
    L’argument habituel des débutants en sécurité : Javascript c'est mieux on peux voir le code source.
    Sauf que le JavaScript ça s'obfusque très bien et on a facilement quelque chose de quasiment indéchiffrable. De l'autre coté le webassembly est certes téléchargé sous forme de binaire, mais il peut se désassembler très facilement sous une forme très lisible.
    Après comme le disait l'étude de l'article c'est vrai que le WebAssembly est moins bien couvert par les outils d'analyse statique actuel car il est plus récent. Mais il n'y a pas de raison que ça dure car il est justement beaucoup plus facile a analyser statiquement que le JavaScript car il est beaucoup plus simple.

    Citation Envoyé par jpiotrowski Voir le message
    Sandboxing is prone to breakouts and effectiveness varies largely by implementation. Adobe Flash is an example of a technology that was sandboxed after a series of exploits, yet exploits and breakouts still occurred.
    Le sandboxing peut être brisé, c'est vrai, mais ... comme dans JavaScript

    Citation Envoyé par jpiotrowski Voir le message
    Transmitting a binary executable format over an insecure channel is susceptible to man-in-the-middle attack.
    Je suis pas rassuré pour la fiabilité du type qui annonce ça, étant donné que WebAssembly n'est pas vraiment ce qu'on peut appeler un exécutable, vu qu'il doit être compilé par le navigateur.
    Après transmettre quoi que ce soit (binaire ou non, exécutable ou non) par une connexion non sécurisée est en effet susceptible d'être exploité par un homme du milieu... comme JavaScript.

    Citation Envoyé par jpiotrowski Voir le message
    Code signing, the process of verifying software has not been tampered with, is not currently possible with WASM. WASM is selling itself as the ability to run desktop-like applications in the browser, yet the operating systems it supports all have code signing requirements for installed software. Allowing random drive-by software to execute unsigned seems to be a 'feature' of WebAssembly.
    WebAssembly permet de faire tourner des applications non signées, ce qui serait un contournement des mesures de sécurité de l'OS ... comme JavaScript
    A noter que à ma connaissance MacOS est le seul qui exige des signatures pour les applications exécutées avec les droits utilisateurs comme un Navigateur et donc le WebAssembly.

    Citation Envoyé par jpiotrowski Voir le message
    WebAssembly assumes that 'safe applications' can be derived from language subsets and a few rules to prevent specific type of behavior. This is similar to blacklisting in the security world, a technique that rarely works. The specification omits the possibility of misuse cases from their security dialog. Exploits can occur in 'safe applications' simply by using the application in a way it wasn't designed to run. Since static code analysis is not currently possible, automatically identifying potential performance, insider-threats, security, and misuse cases is not possible.
    On peut trouver des moyens d’échapper au sandboxing par limitation du langage... comme en JavaScript.
    A noter que en plus du sandboxing au niveau du langage, les navigateurs font en plus de nos jours du sandboxing au niveau système.

    Citation Envoyé par jpiotrowski Voir le message
    The WebAssembly specification does not address any of the above threats. Therefore, I have disabled WASM on my personal browsers and have discountinued use of browsers that do not allow WASM to be disabled. To be fair, many of the threats above also apply to Javascript, which can be statically analyzed or outright disabled.
    Il reconnait quand même que tout ce qu'il dénonce s'applique a JavaScript, mais visiblement ça le choque moins car il est analysable et désactivable, pourtant Webassembly l'est tout autant si ce n'est plus.

    Bref si vous avez peur de WebAssembly vous devriez avoir encore plus peur de JavaScript.

  12. #12
    Membre averti
    Profil pro
    Inscrit en
    avril 2012
    Messages
    200
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2012
    Messages : 200
    Points : 368
    Points
    368
    Par défaut
    Pour Fiferox, on désactive ainsi dans about:config

    javascript.options.wasm double-clique pour basculer de true à false.

    La suite de l'article explique pour différents navigateurs.

  13. #13
    Nouveau Candidat au Club
    Homme Profil pro
    Intégrateur Web
    Inscrit en
    août 2019
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Intégrateur Web
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2019
    Messages : 1
    Points : 0
    Points
    0
    Par défaut faut-il s'inquiéter ?
    faut-il s'inquiéter ?

  14. #14
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2018
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Services de proximité

    Informations forums :
    Inscription : juin 2018
    Messages : 2
    Points : 2
    Points
    2
    Par défaut Merci Uther
    Ce que vous décrivez et explicitez et hashment instructif, merci.

    Jean

Discussions similaires

  1. Réponses: 8
    Dernier message: 01/03/2013, 16h06
  2. Site web utilisables pour un bug tracker
    Par Bayard dans le forum Autres
    Réponses: 0
    Dernier message: 29/08/2010, 11h58
  3. Réponses: 5
    Dernier message: 16/11/2009, 17h53
  4. Site web utilisant HTTPS
    Par nkonito dans le forum IIS
    Réponses: 4
    Dernier message: 31/12/2007, 12h00
  5. site web :faut-il utiliser des panels?
    Par jeprog dans le forum Flex
    Réponses: 3
    Dernier message: 15/11/2007, 13h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo