Pytanie:
Jak dowiedzieć się, w jakim języku programowania jest wbudowana strona internetowa?
storm
2016-03-11 16:26:44 UTC
view on stackexchange narkive permalink

Myślę, że dla testerów bezpieczeństwa fundamentalne znaczenie ma zbieranie informacji o działaniu aplikacji internetowej i ostatecznie w jakim języku jest napisana.

Wiem, że rozszerzenia adresów URL, nagłówki HTTP, pliki cookie sesji, komentarze HTML i Arkusze stylów mogą ujawnić pewne informacje, ale nadal jest to trudne i niepewne.

Zastanawiałem się więc: czy istnieje sposób, aby określić, jaka technologia i struktura stoją za witryną?

Wypróbuj www.builtwith.com
Mój serwer tomcat zwraca „CERN httpd” tylko po to, aby zadzierać z ludźmi
Moje pierwsze przypuszczenie to HTML
@HagenvonEitzen Gdyby HTML był językiem programowania, nazywałby się raczej HTPL niż HTML.
`` Myślę, że fundamentalne znaczenie dla testerów bezpieczeństwa ma zbieranie informacji o tym, jak działa aplikacja internetowa iw jakim języku jest napisana. '' Myślę, że nawet jeśli tester bezpieczeństwa nie może dowiedzieć się, w jakim języku jest wbudowana witryna, jest bezpieczniejszy, ponieważ wtedy nikt nie będzie wiedział, których exploitów spróbować. (Tak, czasami zdarzają się ważne przypadki użycia związane z bezpieczeństwem poprzez niejasność).
@MasonWheeler: ustalenie, w jakim języku jest wbudowana witryna, pozwoli tylko określić, które exploity * nie * należy wypróbować. Nie zwiększy to bezpieczeństwa witryny.
@BenoitEsnard, jeśli atakujący używa go do określenia, których exploitów * nie * ma spróbować, byłoby to poprawą bezpieczeństwa, gdyby witryna skutecznie wprowadziła atakującego w błąd, myśląc, że to coś innego, a zatem atakujący pomija próbowanie „odpowiednich” exploitów.
Aby być usatysfakcjonowanym, wystarczy sprawdzić .php lub .aspx, aby określić, czy witryna jest w PHP, czy w formularzach internetowych ASP.NET. Teraz dni, z routingiem URL i frameworkiem MVC, jest mi dość trudno to rozróżnić. : p dzięki za pytanie.
Sześć odpowiedzi:
Benoit Esnard
2016-03-11 16:54:24 UTC
view on stackexchange narkive permalink

Nie ma sposobu, aby być w 100% pewnym, że nie masz dostępu do serwera, więc chodzi o zgadywanie. Oto kilka wskazówek:

  • Rozszerzenia plików: login.php to najprawdopodobniej skrypt PHP.
  • nagłówki HTTP: mogą wyciekać pewne informacje o języku uruchomionym na serwerze i dodatkowe szczegóły, takie jak wersja: X-Powered-By: PHP / 7.0.0 oznacza, że ​​strona została wyrenderowana przez PHP.
  • Zanieczyszczenie parametrem HTTP: jeśli udało Ci się odgadnąć, który serwer jest uruchomiony, możesz sprecyzować przypuszczenie.
  • Limity językowe: maksymalna liczba danych postów, maksymalna liczba zmiennych w danych GET i POST itp. Może być przydatne, jeśli webmaster zachował wartości domyślne.
  • Określone dane wejściowe: na przykład PHP miało kilka pisanek.
  • Błędy: błędy uruchamiania mogą również powodować wycieki języka . Ostrzeżenie: dzielenie przez zero w /var/www/html/index.php w wierszu 3 to na przykład PHP.
  • Przesyłane pliki: biblioteki może dodać metadane, jeśli plik jest modyfikowany po stronie serwera. Na przykład większość witryn zmienia rozmiar awatarów użytkowników i sprawdzanie danych EXIF ​​spowoduje wyciek CREATOR: gd-jpeg v1.0 (przy użyciu IJG JPEG v90), domyślna jakość , co może pomóc w odgadnięciu, który język jest używane.
  • Domyślne nazwy plików: Sprawdź, czy / i /index.php to ta sama strona.
  • Exploity: odczytanie pliku kopii zapasowej lub wykonanie dowolnego kodu na serwerze.
  • Open source: witryna mogła mieć otwarte źródła i jest dostępny gdzieś w Internecie.
  • Strona z informacjami: webmaster mógł podziękować społeczności językowej na stronie „Często zadawane pytania” lub „Informacje”.
  • Strona z ofertami pracy: zespół programistów może rekrutować i szczegółowo opisać technologie, których używa.
  • Inżynieria społeczna: zapytaj webmastera!
  • Profile publiczne: jeśli wiesz, kto pracuje w witrynie (sprawdź LinkedIn i /humans.txt ), możesz sprawdzić ich publiczne repozytoria lub umiejętności w Internecie profile (GitHub, LinkedIn, Twitter, ...).

Możesz również chcieć wiedzieć, czy witryna jest zbudowana z wykorzystaniem frameworka lub CMS, ponieważ zawiera informacje o używanym języku:

  • URL-e: katalogi i strony są specyficzne dla niektórych CMS. Na przykład, jeśli niektóre zasoby znajdują się w katalogu / wp-content / , oznacza to, że został użyty WordPress.
  • Pliki cookie sesji: nazwa i format.
  • Tokeny CSRF: nazwa i format.
  • Rendered HTML: na przykład: kolejność metatagów, komentarze.

Zauważ, że wszystkie informacje pochodzące z serwera mogą zostać zmienione, aby Cię oszukać. Zawsze powinieneś próbować korzystać z wielu źródeł, aby potwierdzić swoje przypuszczenia.

Zapomniałeś wspomnieć o kilku przykładach pochodzących z Javy, które generalnie używają cookie JSESSIONID do zarządzania sesjami. Adres URL logowania może również zdradzić nieznaną technologię, na przykład domyślny adres URL wiosny. Te przykłady dotyczą języka Java, ale z pewnością są prawdziwe w przypadku innych
Uwaga: tylko dlatego, że nagłówki http * mówią *, że są zasilane przez php, nie oznacza, że ​​witryna faktycznie jest. Chociaż ten przykład dotyczy bardziej platformy serwerowej, znam gościa, który sprawiłby, że jego serwer nginx zwracałby serwer: Microsoft-IIS / 5.0 przy każdym żądaniu, aby mógł nakłonić atakujących do użycia niewłaściwych ataków na serwer. "To jest za łatwe!" ~ * napastnik *. Masz rację! (To tylko pokazuje, że nie możesz ufać nagłówkom)
Podobała mi się technika Parameter Pollution. Jestem pewien, że jest o wiele więcej sposobów
@Walfrat: Właśnie szczegółowo opisałem część CMS / framework!
@AhmedJerbi: Dodałem więcej technik.
@Benoit: dziękuję .. Wiele dokumentów do przeczytania na weekend :-)
Innym dobrym sposobem jest sprawdzenie źródła, aby zobaczyć, czy istnieją ostrzegawcze oznaki użycia jakiegoś silnika szablonów charakterystycznego dla danego języka.
Zapomniałeś o jednym z najprostszych - patrząc na stronę z ofertami pracy. :)
Nitpick: pierwsze 9 naprawdę powie Ci tylko, w jakim języku * wdrożono * witrynę, a nie * ją * zbudować. Np. Jeśli stwierdzisz, że witryna została wdrożona na JVM, to nie mówi ci wiele, istnieje ponad 400 języków z implementacjami JVM, witryna mogła zostać zbudowana w Scala, Groovy, Clojure (która również ma implementacje dla CLI i ECMAScript), Fantom (jw.), Ruby (JRuby), Python (Jython), PHP (IBM P8, Quercus), ECMAScript (Mozilla Rhino, Oracle Nashorn, dyn.js). To samo dotyczy CLI (IronPython, IronRuby, IronJS,…). Jest też wiele kompilatorów, które…
… Kieruj na PHP: haXe, Hack, Wasabi,…
@mowwwalker: Dodałem ten znak pod częścią „renderowany HTML”. Nie jestem pewien, czy myślałeś o innym znaku, więc daj mi znać, jeśli coś przegapiłem!
A co z people.txt?
A może cię trolluję. /cgi-bin/postcomment.exe okazuje się być skryptem ksh.
Jeśli istnieje ukryte pole o nazwie „__VIEWSTATE” i / lub jeśli przyciski mówią „href = javascript: __ doPostBack”, prawdopodobnie jest to strona asp.net. Nie mogę wymyślić porównywalnych „podpisów” na innych platformach, ale itd.
Stephan
2016-03-11 23:07:29 UTC
view on stackexchange narkive permalink

Aby odgadnąć język programowania, możesz wykonać trzy kroki opisane poniżej:

KROK 1 - Wyszukaj dowody w samej witrynie

Ręcznie ...

  • Wyszukaj na dole strony witryny frazy takie jak:

    -> „Obsługiwane przez XXX” -> "Dumnie wspierane przez XXX"
    -> "Działa w XXX"
    -> ...

  • Wyszukaj w witrynie, czy będzie ona uczestniczyła w konferencji, na której mogliby porozmawiać o witrynie z technicznego punktu widzenia.

... lub z pomocą narzędzia

  • Przeczytaj kod HTML pobrany przez przeglądarkę

  • Uruchom w górę zakładka Sieć na pasku narzędzi programisty i przestudiuj wymiany dokonane między przeglądarką a serwerem.

  • Wyszukaj jakąś znaną ukrytą stronę:

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

    Jeśli otrzymasz 200, witryna może działać na platformie publicznej (fr ee, płatne itp.).

KROK 2 - Wyszukaj dowody w sieci

Zapytaj wyszukiwarki o błędy w interfejsie

Możesz poszukać błędów generowanych przez witrynę.

  • Niektóre słowa kluczowe do wpisania w wyszukiwarce:

    • Witryna z błędem 500: the-site.com
    • Wyjątek site: the-site.com
    • ...
    • <what ever> site: the-site.com
      => Możesz po prostu zastąpić „<what ever>” jakimś znanym komunikatem o błędzie generowanym przez różne technologie sieciowe.

Zapytaj wyszukiwarki pod kątem błędów zaplecza

Możesz nawet odgadnąć technologie użyte w zapleczu:

  • ORA-12170 site: the-site.com
    => Jeśli coś znajdziesz, witryna może używać Oracle w swojej wewnętrznej części.

Zapytaj wyszukiwarki o konkurentów witryny

  • Dowiedz się, jaka technologia jest popularne w branży witryn internetowych

  • Dowiedz się, jakiej technologii używają konkurenci

  • Znajdź porównania witryny z innymi konkurentami.
    Te porównania mogą dotyczyć używanych technologii.

Ankieta dotycząca technologii witryny

Witryny te mogą dostarczać przydatnych informacji do witryny, na którą kierujesz reklamy. Być może wykonali już za Ciebie część pracy.

  • http://w3techs.com/sites
    => Wprowadź adres URL witryny, na którą kierujesz reklamy, i zobacz, jakie technologie (po stronie klienta lub serwera) zostały wykryte.
    Pamiętaj, że witryna musi znajdować się w pierwszym rankingu Alexa 1M.

  • http://stackshare.io/search/q=<keyword>
    => <keyword> może być dowolną nazwą firmy, witryną imię i nazwisko itp.

KROK 3 - Przeanalizuj swoje wyniki

Dowody znalezione w kroku 1 mogą być błędne, ponieważ właściciel witryny może je zmieniać. Spróbuj znaleźć sprzeczności między tymi dowodami. Wyeliminuj sprzeczne dowody.

Połącz dowody w kroku 2 między różnymi źródłami i swoimi. Ponownie wyeliminuj sprzeczne dowody.

Wznów wszystkie swoje ustalenia w tabeli takiej jak poniższa. 

  + ------------- + - ---------- + ------------------ + ... + ---------- + ----- - + -------- + | DOWODY | NA MIEJSCU | Wyszukiwarka 1 ŹRÓDŁO n SCORE PCT (%) + ------------- + ------------------------- ----- + ... + ---------- + ------- + -------- + | PHP 7 | X | X | X | 3 | 300 / n + ------------- + ------------------------------ + .. . + ---------- + ------- + -------- + | Wordpress | | X | X | 2 | 200 / n + ------------- + ------------------------------ + .. . + ---------- + ------- + -------- + ... + ------------- + - ---------------------------- + ... + ---------- + ------ - + -------- + | DOWODY m | | | | | (100 * PUNKTACJA) / n
+ ------------- + ------------------------------ + ... + ---------- + ------- + -------- +

Wreszcie będziesz mógł powiedzieć „ja” mam pewność na poziomie XX%, że ta witryna działa w dniu YY (DOWÓD i) ”.

Wygląda to na przydatny przewodnik krok po kroku, ale prawdopodobnie przedstawianie arbitralnego wyniku ufności w procentach jest złym pomysłem.Nawet jeśli serwer uzyska doskonały wynik, może to być starannie zmontowany honeypot, więc nie powinieneś mówić, że jesteś w 100% pewien, że tak nie jest.
@AugustJanse Jak można przedstawić arbitralny wynik zaufania?
Coś w stylu „Wnioskuję, że ta witryna działa na YY z wynikiem ufności XX”?Problem polega na tym, że procent wygląda trochę za bardzo jak prawdopodobieństwo.
Manish Kumar
2016-03-11 21:14:37 UTC
view on stackexchange narkive permalink

To proste. Dodaj rozszerzenie Wapplyzer dostępne dla Chrome, a także Firefox.

Informuje o języku programowania, serwerze, narzędziu analitycznym lub o CMS & Framework, w którym strona jest zbudowany.

Spróbuj, spodoba ci się.

To wydaje się dobre… ale czy jest rzetelne i dokładne?
Tak, jest bardzo dokładny. Używam go od 4 lat, a nawet na własnych opracowanych stronach internetowych. Zawsze jest dokładny.
Myślę, że nie można tego uznać za trafne. Celowo fałszujemy nasze wysłane nagłówki, aby zwrócić IIS. Miej wp-admin.php, nawet jeśli nie używamy Wordpress. I kilka innych garnków na miód. Nasza witryna jest w rzeczywistości aplikacją Node.js, która zwraca statyczną zawartość.
Właśnie pobrałem go tak, jak jest dokładny. Oczywiście nie może stwierdzić, czy nagłówki są fałszowane, czy nie.
@Ahmed działa poprzez [skanowanie] (https://wappalyzer.com/suggestions) HTML, nagłówki, URL i zmienne JavaScript na stronie. Oczywiście jest tak samo dobre, jak zestawy reguł używane do wykrywania, ale prawie zawsze sprawdzają się prawidłowo. (Ale oczywiście każdą stronę internetową można skonfigurować tak, aby udawała, że ​​działa coś, czym nie jest).
Inżynieria społeczna: zapytaj, jak zidentyfikować oprogramowanie używane do obsługi stron internetowych w StackExchange i poczekaj, aż ludzie powiedzą, na czym działa ich witryna. Dziękuję, @BradMetcalf ...
Dan Dascalescu
2016-03-12 03:41:04 UTC
view on stackexchange narkive permalink

Oprócz rozszerzenia przeglądarki Wappalizer istnieje kilka witryn, które wykrywają technologie napędzające daną witrynę:

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

Odpowiedź jest taka, że ​​nigdy nie można mieć „pewności”. Podczas gdy w 99,9% przypadków wysoko ocenione odpowiedzi znajdą „podpowiedzi” frameworka witryny, ale nigdy nie jest to pewne.

Zasadniczo Twoja przeglądarka otrzymuje końcowe wyniki przetwarzania kodów. (html, CSS i JavaScript) Pomiędzy tobą a samym kodem znajduje się serwer sieciowy (nginx, Apache itp.) i potencjalnie moduł równoważenia obciążenia i CDN. Ponieważ nie wchodzisz w interakcje bezpośrednio, nie ma sposobu na pewność.

Jeśli witryna obsługuje treści z plików wp-upload / Można bezpiecznie założyć, że działa na niej Wordpress, ale nie jest to pewne. Być może strona korzystała z Wordpress, ale kiedy została przeniesiona do czegoś innego, wp-uploads / path została zachowana, aby uniknąć zrywania linków i zakładek.

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

Czasami możesz wiedzieć, a czasami nie.

Jeśli kod HTML jest generowany po stronie klienta, możesz łatwo określić język, patrząc na źródło w przeglądarce internetowej. Te języki to: ruby ​​on rails, javascript, java itp. Po stronie klienta źródło jest otwarte dla użytkownika i musi być uczciwy co do tego, jaka to technologia.

Jeśli generowany jest kod HTML po stronie serwera możesz nie wiedzieć, który język programowania go wygenerował. Te języki obejmują: PHP, C ++ i wiele innych języków. Po stronie serwera, na tyle sposobów, na ile możesz zgadnąć, który to język, jest tyle samo sposobów, aby technologia mogła się ukryć.

Załóżmy, że jesteś administratorem sieci, który chce ukryć technologię po stronie serwera. Wybierz jedną z technik wymienionych w innym pytaniu, aby spróbować zidentyfikować język. Na przykład rozszerzenie * .php dla pliku. Teraz skonfiguruj swój serwer WWW tak, aby wykonywał kod C z pliku z rozszerzeniem * .php. Twoi użytkownicy nie będą mieli możliwości przeglądania źródła (ponieważ oba języki są równie zdolne do generowania tego samego wyniku, według kompletności Turinga), ale zostaną wprowadzeni w błąd, myśląc, że używasz PHP.

Dlaczego ktoś miałby chcesz zaciemnić wybór technologii po stronie serwera? Ponieważ języki CGI mają różne luki w zabezpieczeniach, które są łatwiejsze do wykrycia, jeśli użytkownicy końcowi wiedzą, którego z tych języków używasz. Wprowadzanie użytkowników w błąd co do używanych technologii po stronie serwera jest bardzo rozsądnym środkiem bezpieczeństwa.

Nie głosowałem przeciw, ale ta odpowiedź pomija liczne dostępne techniki określania języka i technologii po stronie serwera.
Po pierwsze, Ruby on Rails i Java doskonale potrafią generować HTML całkowicie po stronie serwera.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...