Mi az az MDB adatbázis? Bármely hálózati adminisztrátor, aki rendelkezik némi tapasztalattal weboldal-készítésben, tudja, hogy az "IIS+ASP+ACCESS" kombinációja a legnépszerűbb módja egy weboldal építésének, és a legtöbb kis- és középszintű internetes weboldal ezt a "csomagot" használja, de a vele járó biztonsági problémák egyre nyilvánvalóbbá válnak. Az egyik legsebezhetőbb a támadók számára az MDB adatbázis illegális letöltése.
Amíg a betolakodó kitalálja vagy átvizsgálja az mdb adatbázis útját, könnyen letöltheted a helyi merevlemezre egy letöltő eszközzel, majd kombinálhatod brute force cracking eszközökkel vagy valamilyen szuper feltörő eszközökkel, hogy könnyen megtekinthesd az adatbázis fájltartalmát, így a vállalat magánélete és a munkatársak jelszavai már nem biztonságosak. Nem tudnánk megerősíteni az MDB adatbázis biztonságát? Még ha csak kevés adatunk is van, gondot kell okoznunk a SQL Serverrel vagyjóslóTényleg? A válasz nem: ebben a cikkben a szerző elmondja neked a biztonságos MDB adatbázis fájl létrehozásának egyedi titkát.
1. A válság okai:
Általánosságban elmondható, hogy az ASP-re épült weboldal-programok és fórumok adatbázisának bővítése alapértelmezés szerint mdb, ami nagyon veszélyes. A fájlt könnyen letöltheted, ha kitalálod az adatbázis fájl helyét, és beírod az URL-jét a böngésző címsorába. Még ha hozzáadunk is egy jelszót az adatbázishoz, és az adminisztrátor jelszó is az MD5-tel titkosítva, könnyen feltörhető helyben letöltés után. Hiszen az MD5-öt már most is erőszakkal lehet feltörni. Ezért, amíg az adatbázis le van töltve, az egyáltalán nem biztonságos.
2. Leggyakrabban használt gyógymódi módszerek:
Jelenleg több általánosan alkalmazott módszer létezik az adatbázis-fájlok illegális letöltésének megakadályozására.
(1) Módosítsd az adatbázis nevét, és helyezd be egy mély könyvtárba. Például az adatbázis nevének megváltoztatása Sj6gf5.mdb-re és egy többszintű könyvtárba helyezése megnehezíti a támadó számára, hogy egyszerűen kitalálja az adatbázis helyét. Természetesen ennek hátránya, hogy ha az ASP kódfájl kiszivárog, akkor haszontalan, bármennyire is rejtve van.
(2) Megváltoztatja az adatbázis kiterjesztését ASP-re vagy ASA-ra, illetve más nevekre, amelyek nem befolyásolják az adatlekérdezést. De néha még mindig le lehet tölteni ASP-re vagy ASA-ra változtatás után, például miután ASP-re váltunk, közvetlenül beírjuk a hálózati címet az IE címsávjába, bár nincs letöltési prompt, de a böngészőben rengeteg zavaros karakter jelenik meg. Ha profi letöltőeszközt használsz, mint például a FlashGet vagy a Video Conveyor, közvetlenül letöltheted az adatbázis fájlt. Ennek a módszernek azonban van némi vaksága, hiszen a betolakodó nem tudja biztosítani, hogy a fájl feltétlenül MDB adatbázis-módosító kiterjesztéssel rendelkező fájl legyen, de azok a betolakodók, akiknek elég energiájuk és idejük van, letölthetik az összes fájlt, és megváltoztathatják a kiterjesztést találgatásra. Ennek a módszernek a védelme jelentősen csökkenni fog.
3. Az író oldali ajtaja:
A szerzői teszt során azzal a problémával találkoztam, hogy ASP és ASA fájlok is letöltődnek, ezért kutatás után a következő módszert találtam.
Ha az adatbázis fájlt "#admin.asa"-nak nevezed el az adatbázis fájl elnevezésekor, teljesen elkerülheted az IE-vel a letöltést, de ha a vandál kitalálja az adatbázis útvonalát, akkor is sikeresen letöltheted FlashGet-tel, majd átnevezheted a letöltött fájlt "admin.mdb"-re, így a weboldal titok feltárul. Szóval meg kell találnunk egy módot, hogy a FlashGet ne legyen letölthető, de hogyan tehetnénk leletölthethetetlenné tenni? Valószínűleg a korábbi unicode sebezhetőségek miatt a weboldalak nem dolgozzák fel azokat a linkeket, amelyek unicode kódot tartalmaznak. Tehát használhatjuk az unicode kódolást (például a "%3C" a "<" helyett stb.) a céljaink eléréséhez. Azonban amikor a FlashGet feldolgozza a unicode kódot tartalmazó linkeket, "ügyesen" végzi el az unicode kódolás megfelelő feldolgozását, például automatikusan átalakítja a "%29" unicode kódolási formáját (", így http://127.0.0.1/xweb/data/%29xadminsxx.mdb letöltési linket küldel be a FlashGet-nek, de az úgy értelmezi: http: // 127.0.0.1/xweb/data/(xadminsxx.mdb, nézd meg, hol van fent az URL, és az átnevezett hely lent, a FlashGet a "%29xadminsxx.mdb"-t "(xadminsxx.mdb"-ként értelmezi, és amikor a "OK" gombra kattintunk a letöltéshez, egy "(xadminsxx.mdb" nevű fájlt keres. Vagyis a FlashGet bevezet minket, hogy eltávolodjunk a tévedéshez, és persze nem találja meg, így a prompt nem sikerül.
Ha azonban a letöltés meghibásodik, a támadó mindenképpen lépéseket akar tennimástámadási módszer. Ebből egy másik megelőzési módszert alkalmazhatunk: mivel a FlashGet megtalálja a "(xadminsxx.mdb" nevű fájlt, előkészíthetünk egyet, létrehozunk egy szimulált adatbázist "(xadminsxx.mdb" néven, így amikor a betolakodó le akarja tölteni a fájlt, visszatölti az adatbázist, de az adatbázis hamis vagy üres, amikor titokban örülnek, Valójában a végső győzelem a miénk.
Összefoglaló:
Az MDB adatbázis-fájlok védelmére szolgáló módszer bevezetésével két biztonsági intézkedést tisztázhatunk: az egyik a zavaros módszer, vagyis megváltoztatják, amit a hacker meg akar szerezni, például a fájlnév vagy kiterjesztés megváltoztatása; A második az alternatív módszer, vagyis elrejtik, amit a hacker meg akar szerezni, és helyette valami gyakorlati jelentéssel helyettesítik, hogy még ha a hacker sikeresen betör, hamis információt kap, és azt hiszi, hogy a behatolás sikeres, és megállítja a következő támadást.
|
|
Közzétéve 2014. 11. 26. 15:46:39
|
|
|
Közzétéve 2017. 10. 22. 14:15:09
|
