Question:
Comment savoir dans quel langage de programmation un site Web est intégré?
storm
2016-03-11 16:26:44 UTC
view on stackexchange narkive permalink

Je pense qu'il est fondamental pour les testeurs de sécurité de recueillir des informations sur le fonctionnement d'une application Web et éventuellement dans la langue dans laquelle elle est écrite.

Je sais que les extensions d'URL, les en-têtes HTTP, les cookies de session, les commentaires HTML et Les feuilles de style peuvent révéler certaines informations, mais c'est toujours difficile et incertain.

Je me demandais donc: y a-t-il un moyen de déterminer quelle technologie et quel cadre se cachent derrière un site Web?

Essayez www.builtwith.com
Mon serveur tomcat renvoie "CERN httpd" juste pour déranger les gens
Ma première hypothèse serait HTML
@HagenvonEitzen Si HTML avait été un langage de programmation, il aurait été nommé HTPL plutôt que HTML.
`Je pense qu'il est fondamental pour les testeurs de sécurité de recueillir des informations sur le fonctionnement d'une application Web et la langue dans laquelle elle est écrite.` Je pense que si même un testeur de sécurité ne peut pas déterminer dans quelle langue le site est intégré, c'est plus sûr car personne ne saura alors quels exploits essayer. (Oui, il existe parfois des cas d'utilisation valables pour la sécurité par l'obscurité.)
@MasonWheeler: déterminer dans quelle langue le site est intégré déterminera uniquement les exploits * à ne pas * essayer. Cela ne rendra pas le site plus sécurisé.
@BenoitEsnard bien, si un attaquant l'utilise pour déterminer quels exploits * pas * essayer, alors ce serait une amélioration de la sécurité si un site réussissait à induire l'attaquant en erreur en lui faisant croire que c'est quelque chose de différent et ainsi l'attaquant ignore les exploits «appropriés».
J'avais l'habitude d'être satisfait en vérifiant simplement .php ou .aspx pour identifier si le site Web est sur PHP ou sur des formulaires Web ASP.NET. Aujourd'hui, avec le routage d'URL et le framework MVC, il m'est assez difficile de faire la différence. : p merci pour la question.
Six réponses:
Benoit Esnard
2016-03-11 16:54:24 UTC
view on stackexchange narkive permalink

Il n'y a aucun moyen d'être sûr à 100% si vous n'avez pas accès au serveur, il s'agit donc de deviner. Voici quelques indices:

  • Extensions de fichier: login.php est probablement un script PHP.
  • En-têtes HTTP: ils peuvent divulguer des informations sur la langue qui s'exécute sur le serveur, ainsi que des détails supplémentaires comme la version: X-Powered-By: PHP / 7.0.0 signifie que la page a été rendue par PHP.
  • Pollution des paramètres HTTP: si vous avez réussi à deviner quel serveur est en cours d'exécution, vous pouvez affiner la supposition.
  • Limites linguistiques: données de publication maximum, variable de nombre maximum dans les données GET et POST, etc. Cela peut être utile si le webmaster a conservé les valeurs par défaut.
  • Saisie spécifique: par exemple, PHP avait des œufs de Pâques.
  • Erreurs: les erreurs de déclenchement peuvent également laisser échapper le langage . Attention: la division par zéro dans /var/www/html/index.php à la ligne 3 est PHP, par exemple.
  • Importations de fichiers: bibliothèques peut ajouter des métadonnées si le fichier est en cours de modification côté serveur. Par exemple, la plupart des sites redimensionnent les avatars des utilisateurs et la vérification des données EXIF ​​entraînera des fuites de CREATOR: gd-jpeg v1.0 (en utilisant IJG JPEG v90), qualité par défaut , ce qui peut aider à deviner quelle langue est utilisé.
  • Noms de fichiers par défaut: Vérifiez si / et /index.php sont la même page.
  • Exploits: lecture d'un fichier de sauvegarde ou exécution de code arbitraire sur le serveur.
  • Open source: le site Web peut avoir été open-source et est disponible quelque part sur Internet.
  • Page À propos: le webmaster a peut-être remercié la communauté linguistique dans une page "FAQ" ou "À propos".
  • Page Emplois: l'équipe de développement est peut-être en train de recruter, et elle peut avoir détaillé les technologies qu'elle utilise.
  • Ingénierie sociale: demandez au webmestre!
  • Profils publics: si vous savez qui travaille sur le site Web (consultez LinkedIn et /humans.txt ), vous pouvez vérifier leurs dépôts publics ou leurs compétences en ligne profils (GitHub, LinkedIn, Twitter, ...).

Vous pouvez également vouloir savoir si le site est construit avec un framework ou un CMS, car cela donnera des informations à propos de la langue utilisée:

  • URL: les répertoires et pages sont spécifiques à certains CMS. Par exemple, si certaines ressources se trouvent dans le répertoire / wp-content / , cela signifie que WordPress a été utilisé.
  • Cookies de session: nom et le format.
  • jetons CSRF: nom et format.
  • HTML rendu: par exemple: ordre des balises meta, commentaires.

Notez que toutes les informations provenant du serveur peuvent être modifiées pour vous tromper. Vous devriez toujours essayer d'utiliser plusieurs sources pour valider votre supposition.

Vous oubliez de citer quelques exemples issus de Java qui utilisent généralement un cookie JSESSIONID pour leur gestion de session. L'URL de connexion peut également trahir une technologie sous-jacente, l'URL par défaut du printemps par exemple. Ces exemples sont pour java mais sont sûrement vrais pour certains autres
Juste une note: ce n'est pas parce que les en-têtes http * disent * qu'ils sont alimentés par php que le site l'est réellement. Bien que cet exemple concerne davantage la plate-forme serveur, je connais un gars qui ferait retourner son serveur nginx Server: Microsoft-IIS / 5.0 à chaque demande afin qu'il puisse tromper les attaquants en utilisant les mauvaises attaques contre le serveur. "C'est trop facile!" ~ * l'attaquant *. Vous avez raison à ce sujet! (Cela montre simplement que vous ne pouvez pas faire confiance aux en-têtes)
J'ai aimé la technique de pollution des paramètres. Je suis sûr qu'il existe de nombreuses autres façons
@Walfrat: Je viens de détailler la partie CMS / framework!
@AhmedJerbi: J'ai ajouté plus de techniques.
Merci @Benoit: .. Beaucoup de docs à lire pour le week-end :-)
Une autre bonne solution consiste à vérifier la source pour voir s'il existe des signes révélateurs de l'utilisation d'un moteur de création de modèles spécifique à un langage.
Vous avez oublié l'un des plus simples - en regardant la page des emplois. :)
Nitpick: les 9 premiers ne vous diront vraiment que la langue utilisée pour * déployer * le site, pas pour * le construire *. Par exemple, si vous déterminez que le site a été déployé sur une JVM, cela ne vous dit pas grand chose, il existe plus de 400 langues avec des implémentations pour la JVM, le site peut avoir été construit en Scala, Groovy, Clojure (qui a également des implémentations pour la CLI et ECMAScript), Fantom (idem), Ruby (JRuby), Python (Jython), PHP (IBM P8, Quercus), ECMAScript (Mozilla Rhino, Oracle Nashorn, dyn.js). Il en est de même pour la CLI (IronPython, IronRuby, IronJS,…). Il existe également de nombreux compilateurs qui…
… Cible PHP: haXe, Hack, Wasabi,…
@mowwwalker: J'ai ajouté ce signe sous la partie "HTML rendu". Je ne sais pas si vous pensiez à un autre signe, alors faites-moi savoir si j'ai raté quelque chose!
Et les humains.txt?
Ou peut-être que je vous traine. /cgi-bin/postcomment.exe s'avère être un script ksh.
S'il existe un champ masqué nommé "__VIEWSTATE", et / ou si les boutons indiquent "href = javascript: __ doPostBack", c'est probablement asp.net. Du haut de ma tête, je ne peux pas penser à des «signatures» comparables sur d'autres plates-formes, mais, etc.
Stephan
2016-03-11 23:07:29 UTC
view on stackexchange narkive permalink

Pour deviner le langage de programmation, vous pouvez suivre l'approche en trois étapes détaillée ci-dessous:

ÉTAPE 1 - Rechercher des preuves sur le site lui-même

Manuellement ...

  • Recherchez sur une page de site en bas des expressions comme:

    -> "Powered by XXX" -> "Proudly Powered by XXX"
    -> "Running on XXX"
    -> ...

  • Recherchez sur le site s'il participera à une conférence où ils pourraient parler du site d'un point de vue technique

... ou à l'aide d'un outil

  • Lisez le code HTML téléchargé par votre navigateur

  • Fire dans Onglet Réseau dans la barre d'outils développeur et étudiez les échanges effectués entre le navigateur et le serveur.

  • Recherchez une page cachée connue:

    wget -head http://the-site.com/private/admin

    Si vous en obtenez 200, le site peut fonctionner en public (en ee, payant, etc.) logiciels disponibles.

ÉTAPE 2 - Rechercher des preuves sur le Web

Interroger les moteurs de recherche sur les erreurs frontales

Vous pouvez rechercher certaines erreurs générées par le site Web.

  • Quelques mots clés à saisir dans un moteur de recherche:

    • Erreur 500 du site: the-site.com
    • Site d'exception: the-site.com
    • ...
    • <what ever> site: the-site.com
      => Vous pouvez simplement remplacer "<what ever>" par un message d'erreur connu produit par les différentes technologies Web.

Demandez moteurs de recherche d'erreurs back-end

Vous pouvez même deviner les technologies utilisées dans le backend:

  • site ORA-12170: the-site.com
    => Si vous trouvez quelque chose, le site utilise peut-être Oracle dans sa partie backend.

Demandez aux moteurs de recherche quels sont les concurrents du site

  • Trouvez la technologie populaire dans l'industrie des sites Web

  • Découvrez la technologie utilisée par les concurrents

  • Recherchez des comparaisons du site avec d'autres concurrents.
    Ces comparaisons peuvent parler des technologies utilisées

Enquête technologique sites

Ces sites peuvent fournir des informations intéressantes au site que vous ciblez. Ils ont peut-être déjà fait une partie du travail à votre place.

  • http://w3techs.com/sites
    => Entrez l'url du site que vous ciblez et voyez quelles technologies (côté client ou serveur) ont été détectées.
    Notez que le site doit être dans le premier classement Alexa 1M.

  • http://stackshare.io/search/q=<keyword>
    => <keyword> peut être n'importe quel nom de société, site Web nom, etc

ÉTAPE 3 - Analysez vos résultats

Les preuves que vous avez trouvées à l ' étape 1 sont peut-être fausses car le propriétaire du site peut les modifier. Essayez de trouver des contradictions entre ces preuves. Éliminez les preuves contradictoires.

Fusionnez les preuves de l ' étape 2 entre les différentes sources et les vôtres. Éliminez à nouveau les preuves contradictoires.

Reprenez tous vos résultats dans un tableau comme celui ci-dessous. 

  + ------------- + - ---------- + ------------------ + ... + ---------- + ----- - + -------- + | PREUVES | SUR PLACE | Moteur de recherche 1 SOURCE n SCORE PCT (%) + ------------- + ------------------------- ----- + ... + ---------- + ------- + -------- + | PHP 7 | X | X | X | 3 | 300 / n + ------------- + ------------------------------ + .. . + ---------- + ------- + -------- + | Wordpress | | X | X | 2 | 200 / n + ------------- + ------------------------------ + .. . + ---------- + ------- + -------- + ... + ------------- + - ---------------------------- + ... + ---------- + ------ - + -------- + | PREUVE m | | | | | (100 * SCORE) / n
+ ------------- + ------------------------------ + ... + ---------- + ------- + -------- +

Enfin, vous pourrez dire «je» Je suis convaincu à XX% que ce site fonctionne sur YY (EVIDENCE i) ".

Cela ressemble à un guide étape par étape utile, mais c'est probablement une mauvaise idée de présenter le score de confiance arbitraire en pourcentage.Même si un serveur obtient un score parfait, il pourrait très bien s'agir d'un pot de miel soigneusement assemblé, vous ne devriez donc pas dire que vous êtes sûr à 100% que ce n'est pas le cas.
@AugustJanse Comment présenter le score de confiance arbitraire?
Quelque chose comme "Je conclus que ce site fonctionne sur YY avec un score de confiance de XX" peut-être?Le problème est que le pourcentage ressemble un peu trop à une probabilité.
Manish Kumar
2016-03-11 21:14:37 UTC
view on stackexchange narkive permalink

C'est simple. Ajoutez l'extension Wapplyzer disponible pour Chrome ainsi que Firefox.

Elle parle du langage de programmation, du serveur, de l'outil d'analyse ou du CMS & Frameworks sur quel site Web est construit.

Essayez-le, vous allez l'adorer.

Cela semble bien .. mais est-ce fiable et précis?
Oui, c'est très précis. Je l'utilise depuis 4 ans et même sur mes propres sites Web développés. C'est toujours précis.
Je ne pense pas que cela puisse être considéré comme exact. Nous simulons volontairement nos en-têtes envoyés pour renvoyer IIS. Ayez un wp-admin.php même si nous n'utilisons pas Wordpress. Et plusieurs autres pots de miel. Notre site est en fait une application Node.js qui renvoie du contenu statique.
Je viens de le télécharger car il est aussi précis que possible. De toute évidence, il ne peut pas dire si les en-têtes sont usurpés ou non.
@Ahmed cela fonctionne en [scannant] (https://wappalyzer.com/suggestions) le HTML, les en-têtes, les URL et les variables JavaScript sur une page. C'est aussi bon que les jeux de règles utilisés pour la détection, bien sûr, mais j'ai trouvé que c'était presque toujours vrai. (Mais, bien sûr, n'importe quelle page Web peut être configurée pour faire semblant d'exécuter quelque chose qu'elle n'est pas.)
Ingénierie sociale: demandez comment identifier le logiciel utilisé pour servir des pages Web sur StackExchange et attendez que les gens disent sur quoi leur site fonctionne. Merci, @BradMetcalf ...
Dan Dascalescu
2016-03-12 03:41:04 UTC
view on stackexchange narkive permalink

Outre l'extension de navigateur Wappalizer, il existe plusieurs sites qui détectent les technologies qui alimentent un site Web donné:

Nath
2016-03-13 19:26:04 UTC
view on stackexchange narkive permalink

La réponse est que vous ne pouvez jamais "être assuré". Alors que 99,9% du temps, les réponses les plus votées trouveront les «indices» du cadre derrière le site, mais ce n'est jamais une certitude. (html, CSS et JavaScript) Entre vous et le code lui-même se trouve un serveur Web (nginx, Apache, etc.) et potentiellement un équilibreur de charge et un CDN. Parce que vous n'interagissez pas directement, il n'y a aucun moyen de certitude.

Si un site Web diffuse du contenu à partir de wp-uploads / Il y a fort à parier qu'il exécute Wordpress mais ce n'est pas une certitude. Peut-être que le site utilisait Wordpress mais quand il a été migré vers autre chose, le wp-uploads / path a été conservé pour éviter de casser les liens et les signets.

Brent Kirkpatrick
2016-03-12 04:04:08 UTC
view on stackexchange narkive permalink

Parfois, vous pouvez savoir, parfois vous ne pouvez pas.

Si le HTML est généré côté client, vous pouvez facilement dire quelle langue en regardant la source dans votre navigateur Web. Ces langages incluent: ruby ​​on rails, javascript, java, etc. Du côté client, la source est ouverte à l'utilisateur, et il doit être honnête quant à la technologie dont il s'agit.

Si le HTML est généré côté serveur, vous ne savez peut-être pas quel langage de programmation l'a généré. Ces langages incluent: PHP, C ++ et de nombreux autres langages. Côté serveur, pour autant de façons que vous pouvez imaginer de deviner de quelle langue il s'agit, il y a autant de façons pour que la technologie se cache.

Supposons que vous soyez un administrateur Web qui veut cacher la technologie côté serveur. Choisissez l'une des techniques énumérées dans une autre question pour tenter d'identifier la langue. Par exemple, l'extension * .php d'un fichier. Maintenant, configurez votre serveur Web pour exécuter du code C à partir d'un fichier avec une extension * .php. Vos utilisateurs n'auront aucun moyen d'afficher la source (puisque les deux langues sont également capables de produire le même résultat, par l'exhaustivité de Turing), mais ils seront induits en erreur en pensant que vous utilisez PHP.

Pourquoi quelqu'un vous voulez masquer le choix de la technologie côté serveur? Parce que les langages CGI ont diverses vulnérabilités qui sont plus faciles à cibler si les utilisateurs finaux savent lesquels de ces langages vous utilisez. Induire les utilisateurs en erreur sur les technologies côté serveur que vous utilisez est une mesure de sécurité très raisonnable.

Je n'ai pas voté contre, mais cette réponse néglige les nombreuses techniques disponibles pour déterminer le langage et la technologie côté serveur.
Pour commencer, Ruby on Rails et Java sont parfaitement capables de générer du HTML entièrement côté serveur.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...