Domanda:
Come scoprire in quale linguaggio di programmazione è integrato un sito web?
storm
2016-03-11 16:26:44 UTC
view on stackexchange narkive permalink

Penso che sia fondamentale per i tester di sicurezza raccogliere informazioni su come funziona un'applicazione web e alla fine in quale lingua è scritta.

So che estensioni URL, intestazioni HTTP, cookie di sessione, commenti HTML e i fogli di stile possono rivelare alcune informazioni, ma è ancora difficile e non garantito.

Quindi mi chiedevo: esiste un modo per determinare quale tecnologia e framework ci sono dietro un sito web?

Prova www.builtwith.com
Il mio server Tomcat restituisce "CERN httpd" solo per scherzare con le persone
La mia prima ipotesi sarebbe HTML
@HagenvonEitzen Se l'HTML fosse stato un linguaggio di programmazione, sarebbe stato chiamato HTPL invece che HTML.
"Penso che sia fondamentale per i tester di sicurezza raccogliere informazioni su come funziona un'applicazione web e in quale lingua è scritta. Penso che, se anche un tester di sicurezza non riesce a capire in quale lingua è integrato il sito, è più sicuro perché poi nessuno saprà quali exploit provare. (Sì, a volte ci sono casi d'uso validi per la sicurezza attraverso l'oscurità.)
@MasonWheeler: capire in quale lingua è integrato il sito determinerà solo quali exploit * non * provare. Ciò non renderà il sito più sicuro.
@BenoitEsnard bene, se un attaccante lo usa per determinare quali exploit * non * provare, allora sarebbe un miglioramento della sicurezza se un sito con successo induce in errore l'aggressore a pensare che sia qualcosa di diverso e quindi l'attaccante salta a tentare gli exploit "appropriati".
Sono solito essere soddisfatto semplicemente controllando .php o .aspx per identificare se il sito web è su PHP o su webform ASP.NET. Ora un giorno, con il routing degli URL e il framework MVC, è abbastanza difficile per me distinguere. : p grazie per la domanda.
Sei risposte:
Benoit Esnard
2016-03-11 16:54:24 UTC
view on stackexchange narkive permalink

Non c'è modo di essere sicuri al 100% se non si ha accesso al server, quindi si tratta di indovinare. Ecco alcuni indizi:

  • Estensioni di file: login.php è molto probabilmente uno script PHP.
  • Intestazioni HTTP: potrebbero trapelare alcune informazioni sulla lingua in esecuzione sul server e alcuni dettagli aggiuntivi come la versione: X-Powered-By: PHP / 7.0.0 significa che la pagina è stata visualizzata da PHP.
  • Inquinamento dei parametri HTTP: se sei riuscito a indovinare quale server è in esecuzione, puoi perfezionare l'ipotesi.
  • Limiti di lingua: numero massimo di dati post, numero massimo di variabili nei dati GET e POST, ecc. Può essere utile se il webmaster mantiene i valori predefiniti.
  • Input specifico: ad esempio, PHP conteneva alcuni easter egg.
  • Errori: l'attivazione di errori potrebbe anche far trapelare la lingua . Avviso: la divisione per zero in /var/www/html/index.php alla riga 3 è PHP, ad esempio.
  • Caricamenti di file: librerie può aggiungere metadati se il file viene modificato sul lato server. Ad esempio, la maggior parte dei siti ridimensiona gli avatar degli utenti e il controllo dei dati EXIF ​​perderà CREATOR: gd-jpeg v1.0 (utilizzando IJG JPEG v90), qualità predefinita , che può aiutare a indovinare quale lingua sia utilizzato.
  • Nomi di file predefiniti: controlla se / e /index.php sono la stessa pagina.
  • Exploit: lettura di un file di backup o esecuzione di codice arbitrario sul server.
  • Open source: il sito web potrebbe essere stato open source ed è disponibile da qualche parte su Internet.
  • Pagina Informazioni: il webmaster potrebbe aver ringraziato la comunità linguistica in una pagina "Domande frequenti" o "Informazioni".
  • Pagina di lavoro: il team di sviluppo potrebbe reclutare e potrebbe aver dettagliato le tecnologie che stanno utilizzando.
  • Ingegneria sociale: chiedi al webmaster!
  • Profili pubblici: se sai chi sta lavorando sul sito web (controlla LinkedIn e /humans.txt ), puoi controllare i loro repository pubblici o le loro competenze online profili (GitHub, LinkedIn, Twitter, ...).

Potresti anche voler sapere se il sito web è costruito con un framework o un CMS, poiché questo fornirà informazioni sulla lingua utilizzata:

  • URL: le directory e le pagine sono specifiche di determinati CMS. Ad esempio, se alcune risorse si trovano nella directory / wp-content / , significa che è stato utilizzato WordPress.
  • Cookie di sessione: nome e formato.
  • Token CSRF: nome e formato.
  • HTML di rendering: ad esempio: ordine dei meta tag, commenti.

Nota che tutte le informazioni provenienti dal server potrebbero essere alterate per ingannarti. Dovresti sempre provare a utilizzare più fonti per convalidare la tua ipotesi.

Dimentichi di menzionare alcuni esempi che provengono da Java che utilizzano generalmente un cookie JSESSIONID per la loro gestione della sessione. L'URL di accesso può tradire anche la tecnologia non conforme, ad esempio l'URL predefinito di primavera. Questi esempi sono per java ma sono sicuramente veri per alcuni altri
Solo una nota: solo perché le intestazioni http * dicono * sono alimentate da php, non significa che il sito lo sia effettivamente. Sebbene questo esempio riguardi più la piattaforma server, conosco un ragazzo che farebbe sì che il suo server nginx restituisca Server: Microsoft-IIS / 5.0 ad ogni richiesta in modo da poter indurre gli aggressori a utilizzare gli attacchi sbagliati contro il server. "È troppo facile!" ~ * l'attaccante *. Hai ragione su questo! (Questo dimostra solo che non puoi fidarti delle intestazioni)
Mi è piaciuta la tecnica dell'inquinamento dei parametri .. Sono sicuro che ci sono molti altri modi però
@Walfrat: Ho appena dettagliato la parte CMS / framework!
@AhmedJerbi: Ho aggiunto più tecniche.
@Benoit: grazie .. Molti documenti da leggere per il fine settimana :-)
Un altro buon metodo è controllare la fonte per vedere se ci sono segni rivelatori dell'uso di un motore di template specifico per una lingua.
Hai dimenticato uno dei più semplici: guardare la pagina dei lavori. :)
Nitpick: i primi 9 ti diranno solo quale lingua è stata usata per * distribuire * il sito, non per * costruirlo *. Ad esempio, se determini che il sito è stato distribuito su una JVM, questo non ti dice molto, ci sono oltre 400 lingue con implementazioni per la JVM, il sito potrebbe essere stato costruito in Scala, Groovy, Clojure (che ha anche implementazioni per CLI ed ECMAScript), Fantom (idem), Ruby (JRuby), Python (Jython), PHP (IBM P8, Quercus), ECMAScript (Mozilla Rhino, Oracle Nashorn, dyn.js). Lo stesso vale per la CLI (IronPython, IronRuby, IronJS, ...). Ci sono anche molti compilatori che ...
... target PHP: haXe, Hack, Wasabi, ...
@mowwwalker: ho aggiunto quel segno sotto la parte "HTML renderizzato". Non sono sicuro che stavi pensando a un altro segno, quindi fammi sapere se mi sono perso qualcosa!
Che ne dici di human.txt?
O forse ti sto trollando. /cgi-bin/postcomment.exe risulta essere uno script ksh.
Se c'è un campo nascosto chiamato "__VIEWSTATE" e / o se i pulsanti dicono "href = javascript: __ doPostBack" è probabile asp.net. Dalla parte superiore della mia testa non riesco a pensare a "firme" comparabili in altre piattaforme, ma, ecc.
Stephan
2016-03-11 23:07:29 UTC
view on stackexchange narkive permalink

Per indovinare il linguaggio di programmazione, puoi seguire l'approccio in tre passaggi descritto di seguito:

PASSAGGIO 1 - Cerca le prove sul sito stesso

Manualmente ...

  • Cerca in una pagina del sito in basso frasi come:

    -> "Powered by XXX" -> "Proudly Powered by XXX"
    -> "In esecuzione su XXX"
    -> ...

  • Cerca nel sito se parteciperà a una conferenza dove potrebbero parlare del sito web da un punto di vista tecnico

... o con l'aiuto di uno strumento

  • Leggi il codice HTML scaricato dal tuo browser

  • Fuoco sulla scheda Rete nella barra degli strumenti dello sviluppatore e studia gli scambi effettuati tra il browser e il server.

  • Cerca qualche pagina nascosta nota:

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

    Se ottieni 200, il sito potrebbe essere in esecuzione su una piattaforma pubblica (fr ee, a pagamento, ecc.) disponibile.

PASSAGGIO 2 - Cerca prove sul Web

Chiedi ai motori di ricerca di errori front-end

Puoi cercare alcuni errori prodotti dal sito web.

  • Alcune parole chiave da digitare in un motore di ricerca:

    • Errore 500 sito: the-site.com
    • Eccezione sito: the-site.com
    • ...
    • <what ever> site: the-site.com
      => Puoi semplicemente sostituire "<what ever>" con un messaggio di errore noto prodotto dalle varie tecnologie web.

Chiedi motori di ricerca per errori di back-end

Puoi anche indovinare le tecnologie utilizzate nel backend:

  • ORA-12170 site: the-site.com
    => Se trovi qualcosa, il sito potrebbe utilizzare Oracle nella sua parte di backend.

Chiedi ai motori di ricerca i concorrenti del sito web

  • Scopri che tecnologia è popolare nel settore dei siti web

  • Trova la tecnologia utilizzata dai concorrenti

  • Trova confronti del sito con altri concorrenti.
    Questi confronti potrebbero parlare di tecnologie in uso

Sondaggio tecnologico siti

Questi siti possono fornire ottime informazioni al sito targetizzato. Potrebbero aver già svolto una parte del lavoro per te.

  • http://w3techs.com/sites
    => Inserisci l'URL del sito che stai mirando e vedi quali tecnologie (lato client o lato server) sono state rilevate.
    Tieni presente che il sito deve essere nella prima classifica di 1 milione di Alexa.

  • http://stackshare.io/search/q=<keyword>
    => <keyword> può essere qualsiasi nome dell'azienda, sito web nome, ecc.

PASSAGGIO 3 - Analizza i risultati

Le prove che hai trovato nel passaggio 1 potrebbero essere errate perché il proprietario del sito può modificarli. Prova a trovare contraddizioni tra queste prove. Elimina le prove contraddittorie.

Unisci le prove nel passaggio 2 tra le varie fonti e le tue. Ancora una volta elimina le prove contraddittorie.

Riprendi tutti i tuoi risultati in una tabella come quella seguente. 

  + ------------- + - ---------- + ------------------ + ... + ---------- + ----- - + -------- + | EVIDENZE | IN SITO | Motore di ricerca 1 SOURCE n SCORE PCT (%) + ------------- + ------------------------- ----- + ... + ---------- + ------- + -------- + | PHP 7 | X | X | X | 3 | 300 / n + ------------- + ------------------------------ + .. . + ---------- + ------- + -------- + | Wordpress | | X | X | 2 | 200 / n + ------------- + ------------------------------ + .. . + ---------- + ------- + -------- + ... + ------------- + - ---------------------------- + ... + ---------- + ------ - + -------- + | PROVE m | | | | | (100 * PUNTEGGIO) / n
+ ------------- + ------------------------------ + ... + ---------- + ------- + -------- +

Infine, potrai dire "I" Sono sicuro al XX% che questo sito venga eseguito su YY (EVIDENZA i) ".

Sembra un'utile guida passo passo, ma probabilmente è una cattiva idea presentare il punteggio di confidenza arbitrario come percentuale.Anche se un server ottiene un punteggio perfetto, potrebbe benissimo essere un honeypot assemblato con cura, quindi non dovresti dire che sei sicuro al 100% che non lo sia.
-1
Qualcosa come "Concludo che questo sito viene eseguito su YY con un punteggio di affidabilità di XX" forse?Il problema è che la percentuale assomiglia un po 'troppo a una probabilità.
Manish Kumar
2016-03-11 21:14:37 UTC
view on stackexchange narkive permalink

È semplice. Aggiungi l'estensione Wapplyzer disponibile per Chrome e Firefox.

Descrive il linguaggio di programmazione, il server, lo strumento di analisi o i framework CMS & su quale sito web è costruito.

Provalo, lo adorerai.

Sembra buono .. ma è affidabile e preciso?
Sì, è molto accurato. Lo sto usando dagli ultimi 4 anni e anche sui miei siti Web sviluppati. È sempre accurato.
Non credo che possa essere considerato accurato. Abbiamo intenzionalmente falsificato le nostre intestazioni inviate per restituire IIS. Avere un wp-admin.php anche se non usiamo Wordpress. E molti altri vasi di miele. Il nostro sito è in realtà un'applicazione Node.js che restituisce contenuto statico.
L'ho appena scaricato perché è accurato come può essere. Ovviamente non può dire se le intestazioni vengono falsificate o meno.
@Ahmed funziona [scansionando] (https://wappalyzer.com/suggestions) l'HTML, le intestazioni, l'URL e le variabili JavaScript su una pagina. Ovviamente è buono quanto le regole usate per il rilevamento, ma ho trovato che sia giusto quasi sempre. (Ma, ovviamente, qualsiasi pagina web può essere configurata per fingere di eseguire qualcosa che non è.)
Ingegneria sociale: chiedi come identificare il software utilizzato per servire le pagine web su StackExchange e attendi che le persone dicano su cosa gira il loro sito. Grazie, @BradMetcalf ...
Dan Dascalescu
2016-03-12 03:41:04 UTC
view on stackexchange narkive permalink

Oltre all'estensione per browser Wappalizer, esistono diversi siti che rilevano le tecnologie che alimentano un determinato sito Web:

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

La risposta è che non puoi mai "essere certo". Mentre il 99,9% delle volte le risposte più votate troveranno i "tell" del framework dietro il sito, ma non è mai una certezza.

Fondamentalmente il tuo browser riceve i risultati finali dell'elaborazione dei codici. (html, CSS e JavaScript) Tra te e il codice stesso si trova un server web (nginx, Apache ecc.) E potenzialmente un bilanciatore del carico e un CDN. Poiché non interagisci direttamente, non c'è modo di avere certezza.

Se un sito web offre contenuti da wp-uploads / È una scommessa sicura che utilizzi Wordpress ma non è una certezza. Forse il sito utilizzava Wordpress, ma quando è stato migrato a qualcos'altro il wp-uploads / path è stato mantenuto per evitare di rompere collegamenti e segnalibri.

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

A volte puoi saperlo, a volte no.

Se l'HTML viene generato sul lato client, puoi facilmente capire quale lingua guardando la fonte nel tuo browser web. Questi linguaggi includono: ruby ​​on rails, javascript, java, ecc. Sul lato client il sorgente è aperto all'utente e deve essere onesto su quale tecnologia sia.

Se viene generato l'HTML sul lato server potresti non sapere quale linguaggio di programmazione l'ha generato. Questi linguaggi includono: PHP, C ++ e molti altri linguaggi. Sul lato server, per quanti modi ti vengono in mente di indovinare quale lingua è, ci sono altrettanti modi per nascondere la tecnologia.

Supponi di essere un amministratore web che vuole nascondere la tecnologia lato server. Scegli una delle tecniche elencate in un'altra domanda per tentare di identificare la lingua. Ad esempio, l'estensione * .php per un file. Ora, configura il tuo server web per eseguire codice C da un file con estensione * .php. I tuoi utenti non avranno modo di visualizzare il sorgente (poiché entrambe le lingue sono ugualmente in grado di produrre lo stesso output, per completezza di Turing), ma saranno indotti a pensare che tu stia utilizzando PHP.

Perché qualcuno dovrebbe vuoi offuscare la scelta della tecnologia lato server? Perché i linguaggi CGI hanno varie vulnerabilità che sono più facili da prendere di mira se gli utenti finali sanno quale di quelle lingue stai utilizzando. Indurre in errore gli utenti sulle tecnologie lato server che stai utilizzando è una misura di sicurezza molto ragionevole.

Non ho downvote, ma questa risposta trascura le numerose tecniche disponibili per determinare il linguaggio e la tecnologia lato server.
Per cominciare, Ruby on Rails e Java sono perfettamente in grado di generare HTML interamente sul lato server.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...