intitle: |
szuka frazy w tytule strony (znacznik )</td>
<td><code>intitle:"index of"</code></td>
</tr>
<tr>
<td><code>intext:</code></td>
<td>szuka frazy w treści strony</td>
<td><code>intext:"DB_PASSWORD"</code></td>
</tr>
<tr>
<td><code>filetype:</code> / <code>ext:</code></td>
<td>ogranicza do typu pliku</td>
<td><code>filetype:sql</code></td>
</tr>
<tr>
<td><code>"..."</code></td>
<td>dopasowanie dokładnej frazy</td>
<td><code>"Welcome to phpMyAdmin"</code></td>
</tr>
<tr>
<td><code>-</code> (minus)</td>
<td>wyklucza wyniki</td>
<td><code>site:przyklad.pl -inurl:www</code></td>
</tr>
<tr>
<td><code>OR</code> / `</td>
<td>`</td>
<td>alternatywa</td>
</tr>
</tbody></table>
<p>Najprostszy, a zarazem jeden z najważniejszych operatorów to <code>site:</code>. Połączony z <code>filetype:</code> pokazuje, jakie dokumenty Twojej domeny indeksuje Google. Sama liczba wyników zdradza skalę zasobu, a kombinacja z wykluczeniem <code>-inurl:www</code> potrafi odsłonić subdomeny deweloperskie i testowe, o których nikt już nie pamiętał.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>site:przyklad.pl filetype:pdf # dokumenty PDF z domeny
site:przyklad.pl filetype:xlsx # arkusze kalkulacyjne
site:*.przyklad.pl -inurl:www # subdomeny inne niz www
site:przyklad.pl intext:"poufne" # dokumenty oznaczone jako poufne
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/cnvx7e8vh1hatvmnpta7.png" alt="Wyniki Google dla zapytania site:jsystems.pl filetype:pdf - lista dokumentów PDF z domeny"/></p>
<p>Operator <code>site:</code> połączony z <code>filetype:pdf</code> zwraca wszystkie zaindeksowane dokumenty PDF domeny. W realnym audycie to często prezentacje, oferty, a nawet dokumenty wewnętrzne, których metadane zdradzają imiona autorów i ścieżki na serwerze.</p>
<h2>
<a name="indeksy-katalogów-gdy-serwer-pokazuje-wszystko" href="#indeksy-katalogów-gdy-serwer-pokazuje-wszystko" class="anchor">
</a>
Indeksy katalogów: gdy serwer pokazuje wszystko
</h2>
<p>Jeśli w katalogu na serwerze brakuje pliku startowego (np. <code>index.html</code>), a serwer ma włączone wyświetlanie zawartości katalogów (tzw. <strong>directory listing</strong>), przeglądarka pokaże spis plików jak okno menedżera plików. Tytuł takiej strony zaczyna się od „Index of", co czyni ją trywialną do odnalezienia.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>intitle:"index of" "backup" # otwarte katalogi z kopiami zapasowymi
intitle:"index of" "parent directory"
intitle:"index of" "*.sql" # katalogi ze zrzutami baz
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/mktexe8anq9093j4an9x.png" alt="Wyniki Google dla intitle:index of backup - lista otwartych katalogów z kopiami zapasowymi"/></p>
<p>Otwarte katalogi z kopiami zapasowymi. Wpis <code>[PARENTDIR]</code> i pliki typu <code>.zip</code> czy <code>.php</code> to klasyczna sygnatura listingu katalogu. Tu znajdują się archiwa, konfiguracje, a bywa, że całe bazy danych.</p>
<h2>
<a name="wystawione-panele-administracyjne" href="#wystawione-panele-administracyjne" class="anchor">
</a>
Wystawione panele administracyjne
</h2>
<p>Panel zarządzania, który miał być dostępny tylko z sieci wewnętrznej, regularnie trafia do indeksu. Sam formularz logowania nie jest jeszcze luką, ale dla atakującego to mapa: zdradza, jaki system stoi pod spodem, i staje się punktem startowym do testowania domyślnych haseł. Generyczne dorki działają najlepiej zawężone operatorem <code>site:</code> do badanej domeny. Jeśli zaś chcesz zobaczyć realne, żywe panele, celuj w napis interfejsu konkretnego producenta. Dobrym przykładem są routery MikroTik, których strona konfiguracyjna ma stały, charakterystyczny tytuł.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>site:przyklad.pl inurl:/admin/login.php # panele logowania w obrebie domeny
intitle:"RouterOS router configuration page" # panele routerow MikroTik (zywe urzadzenia)
intitle:"Login" inurl:/admin -site:github.com # bez stron z poradnikami
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/hphmzr5cu0hqc69qn78p.png" alt="Wyniki Google dla intitle:RouterOS router configuration page - realne panele konfiguracyjne routerów MikroTik"/></p>
<p>Dork <code>intitle:"RouterOS router configuration page"</code> zwraca realne, wystawione panele routerów MikroTik. Snippety mówią same za siebie: „You have connected to a router. Administrative access only" oraz „Login: Password: WebFig". Adresy i nazwy właścicieli zamaskowaliśmy.</p>
<h2>
<a name="pliki-konfiguracyjne-i-sekrety-env" href="#pliki-konfiguracyjne-i-sekrety-env" class="anchor">
</a>
Pliki konfiguracyjne i sekrety (.env)
</h2>
<p>To kategoria, w której Google Hacking robi się naprawdę groźny. Pliki <code>.env</code> przechowują zmienne środowiskowe aplikacji: dane dostępowe do bazy, klucze API, sekrety podpisujące sesje. Gdy taki plik wyląduje w publicznym katalogu albo zostanie przez nieuwagę wgrany do repozytorium, wyszukiwarka indeksuje jego treść w całości.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>filetype:env intext:"DB_PASSWORD" # haslo do bazy w pliku .env
filetype:env "APP_KEY" # klucz aplikacji (Laravel itp.)
intext:"AKIA" filetype:env # klucze dostepowe AWS
filetype:pem intext:"PRIVATE KEY" # klucze prywatne SSH/TLS
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/jdvt2yrk7k9nsxteb333.png" alt="Wyniki Google dla filetype:env DB_PASSWORD - wystawione pliki konfiguracyjne, dane w podglądach zredagowane"/></p>
<p>Wystawione pliki <code>.env</code>. Na potrzeby artykułu nazwy repozytoriów i zawartość podglądów zostały zredagowane, ale układ nie kłamie: w środku siedzą loginy do bazy, klucze API i sekrety aplikacji. To jeden z najczęstszych źródeł realnych wycieków.</p>
<p><strong>Uwaga.</strong> Wyciek pojedynczego klucza API czy hasła do bazy potrafi otworzyć drogę do całej infrastruktury. Dlatego sekrety nigdy nie powinny trafiać do publicznych katalogów ani do repozytoriów kodu. Wracamy do tego w sekcji o obronie.</p>
<h2>
<a name="logi-systemowe" href="#logi-systemowe" class="anchor">
</a>
Logi systemowe
</h2>
<p>Pliki logów (<code>.log</code>) bywają zapisywane w publicznie dostępnych katalogach „na chwilę", podczas diagnozowania problemu, i zostają tam na lata. Problem w tym, że logi aplikacji potrafią zawierać tokeny sesji, adresy e-mail, a w gorszych przypadkach hasła przesyłane w żądaniach.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>filetype:log intext:"password" # logi zawierajace slowo 'password'
filetype:log inurl:access # logi dostepu serwera WWW
filetype:log "Authorization: Bearer" # logi z tokenami sesji
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/eu5z7ygrs6luuvz2xuiq.png" alt="Wyniki Google dla filetype:log password - wystawione logi systemowe z zredagowanymi danymi"/></p>
<p>Wystawione logi. Podglądy celowo zredagowaliśmy, bo w realnych wynikach pojawiają się tu loginy, tokeny i sesje. To dane, które nigdy nie powinny być publiczne, a mimo to regularnie lądują w indeksie.</p>
<h2>
<a name="bazy-danych-i-zrzuty-sql" href="#bazy-danych-i-zrzuty-sql" class="anchor">
</a>
Bazy danych i zrzuty SQL
</h2>
<p>Zrzut bazy danych (plik <code>.sql</code>) to najgorszy możliwy wyciek: zawiera całą strukturę i dane, łącznie z tabelą użytkowników. Deweloperzy tworzą takie zrzuty do migracji albo backupu i zostawiają je w katalogu projektu, skąd Google je indeksuje. Drugą furtką są wystawione panele <strong>phpMyAdmin</strong> (webowy klient bazy MySQL/MariaDB) działające bez ograniczenia dostępu.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>filetype:sql "INSERT INTO" "VALUES" "password" # zrzuty z danymi uzytkownikow
intitle:"phpMyAdmin" "Welcome to phpMyAdmin"
filetype:sql "CREATE TABLE" intext:"@gmail.com" # zrzuty z adresami e-mail
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/kw8ifyiw9b2y92e7g8sn.png" alt="Wyniki Google dla filetype:sql INSERT INTO password - wystawione zrzuty baz danych, zawartość zredagowana"/></p>
<p>Wystawione zrzuty SQL. Widoczny (zredagowany) wiersz <code>INSERT INTO `users` VALUES (...)</code> z polem hasła w formie skrótu bcrypt pokazuje, co dokładnie wycieka: kompletne konta użytkowników gotowe do złamania offline.</p>
<p>A tak wygląda sam panel zarządzania bazą od środka. Poniższy zrzut pochodzi z <strong>oficjalnego, publicznego serwera demonstracyjnego phpMyAdmin</strong> (projekt udostępnia go każdemu do testów), więc mogliśmy bezpiecznie pokazać pełen interfejs: drzewo baz po lewej, zakładki zarządzania na górze i podgląd rekordów konkretnej tabeli. Dokładnie taki widok dostaje ktoś, kto trafi na panel phpMyAdmin wystawiony bez logowania, z tą różnicą, że tam w tabelach są prawdziwe dane. Nazwy obcych baz w drzewie zamaskowaliśmy.</p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/1hf1f98wl13903j3dhlk.png" alt="Panel phpMyAdmin (oficjalne demo) - drzewo baz danych, zakładki i podgląd rekordów tabeli"/></p>
<p>Panel phpMyAdmin na oficjalnym serwerze demonstracyjnym projektu (<code>demo.phpmyadmin.net</code>). Po lewej drzewo baz (obce nazwy zamaskowane), na górze zakładki zarządzania, w środku podgląd rekordów tabeli wraz z zapytaniem SQL. Tak od środka wygląda wystawiony menedżer bazy danych.</p>
<h2>
<a name="kamery-ip-klasyka-google-hacking" href="#kamery-ip-klasyka-google-hacking" class="anchor">
</a>
Kamery IP: klasyka Google Hacking
</h2>
<p>Kamery sieciowe to wizytówka Google Hacking, bo ich panele podglądu mają charakterystyczne, powtarzalne tytuły stron. Producenci tacy jak AXIS od lat używają tego samego szablonu „Live View", więc jeden dork odnajduje tysiące urządzeń naraz. Wiele z nich jest wystawionych do internetu bez żadnego uwierzytelnienia, bo ktoś chciał „tylko podejrzeć z domu".<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>intitle:"Live View / - AXIS" # strony startowe kamer AXIS
inurl:"view/view.shtml" # klasyczny panel podgladu
inurl:"/axis-cgi/jpg/image.cgi" # bezposredni strumien obrazu
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/g4vy8ucfja6kkhp7rofn.png" alt="Wyniki Google dla intitle:Live View AXIS - lista wystawionych kamer sieciowych, hosty zredagowane"/></p>
<p>Realne wyniki dla <code>intitle:"Live View / - AXIS"</code>. Tytuły zdradzają konkretne modele kamer (M1124, 205, P1365), a snippety to typowe strony „Live View" wbudowane w firmware kamer AXIS - te urządzenia często działają na własnym serwerze HTTP z domyślną parą haseł. Hosty i nazwy właścicieli zamaskowaliśmy.</p>
<p>Cudzych kamer nie otwieramy, ale żeby pokazać, jak taki panel wygląda od środka, postawiliśmy <strong>własną kamerę w środowisku testowym</strong> i zrobiliśmy zrzut jej interfejsu „Live View". W okno podglądu podstawiliśmy nieszkodliwą grafikę zamiast realnego nagrania, za to cała reszta to typowy panel kamery sieciowej: na żywo aktualizowany strumień, menu konfiguracji, sterowanie PTZ (obrót i zoom) oraz informacja o modelu i firmware. W realnych, wystawionych kamerach w tym oknie widać po prostu obraz z pomieszczenia, bez żadnego logowania.</p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/h1ddjyttsj55ohdwbidd.png" alt="Interfejs Live View kamery sieciowej - strumień na żywo, sterowanie PTZ i informacje o urządzeniu (środowisko testowe)"/></p>
<p>Panel „Live View" kamery sieciowej w naszym środowisku testowym. W oknie podglądu podstawiliśmy nieszkodliwą grafikę zamiast realnego nagrania; poza tym to typowy panel kamery: nagłówek ze znacznikiem czasu, menu konfiguracji, sterowanie PTZ i dane urządzenia. Tak wygląda interfejs, który przy wystawionej kamerze pokazuje obraz bez logowania.</p>
<p><strong>Granica jest tu wyjątkowo ostra.</strong> Lista wyników to dane publiczne, ale otwarcie panelu cudzej kamery i obejrzenie obrazu to już uzyskanie dostępu do informacji bez uprawnienia. W audycie bezpieczeństwa testuje się wyłącznie urządzenia, na które ma się pisemną zgodę właściciela.</p>
<h2>
<a name="kamery-przemysłowe-i-serwery-webcamxp" href="#kamery-przemysłowe-i-serwery-webcamxp" class="anchor">
</a>
Kamery przemysłowe i serwery webcamXP
</h2>
<p>Obok kamer AXIS jest cała kategoria oprogramowania do obsługi kamer na komputerach z Windows, np. <strong>webcamXP</strong>. Te serwery wystawiają własny interfejs webowy, często na nietypowych portach (8080, 8090), i równie często bez logowania. Tu Google Hacking warto uzupełnić o <strong><a href="https://www.shodan.io/">Shodan</a></strong>, czyli wyszukiwarkę urządzeń podłączonych do internetu (tzw. internetu rzeczy), która zamiast treści stron indeksuje banery usług i otwarte porty.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>intitle:"webcamXP" inurl:8080 # serwery webcamXP w Google
# Shodan: webcamxp # te same urzadzenia po stronie banerow uslug
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/mscaqyblx25pbffkjx5w.png" alt="Wyniki Google dla intitle:webcamXP inurl:8080 - serwery kamer webcamXP, hosty zredagowane"/></p>
<p>Serwery webcamXP w wynikach Google. Sam fakt, że panel webowy tego oprogramowania trafił do indeksu, pokazuje, że jest wystawiony do internetu; napis „Not logged in" to tylko domyślny status gościa (nie dowód, że sam podgląd kamery jest otwarty - to zależy od konfiguracji serwera). Tytuły to nazwa oprogramowania, więc nie identyfikują ofiary, ale hosty i tak zamaskowaliśmy.</p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/u0l2tqyyi2fzjno0y5g5.png" alt="Shodan - 89 wystawionych serwerów webcamXP z mapą krajów, adresy IP zredagowane"/></p>
<p>To samo zjawisko w Shodan: blisko 90 wystawionych serwerów webcamXP z rozbiciem na kraje, porty i organizacje sieciowe. Shodan pokazuje banery usług (nagłówek <code>Server: webcamXP</code>), a my zamaskowaliśmy adresy IP i podglądy.</p>
<h2>
<a name="drukarki-sieciowe" href="#drukarki-sieciowe" class="anchor">
</a>
Drukarki sieciowe
</h2>
<p>Drukarka brzmi niegroźnie, ale jej panel webowy to pełnoprawne urządzenie w sieci: zdradza model, status, nazwy wydruków, a często ma domyślne hasło administratora. W 2013 roku głośno było o tym, że Google zindeksowało dziesiątki tysięcy publicznych drukarek HP. Problem nie zniknął, ale żywe panele najłatwiej zobaczyć dziś w Shodan, po porcie <code>9100</code> (protokół druku) i nagłówkach serwerów drukarek. Sam dork drukarkowy w Google zwraca w większości artykuły o zjawisku, a nie panele, o czym piszemy w następnej sekcji.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>inurl:hp/device/this.LCDispatcher # panel webowy drukarek HP
intitle:"HP LaserJet" inurl:SSI # strony statusu HP LaserJet
# Shodan: hp laserjet # banery drukarek; port 9100 = druk
</code></pre></div>
<p></p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/5iaj9lgai8uerqc1gkz3.png" alt="Shodan - blisko 6 tysięcy wystawionych drukarek HP LaserJet, port 9100, adresy IP zredagowane"/></p>
<p>Shodan dla zapytania „hp laserjet": blisko 6 tysięcy urządzeń, z dominującym portem <code>9100</code>. W banerach widać status PJL urządzenia (<code>DISPLAY="Ready"</code>, <code>ONLINE=TRUE</code>) oraz model. Adresy IP zamaskowaliśmy.</p>
<h2>
<a name="dlaczego-popularne-dorki-zwracają-artykuły-a-nie-wycieki-i-urządzenia" href="#dlaczego-popularne-dorki-zwracają-artykuły-a-nie-wycieki-i-urządzenia" class="anchor">
</a>
Dlaczego popularne dorki zwracają artykuły, a nie wycieki i urządzenia
</h2>
<p>Efekt ten dotyka najsłynniejszych dorków niezależnie od tego, czy celują w urządzenia, czy w wycieki. Jeśli wpiszesz najbardziej znane, „memiczne" zapytania - nie tylko kamerowe czy drukarkowe, ale też klasyki na pliki <code>.env</code> i zrzuty baz - często zobaczysz to samo, co my podczas przygotowywania tego artykułu: zamiast paneli urządzeń i realnych wycieków wyskoczą poradniki, wątki na forach, filmy i wpisy w bazach dorków. To nie błąd, tylko skutek popularności. Te zapytania od lat krążą w setkach tutoriali, więc Google ma dla nich mnóstwo „autorytatywnych" stron treściowych i to je promuje na górze. Realnych trafień jest przy tym garstka, mają niski autorytet w wyszukiwarce, a stare zasoby znikają z sieci. Efekt: słynny dork pokazuje artykuły o samym sobie.</p>
<p>Najlepszy przykład to klasyczny dork na panele drukarek HP. W teorii ma odsłaniać urządzenia, w praktyce zwraca głośny artykuł „Google indexes more than 86000 HP printers", wpis w GHDB i posty na forach.</p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/dup00g6anmilurhaqhjh.png" alt="Wyniki Google dla dorka drukarek HP - głównie artykuły o zjawisku, wpis GHDB i posty na forach, a nie panele"/></p>
<p>Realny efekt słynnego dorka na drukarki HP: zamiast paneli urządzeń wyszukiwarka zwraca artykuł „Google indexes more than 86000 HP printers", wpis z GHDB i posty na forach. Tak kończy się większość najpopularniejszych zapytań.</p>
<p>Lista dorków, które dziś najczęściej kończą się właśnie tak (warto je znać, ale nie licz na panele):<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>inurl:"ViewerFrame?Mode=" # slynny dork na kamery Panasonic
inurl:"view/view.shtml" # ogolny panel podgladu kamer
intitle:"webcamXP" inurl:8080 # serwery webcamXP
inurl:hp/device/this.LCDispatcher # panele drukarek HP
intitle:"Live View / - AXIS" # kamery AXIS, czesto juz przykryte artykulami
</code></pre></div>
<p></p>
<p>Jak to omijać, gdy naprawdę zależy Ci na urządzeniach:</p>
<ul>
<li><strong>Wykluczaj strony treściowe</strong> operatorem minus. Dopisz na koniec zapytania <code>-site:exploit-db.com -site:github.com -site:reddit.com -inurl:github</code>, żeby wypchnąć poradniki i bazy dorków.</li>
<li><strong>Celuj w napis interfejsu konkretnego producenta</strong>, a nie w „memiczną" frazę. Tytuł panelu MikroTik (<code>intitle:"RouterOS router configuration page"</code>) wciąż zwraca żywe urządzenia, bo rzadko jest cytowany w artykułach. To właśnie ten dork dał zrzut z sekcji o panelach administracyjnych.</li>
<li><strong>Przesiądź się na Shodan</strong>, gdy zależy Ci na samych urządzeniach. Shodan indeksuje banery usług i otwarte porty, więc pokazuje sprzęt bezpośrednio, bez warstwy treści SEO. To dlatego drukarki i kamery najlepiej widać właśnie tam.</li>
</ul>
<h2>
<a name="google-hacking-database-ghdb" href="#google-hacking-database-ghdb" class="anchor">
</a>
Google Hacking Database (GHDB)
</h2>
<p>Nie musisz wymyślać dorków od zera. <strong><a href="https://www.exploit-db.com/google-hacking-database">Google Hacking Database (GHDB)</a></strong>, prowadzona przez <a href="https://www.exploit-db.com/">Exploit-DB</a>, to katalog tysięcy gotowych zapytań posegregowanych według rodzaju ekspozycji: pliki z hasłami, wrażliwe katalogi, wykrywanie wersji serwerów, urządzenia online. Każdy wpis ma dork, opis i kategorię.</p>
<p><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/cirdzw7vyk8awzhsf8o8.png" alt="Google Hacking Database na Exploit-DB - tabela dorków z kategoriami i autorami"/></p>
<p>Google Hacking Database na Exploit-DB. Kategorie takie jak „Files Containing Passwords" czy „Vulnerable Servers" pozwalają od razu sięgnąć po sprawdzone zapytania zamiast budować je ręcznie.</p>
<h2>
<a name="automatyzacja-dorków-pagodo-i-sitedorks" href="#automatyzacja-dorków-pagodo-i-sitedorks" class="anchor">
</a>
Automatyzacja dorków: pagodo i sitedorks
</h2>
<p>Gdy od kilku ręcznych zapytań przechodzisz do audytu całej domeny, sięgasz po automaty. Dwa narzędzia zdominowały ten temat i oba są darmowe oraz otwartoźródłowe: <strong>pagodo</strong> systematycznie przepuszcza przez jedną domenę całą listę GHDB, a <strong>sitedorks</strong> sprawdza, gdzie dany podmiot pojawia się na setkach platform. To dwa różne zadania, więc warto znać oba.</p>
<h3>
<a name="pagodo-cała-baza-ghdb-na-jednej-domenie" href="#pagodo-cała-baza-ghdb-na-jednej-domenie" class="anchor">
</a>
pagodo - cała baza GHDB na jednej domenie
</h3>
<p><a href="https://github.com/opsdisk/pagodo">pagodo</a> (projekt opsdisk, Python 3.6+) to para skryptów. Najpierw <code>ghdb_scraper.py</code> pobiera aktualną listę dorków z <a href="https://www.exploit-db.com/google-hacking-database">GHDB</a> i zapisuje je do katalogu <code>dorks/</code> (cała lista, JSON oraz osobne pliki na każdą kategorię). Potem <code>pagodo.py</code> uruchamia te dorki dla wskazanej domeny przez bibliotekę <code>yagooglesearch</code>, z wbudowanymi mechanizmami zmniejszającymi ryzyko blokady: losowymi opóźnieniami, rotacją proxy i losowaniem nagłówka User-Agent.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code># instalacja
git clone https://github.com/opsdisk/pagodo
cd pagodo && python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# 1) pobierz aktualne dorki z GHDB (all_google_dorks.txt + JSON + pliki kategorii)
python3 ghdb_scraper.py -s -j -i
# 2) odpal je na SWOJEJ domenie, z losowym opoznieniem 37-60 s
python3 pagodo.py -g dorks/all_google_dorks.txt -d przyklad.pl -m 25 -i 37 -x 60 -s
</code></pre></div>
<p></p>
<p>Najważniejsze flagi <code>pagodo.py</code>:</p>
<ul>
<li><code>-g</code> - plik z dorkami (wymagany), np. wygenerowany przez <code>ghdb_scraper.py</code></li>
<li><code>-d</code> - domena celu; zawęża każdy dork operatorem <code>site:</code></li>
<li><code>-m</code> - maksymalna liczba wyników na pojedynczy dork (domyślnie 100)</li>
<li><code>-i</code> oraz <code>-x</code> - minimalne i maksymalne losowe opóźnienie w sekundach między zapytaniami (domyślnie 37 i 60)</li>
<li><code>-p</code> - lista proxy używanych rotacyjnie (round-robin)</li>
<li><code>-o</code> / <code>-s</code> - zapis wyników do pliku JSON / tekstowego (z automatycznym znacznikiem czasu, jeśli nie podasz nazwy)</li>
</ul>
<p>Na wyjściu dostajesz raport (JSON i/lub TXT) z adresami URL pogrupowanymi według dorka, który je znalazł. Dla skryptu pobierającego dorki, <code>ghdb_scraper.py</code>, kluczowe są trzy flagi: <code>-s</code> zapisuje wszystkie dorki do <code>all_google_dorks.txt</code>, <code>-j</code> pełną odpowiedź JSON, a <code>-i</code> rozbija dorki na osobne pliki według kategorii.</p>
<h3>
<a name="sitedorks-gdzie-cel-pojawia-się-na-setkach-platform" href="#sitedorks-gdzie-cel-pojawia-się-na-setkach-platform" class="anchor">
</a>
sitedorks - gdzie cel pojawia się na setkach platform
</h3>
<p><a href="https://github.com/Zarcolio/sitedorks">sitedorks</a> podchodzi do tematu zupełnie inaczej. Bierze jedną frazę (np. nazwę firmy, nick, adres e-mail lub domenę) i buduje zapytania <code>site:</code> dla każdej z <strong>ponad 600 platform</strong> z wbudowanej listy (15 kategorii: serwisy społecznościowe, komunikatory, repozytoria kodu, pastebiny, fora i inne). Jednym poleceniem sprawdzasz więc, gdzie dany podmiot zostawił ślad w sieci. Wyniki domyślnie otwiera w kartach przeglądarki, a z flagą <code>-echo</code> po prostu wypisuje gotowe adresy zapytań na ekran.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code># instalacja (dziala na domyslnym Kali / Python 3)
git clone https://github.com/Zarcolio/sitedorks
cd sitedorks && bash install.sh
# sprawdz, gdzie fraza pojawia sie na ponad 600 platformach (domyslnie Google)
python3 sitedorks.py -query "przyklad.pl"
# tylko serwisy spolecznosciowe; wypisz adresy zamiast otwierac w przegladarce
python3 sitedorks.py -cat social -query "Jan Kowalski" -echo
</code></pre></div>
<p></p>
<p>Najważniejsze flagi <code>sitedorks</code>:</p>
<ul>
<li><code>-query</code> - szukana fraza (wymagana)</li>
<li><code>-engine</code> - wyszukiwarka: <code>google</code> (domyślna), <code>bing</code>, <code>duckduckgo</code>, <code>yandex</code>, <code>baidu</code>, <code>yahoo</code></li>
<li><code>-cat</code> - ogranicz do wybranych kategorii platform (np. <code>social</code>, <code>comm</code>)</li>
<li><code>-site on|off|inurl</code> - steruje operatorem <code>site:</code> lub zamienia go na <code>inurl:</code> (dla Google i DuckDuckGo)</li>
<li><code>-count</code> - ile platform mieści się w jednym zapytaniu (obejście limitu długości zapytania)</li>
<li><code>-wait</code> - odstęp między otwieraniem kart, żeby ograniczyć CAPTCHA</li>
<li><code>-echo</code> - wypisz adresy zapytań zamiast otwierać je w przeglądarce</li>
</ul>
<h3>
<a name="które-wybrać-i-jak-nie-oberwać-blokadą" href="#które-wybrać-i-jak-nie-oberwać-blokadą" class="anchor">
</a>
Które wybrać i jak nie oberwać blokadą
</h3>
<p>Sięgnij po <strong>pagodo</strong>, gdy chcesz systematycznie i okresowo przeskanować <em>własną domenę</em> pełną listą GHDB i dostać raport z trafień. Wybierz <strong>sitedorks</strong>, gdy szukasz, gdzie konkretny podmiot (firma, osoba, nick) figuruje na wielu platformach naraz, czyli przy klasycznym rozpoznaniu OSINT. W obu wypadkach obowiązuje ta sama zasada: masowe, szybkie zapytania błyskawicznie wywołują <strong>CAPTCHA</strong> (test odróżniający człowieka od bota) i czasową blokadę IP, a automatyczne odpytywanie strony wyników łamie regulamin Google. Dlatego działaj z opóźnieniami i wyłącznie na zasobach, na które masz zgodę. Skalowo i bez ryzyka blokady zrobisz to przez oficjalne API: <a href="https://developers.google.com/custom-search/v1/overview">Google Programmable Search (Custom Search JSON API)</a> albo komercyjne <a href="https://serpapi.com/">SerpAPI</a>, bo pytasz wtedy interfejs przeznaczony do maszynowego odpytywania, a nie stronę wyników.</p>
<h2>
<a name="granica-prawna-gdzie-kończy-się-legalny-rekonesans" href="#granica-prawna-gdzie-kończy-się-legalny-rekonesans" class="anchor">
</a>
Granica prawna: gdzie kończy się legalny rekonesans
</h2>
<p>To najważniejsza sekcja tego artykułu. Budowanie zapytań i przeglądanie wyników Google jest legalne, bo korzystasz z publicznego indeksu wyszukiwarki. Przekroczenie granicy następuje w momencie, w którym <strong>łączysz się z cudzym systemem bez zgody jego właściciela</strong>.</p>
<p><strong>Art. 267 Kodeksu karnego (Polska).</strong> Kto bez uprawnienia uzyskuje dostęp do informacji dla niego nieprzeznaczonej, m.in. przełamując albo omijając zabezpieczenie lub uzyskując dostęp do całości lub części systemu informatycznego, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2.</p>
<p>W praktyce oznacza to, że otwarcie cudzej kamery, panelu czy bazy „bez hasła" nie jest usprawiedliwieniem. Brak zabezpieczenia nie czyni dostępu legalnym. Testować wolno wyłącznie zasoby własne lub takie, na które masz pisemną zgodę (zlecenie, umowa o testy penetracyjne, program bug bounty z określonym zakresem).</p>
<h2>
<a name="jak-się-bronić-zamknij-to-u-siebie" href="#jak-się-bronić-zamknij-to-u-siebie" class="anchor">
</a>
Jak się bronić: zamknij to u siebie
</h2>
<p>Dobra wiadomość jest taka, że obrona przed Google Hacking jest w dużej mierze higieną konfiguracji. Oto co realnie działa.</p>
<h3>
<a name="1-wyłącz-wyświetlanie-katalogów-i-wymuś-uwierzytelnianie" href="#1-wyłącz-wyświetlanie-katalogów-i-wymuś-uwierzytelnianie" class="anchor">
</a>
1. Wyłącz wyświetlanie katalogów i wymuś uwierzytelnianie
</h3>
<p>Na serwerze WWW wyłącz directory listing (w Apache: <code>Options -Indexes</code>) i postaw uwierzytelnianie przed każdym panelem administracyjnym. Panele zarządzania nie powinny być w ogóle dostępne z publicznego internetu, a jedynie z sieci wewnętrznej lub przez <strong>VPN</strong> (szyfrowany tunel do sieci firmowej).</p>
<h3>
<a name="2-trzymaj-sekrety-poza-katalogiem-publicznym-i-poza-repozytorium" href="#2-trzymaj-sekrety-poza-katalogiem-publicznym-i-poza-repozytorium" class="anchor">
</a>
2. Trzymaj sekrety poza katalogiem publicznym i poza repozytorium
</h3>
<p>Pliki <code>.env</code>, klucze i konfiguracje muszą leżeć poza katalogiem dostępnym z sieci. Do repozytorium dodaj wpis w <code>.gitignore</code>, a w organizacji włącz <strong>skanowanie sekretów</strong> (secret scanning), które wychwytuje przypadkowo zacommitowane klucze. Jeśli sekret raz wyciekł, trzeba go unieważnić i wygenerować nowy, bo usunięcie pliku nie cofa wycieku.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code># .gitignore - nie wpuszczaj sekretow do repozytorium
.env
*.sql
*.log
*.pem
</code></pre></div>
<p></p>
<h3>
<a name="3-robotstxt-nie-chroni-tylko-prosi" href="#3-robotstxt-nie-chroni-tylko-prosi" class="anchor">
</a>
3. robots.txt nie chroni, tylko prosi
</h3>
<p>Częsty błąd: wpisanie wrażliwego katalogu do <code>robots.txt</code> w przekonaniu, że to go ukryje. Przeciwnie. <code>robots.txt</code> to tylko prośba do robotów o nieindeksowanie, której treść jest publiczna i sama wskazuje atakującemu, gdzie szukać. Ochroną jest usunięcie lub zabezpieczenie zasobu, a nie wpis w pliku.</p>
<h3>
<a name="4-usuń-to-co-już-wyciekło" href="#4-usuń-to-co-już-wyciekło" class="anchor">
</a>
4. Usuń to, co już wyciekło
</h3>
<p>Jeśli wrażliwa strona jest już w indeksie: najpierw zabezpiecz albo usuń sam zasób, potem dodaj nagłówek lub metatag <code>noindex</code> i skorzystaj z narzędzia <strong>Usuwanie adresów URL</strong> w Google Search Console. Kolejność jest istotna, bo samo <code>noindex</code> bez zabezpieczenia zasobu zostawia treść dostępną pod bezpośrednim adresem.</p>
<h3>
<a name="5-zmień-domyślne-hasła-i-odetnij-urządzenia-iot" href="#5-zmień-domyślne-hasła-i-odetnij-urządzenia-iot" class="anchor">
</a>
5. Zmień domyślne hasła i odetnij urządzenia IoT
</h3>
<p>Kamery, drukarki i inne urządzenia internetu rzeczy konfiguruj z nowym, silnym hasłem i nie wystawiaj ich bezpośrednio do internetu. Jeśli zdalny dostęp jest konieczny, prowadź go przez VPN, a nie przez przekierowanie portu na publiczny adres.</p>
<h3>
<a name="6-audytuj-się-sam-regularnie" href="#6-audytuj-się-sam-regularnie" class="anchor">
</a>
6. Audytuj się sam, regularnie
</h3>
<p>Najlepsza obrona to spojrzenie na siebie oczami atakującego. Uruchamiaj dorki ograniczone do własnej domeny operatorem <code>site:</code>, przeglądaj swoje adresy w Shodan i ustaw monitoring, który zaalarmuje, gdy w sieci pojawi się nowa, niezamierzona usługa. To audyt własnego zasobu, więc jest w pełni legalny i powinien wejść do stałego rytmu pracy zespołu.<br>
</p>
<div class="highlight"><pre class="highlight plaintext"><code>site:twojafirma.pl filetype:env
site:twojafirma.pl intitle:"index of"
site:twojafirma.pl inurl:admin
site:twojafirma.pl filetype:sql OR filetype:bak OR filetype:log
</code></pre></div>
<p></p>
<h2>
<a name="podsumowanie" href="#podsumowanie" class="anchor">
</a>
Podsumowanie
</h2>
<p>Google Hacking nie jest magią ani exploitem. To umiejętność precyzyjnego pytania, połączona ze świadomością, jak wiele danych organizacje zostawiają w zasięgu zwykłej wyszukiwarki. Dla analityka OSINT i pentestera to pierwszy, najtańszy krok rekonesansu. Dla administratora to lista kontrolna rzeczy, które trzeba zamknąć, zanim zrobi to ktoś inny. Granica między jednym a drugim jest prosta: legalnie analizujesz dane publiczne i własne zasoby, ale nie wchodzisz do cudzych systemów bez zgody.</p>
<p><a href="https://jsystems.pl/szkolenia-cyberbezpieczenstwo;osint.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post427&utm_content=banner_google-hacking-google-dorks-kamery-panele-sekrety"><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/rhdoi75nnh6p500ioyly.jpg" alt="Szkolenie OSINT - wywiad ze źródeł otwartych, JSystems"/></a></p>
<p><a href="https://jsystems.pl/szkolenia-cyberbezpieczenstwo;osint.szczegoly?utm_source=blog&utm_medium=article&utm_campaign=post427&utm_content=link_google-hacking-google-dorks-kamery-panele-sekrety">Szkolenie OSINT - wywiad ze źródeł otwartych</a></p>
<p>To szkolenie może być <a href="https://jsystems.pl/dofinansowanie?utm_source=blog&utm_medium=article&utm_campaign=post427&utm_content=dofinansowanie">dofinansowane dla Ciebie z KFS lub BUR</a>.</p>
<p>★★★★★Średnia ocena naszych szkoleń w Google: <strong>5/5</strong></p>
<p>Cyberbezpieczeństwo i OSINT<br>
JSystems © 2026</p>
|
Top comments (0)