Vad är en MDB-databas? Varje nätverksadministratör med viss erfarenhet av webbplatsproduktion vet att kombinationen "IIS+ASP+ACCESS" är det mest populära sättet att bygga en webbplats, och de flesta små och medelstora internetwebbplatser använder detta "paket", men säkerhetsproblemen som följer med det blir allt tydligare. En av de mest sårbara för angripare är den olagliga nedladdningen av MDB-databasen.
Så länge inkräktaren gissar eller skannar vägen till mdb-databasen kan du enkelt ladda ner den till den lokala hårddisken med ett nedladdningsverktyg och sedan kombinera den med brute force-knäckningsverktyg eller några superknäckningsverktyg för att enkelt se innehållet i databasfilen, och företagets integritet och anställdas lösenord är inte längre säkra. Kan vi inte stärka säkerheten i MDB-databasen? Även om vi bara har lite data måste vi bekymmera sqlserver ellerOrakelÄr det så? Svaret är nej, i den här artikeln kommer författaren att berätta den unika hemligheten för att skapa en säker MDB-databasfil.
1. Orsaker till krisen:
Generellt sett är utvidgningen av databasen med webbplatsprogram och forum byggda på ASP mdb som standard, vilket är mycket farligt. Du kan enkelt ladda ner filen genom att gissa var databasfilen finns och ange dess URL i webbläsarens adressfält. Även om vi lägger till ett lösenord i databasen och administratörens lösenord också är krypterat av MD5, är det lätt att knäcka efter att ha laddat ner det lokalt. MD5 kan ju redan brytas av våld. Därför är databasen inte alls säker så länge den laddas ner.
2. Vanligt använda behandlingsmetoder:
För närvarande finns det flera vanliga metoder för att förhindra olaglig nedladdning av databasfiler.
(1) Ändra databasens namn och placera den i en djup katalog. Till exempel gör det svårt för en angripare att bara gissa var databasen befinner sig i databasens namn till Sj6gf5.mdb och placera den i en flernivåkatalog. Naturligtvis är nackdelen att om ASP-kodfilen läcker ut är den värdelös oavsett hur djupt den är gömd.
(2) Ändra tillägget av databasen till ASP eller ASA och andra namn som inte påverkar datafrågan. Men ibland kan den fortfarande laddas ner efter att ha ändrat den till ASP eller ASA, till exempel, efter att vi ändrat till ASP, matar vi direkt in nätverksadressen i IE:s adressfält, även om det inte finns någon prompt för nedladdning, men ett stort antal osammanhängande tecken dyker upp i webbläsaren. Om du använder ett professionellt nedladdningsverktyg som FlashGet eller Video Conveyor kan du ladda ner databasfilen direkt. Denna metod har dock en viss blindhet, trots allt kan inkräktaren inte garantera att filen nödvändigtvis är en fil med MDB-filändelse, men för de inkräktare som har tillräckligt med energi och tid kan de ladda ner alla filer och ändra filändelsen för att gissa. Skyddsnivån för denna metod kommer att vara kraftigt reducerad.
3. Författarens sidodörr:
Under författarens test stötte jag på problemet att ASP- och ASA-filer också kommer att laddas ner, så jag hittade följande metod efter research.
Om du döper databasfilen till "#admin.asa" när du namnger databasfilen kan du helt undvika att ladda ner den med IE, men om vandalen gissar databasens väg kan du ändå ladda ner den framgångsrikt med FlashGet och sedan byta namn på den nedladdade filen till "admin.mdb", då kommer webbplatshemligheten att exponeras. Så vi måste hitta ett sätt att göra FlashGet så att det inte laddas ner, men hur kan vi göra det onedladdningsbart? Troligen på grund av tidigare Unicode-sårbarheter kommer webbplatser inte att bearbeta länkar som innehåller Unicode-kod. Så vi kan använda unicode-kodning (till exempel kan vi använda "%3C" istället för "<", etc.) för att nå våra mål. Men när FlashGet bearbetar länkar som innehåller unicode-kod, gör den "smart" motsvarande bearbetning av unicode-kodning, till exempel genom att automatiskt konvertera unicode-kodningsformen "%29" till (", så du skickar in en http://127.0.0.1/xweb/data/%29xadminsxx.mdb nedladdningslänk till FlashGet, men den tolkar den som http: // 127.0.0.1/xweb/data/(xadminsxx.mdb, titta på var vi har URL:en ovan och den omdöpta platsen nedan, FlashGet tolkar "%29xadminsxx.mdb" som "(xadminsxx.mdb", och när vi klickar på "OK"-knappen för att ladda ner letar den efter en fil som heter "(xadminsxx.mdb". Det vill säga, FlashGet introducerar oss för att gå vilse, och självklart kan den inte hitta den, så prompten misslyckas.
Men om nedladdningen misslyckas kommer angriparen definitivt vilja ageraannanAttackmetod. Utifrån detta kan vi använda en annan förebyggande metod, eftersom FlashGet går för att hitta filen som heter "(xadminsxx.mdb", kan vi förbereda en för den, vi skapar en simulerad databas som heter "(xadminsxx.mdb", så att när inkräktaren vill ladda ner filen så laddar den ner en databas igen, men databasfilen är falsk eller tom, när de i hemlighet jublar, Faktum är att den slutgiltiga segern är vår.
Sammanfattning:
Genom denna introduktion av metoden för att skydda MDB-databasfiler kan vi klargöra två säkerhetsåtgärder: den ena är den förvirrande metoden, det vill säga att ändra vad hackaren vill få, såsom att ändra filnamn eller filändelse på MDB-filen; Den andra är den alternativa metoden, det vill säga att dölja det hackaren vill få och ersätta det med något som saknar praktisk betydelse, så att även om hackaren lyckas invadera får han falsk information, och de tror att intrånget är framgångsrikt och stoppar nästa attack.
|
|
Publicerad på 2014-11-26 15:46:39
|
|
|
Publicerad på 2017-10-22 14:15:09
|
