Som en international standard for databaseforespørgselssætninger er SQL-sætninger blevet bredt anvendt i forskellige programmeringsmiljøer. Som et modent og stabilt system er brugerlogin og adgangskodeverifikation afgørende. I mit daglige programmeringsarbejde har jeg fundet ud af, at mange programmører bruger SQL-sætninger til at verificere brugeradgangskoder gennem en sætning som denne:
sql="Vælg * fra brugertabellen, hvor name='"+name+"' og password='"+password+"'"
Navn og adgangskode er brugernavne og adgangskoder, som brugeren indtaster, og ovenstående udsagn udføres for at verificere, om brugeren og adgangskoden er legitime og gyldige. Dog kan man gennem analyse finde ud af, at der er fatale smuthuller i ovenstående udsagn. Når vi indtaster følgende streng i brugernavnet: 111'or'1=1, og derefter indtaster adgangskoden tilfældigt, sætter vi den til aaaa. Efter at variablen er udskiftet, bliver SQL-sætningen til følgende streng:
sql="Vælg * fra brugertabellen, hvor name='111'or'1=1' og password='aaaa'
Vi ved alle, at når select-sætningen vurderer forespørgselsbetingelserne, vil den ignorere følgende og (og)-operationer, når den møder eller (eller)-operationer, og værdien 1=1 i ovenstående sætning er altid sand, hvilket betyder, at uanset hvilken værdi der indtastes i adgangskoden, kan den bestå ovenstående adgangskodeverifikation! Løsningen på dette problem er meget enkel, og der findes mange metoder; den mest almindeligt anvendte er at vurdere brugerens legitimitet og adgangskoden, som brugeren indtaster, før verifikation udføres, og specialtegn som enkeltstående anførselstegn og lighedstegn er ikke tilladt.
De ovenstående problemer, selvom de kan virke simple, eksisterer. For eksempel havde den tidlige version af det berømte onlinespil "Smiling Proud Jianghu" på internettet et sådant problem, og forfatteren analyserede også omhyggeligt nogle af de programmer, han tidligere havde skrevet efter at have læst sårbarhedsrapporten om dette spil, og der var mange sådanne smuthuller. Det burde virkelig være vores opmærksomhed. Dette afslører også manglende programmeringserfaring og sikkerhedsbevidsthed hos unge programmører, inklusive forfatteren. Samtidig minder det os også om, at programmører bør tage programmets sikkerhed i betragtning, når de designer programmet, og ikke være sjuskete, og at en tilsyneladende lille udeladelse kan medføre alvorlige konsekvenser.
|