Video: Slik sikrer du barn fra 4 år riktig i bilen 2024
Du kan tenke at hvis du kan kontrollere hvem som ser, lager, endrer og sletter data i et SQL-tabell, vær godt beskyttet. Mot mest trusler, er du. En kunnskapsrik hacker kan imidlertid fortsatt ransacke huset ved hjelp av en indirekte metode.
En korrekt utformet relasjonsdatabase har referensintegritet, , som betyr at dataene i en tabell i databasen er i overensstemmelse med dataene i alle de andre tabellene. For å sikre referanseintegritet, bruker databasedesignere begrensninger til tabeller som begrenser databrukerne kan komme inn i tabellene.
Men her er ulempen med denne beskyttelsen: Hvis du har en database med referanseintegritetsbegrensninger, kan en bruker muligens opprette et nytt bord som bruker en kolonne i et konfidensielt bord som en utenlandsk nøkkel. Den kolonnen tjener da som en lenke gjennom hvilken noen muligens kan stjele konfidensiell informasjon. Oops.
Si for eksempel at du er en berømt Wall Street aksjeanalytiker. Mange tror på nøyaktigheten av aksjeplukkene dine, så når du anbefaler en aksje til abonnentene dine, kjøper mange folk den aksjen, og verdien øker.
Du beholder analysen din i en database, som inneholder et bord som heter FOUR_STAR. Dine beste anbefalinger for ditt neste nyhetsbrev er i den tabellen. Selvfølgelig begrenser du tilgangen til FOUR_STAR slik at ordet ikke lekker ut til investerende publikum før dine betalende abonnenter mottar nyhetsbrevet.
Du er imidlertid fortsatt sårbar, hvis noen andre kan lage et nytt bord som bruker feltnavnetfeltet FOUR_STAR som en fremmednøkkel, som vist i følgende kommandop eksempel:
CREATE TABLE HOT_STOCKS (Lagerkarakter (30) REFERANSER FOUR_STAR);
Hackeren kan nå prøve å sette inn navnet på hver aksje på New York Stock Exchange, American Stock Exchange og NASDAQ i tabellen. De innleggene som lykkes, forteller hackeren hvilke aksjer som samsvarer med aksjene du heter i ditt konfidensielle bord. Det tar ikke lang tid for hackeren å trekke ut hele listen over aksjer.
Du kan beskytte deg mot hack som i det foregående eksempel ved å være veldig forsiktig med å skrive inn setninger som ligner på følgende:
GRANT REFERENCES (Stock) PÅ FOUR_STAR TO SECRET_HACKER;
Dette er tydeligvis en overdrivelse. Du ville aldri gi noen form for tilgang til et kritisk bord til en uvurderlig person, ville du? Ikke hvis du skjønte hva du gjorde.Imidlertid er hackere i dag ikke bare smart teknisk. De er også mestre av villedende folk til å gjøre det de vanligvis ikke ville gjøre. Ramp opp til full varsel når en jevn talker nevner alt relatert til din konfidensielle informasjon.
Unngå å gi privilegier til personer som kan misbruke dem. Sant kommer folk ikke med garantier trykt på pannen. Men hvis du ikke ville låne din nye bil til en person for en lang tur, bør du sannsynligvis ikke gi ham REFERENCES-privilegiet på et viktig bord heller.
Det foregående eksemplet gir en god grunn til å opprettholde forsiktig kontroll av REFERENCES-privilegiet. Her er to andre grunner til at du bør opprettholde forsiktig kontroll over REFERENCER:
-
Hvis den andre personen angir en begrensning i HOT STOCKS ved å bruke et RESTRICT-alternativ, og du prøver å slette en rad fra bordet, forteller DBMS at du kan 't, fordi det ville være i strid med en referensiell integritetsbegrensning.
-
Hvis du vil bruke DROP-kommandoen til å ødelegge bordet, finner du at du må få den andre personen til å DROP sin begrensning (eller hans bord) først.
Bunnlinjen: Å aktivere en annen person til å angi integritetsbegrensninger på bordet, introduserer ikke bare et potensielt sikkerhetsbrudd, men betyr også at den andre brukeren noen ganger kommer i veien.
