Hva er en MDB-database? Enhver nettverksadministrator med noe erfaring med nettsideproduksjon vet at kombinasjonen «IIS+ASP+ACCESS» er den mest populære måten å bygge et nettsted på, og de fleste små og mellomstore internettnettsteder bruker denne «pakken», men sikkerhetsproblemene som følger med dette blir stadig mer åpenbare. En av de mest sårbare for angripere er ulovlig nedlasting av MDB-databasen.
Så lenge inntrengeren gjetter eller skanner veien til mdb-databasen, kan du enkelt laste det ned til den lokale harddisken ved hjelp av et nedlastingsverktøy, og deretter kombinere det med brute force-knekkeverktøy eller noen superknekkeverktøy for enkelt å se innholdet i databasefilen, og bedriftens personvern og ansattes passord er ikke lenger trygt. Kan vi ikke styrke sikkerheten til MDB-databasen? Selv om vi bare har litt data, må vi bry oss med sqlserver ellerOrakelEr det det? Svaret er nei, i denne artikkelen vil forfatteren fortelle deg den unike hemmeligheten bak å lage en sikker MDB-databasefil.
1. Årsaker til krisen:
Generelt er utvidelsen av databasen med nettsideprogrammer og forum bygget på ASP mdb som standard, noe som er svært farlig. Du kan enkelt laste ned filen ved å gjette plasseringen av databasefilen og skrive inn URL-en i nettleserens adressefelt. Selv om vi legger til et passord i databasen og administratorens passord også er kryptert av MD5, er det lett å knekke etter å ha lastet det ned lokalt. Tross alt kan MD5 allerede knekkes av vold. Derfor, så lenge databasen er lastet ned, er den ikke sikker i det hele tatt.
2. Vanlig brukte behandlingsmetoder:
For øyeblikket finnes det flere vanlige metoder for å forhindre ulovlig nedlasting av databasefiler.
(1) Endre navnet på databasen og legg den i en dyp katalog. For eksempel gjør det å endre databasenavnet til Sj6gf5.mdb og plassere det i en flernivåkatalog det vanskelig for en angriper å bare gjette plasseringen av databasen. Ulempen med dette er selvfølgelig at hvis ASP-kodefilen lekker, er den ubrukelig uansett hvor dypt den er skjult.
(2) Endre utvidelsen av databasen til ASP eller ASA og andre navn som ikke påvirker dataspørringen. Men noen ganger kan det fortsatt lastes ned etter å ha endret det til ASP eller ASA, for eksempel, etter at vi har endret det til ASP, skriver vi direkte inn nettverksadressen i adresselinjen til IE, selv om det ikke finnes noen forespørsel om nedlasting, men et stort antall utydelige tegn vises i nettleseren. Hvis du bruker et profesjonelt nedlastingsverktøy som FlashGet eller Video Conveyor, kan du laste ned databasefilen direkte. Denne metoden har imidlertid en viss blindhet, tross alt kan ikke inntrengeren sikre at filen nødvendigvis er en fil med MDB-databasefilendringsendelse, men for de inntrengerne som har nok energi og tid, kan de laste ned alle filene og endre filendelsen til å gjette. Beskyttelsesnivået til denne metoden vil bli kraftig redusert.
3. Forfatterens sidedør:
Under forfatterens test støtte jeg på problemet med at ASP- og ASA-filer også vil bli lastet ned, så jeg fant følgende metode etter research.
Hvis du navngir databasefilen "#admin.asa" når du navngir databasen, kan du helt unngå å laste den ned med IE, men hvis vandalen gjetter databasens sti, kan du fortsatt laste den ned med FlashGet, og deretter omdøpe filen til "admin.mdb", da vil nettstedets hemmelighet bli eksponert. Så vi må finne en måte å få FlashGet til å ikke laste ned, men hvordan kan vi gjøre det unedlastbart? Sannsynligvis på grunn av tidligere Unicode-sårbarheter, vil ikke nettsteder behandle lenker som inneholder Unicode-kode. Så vi kan bruke unicode-koding (for eksempel kan vi bruke "%3C" i stedet for "<", osv.) for å nå målene våre. Men når FlashGet behandler lenker som inneholder unicode-kode, gjør den "smart" den tilsvarende behandlingen av unicode-koding, for eksempel automatisk å konvertere unicode-kodingsformen "%29" til (", så du sender inn en http://127.0.0.1/xweb/data/%29xadminsxx.mdb nedlastingslenke til FlashGet, men den tolker den som http: // 127.0.0.1/xweb/data/(xadminsxx.mdb, se hvor vi har URL-en ovenfor og det omdøpte stedet under, FlashGet tolker "%29xadminsxx.mdb" som "(xadminsxx.mdb", og når vi klikker på "OK"-knappen for å laste ned, går den til å lete etter en fil kalt "(xadminsxx.mdb". Det vil si, FlashGet introduserer oss for å gå på villspor, og selvfølgelig finner den den ikke, så prompten feiler.
Men hvis nedlastingen mislykkes, vil angriperen definitivt ønske å handleannenAngrepsmetode. Fra dette kan vi bruke en annen forebyggingsmetode, siden FlashGet går for å finne filen kalt "(xadminsxx.mdb", kan vi forberede en for den, vi lager en simulert database kalt "(xadminsxx.mdb", slik at når inntrengeren vil laste ned filen, laster den ned en database tilbake, men databasefilen er falsk eller tom, når de i hemmelighet jubler, Faktisk er den endelige seieren vår.
Sammendrag:
Gjennom denne introduksjonen av metoden for å beskytte MDB-databasefiler kan vi klargjøre to sikkerhetstiltak: det ene er den forvirrende metoden, det vil si å endre hva hackeren ønsker å få tak i, som å endre filnavn eller filendelse på MDB-filen; Den andre er den alternative metoden, det vil si å skjule det hackeren ønsker å få tak i og erstatte det med noe som ikke har noen praktisk betydning, slik at selv om hackeren lykkes med å invadere, får han falsk informasjon, og de vil tro at inntrengningen er vellykket og stoppe neste angrep.
|
|
Publisert på 26.11.2014 15:46:39
|
|
|
Publisert på 22.10.2017 14:15:09
|
