Som en internationell standard för databasfrågesatser har SQL-satser använts i stor utsträckning i olika programmeringsmiljöer. Som ett moget och stabilt system är användarinloggning och lösenordsverifiering avgörande. I mitt dagliga programmeringsarbete upptäckte jag att många programmerare använder SQL-satser för att verifiera användarlösenord genom ett uttalande som detta:
sql="Välj * från användartabellen där name='"+name+"' och password='"+password+"'"
Namnet och lösenordet är användarnamn och lösenord som användaren anger i, och ovanstående uttalanden utförs för att verifiera om användaren och lösenordet är legitima och giltiga. Men genom analys kan man upptäcka att det finns ödesdigra kryphål i ovanstående påståenden. När vi anger följande sträng i användarnamnet: 111'or'1=1, och sedan anger lösenordet nonchalant, sätter vi det till aaaa. Efter att variabeln bytts ut blir SQL-satsen följande sträng:
sql="Välj * från användartabellen där name='111'or'1=1' och password='AAAAA'
Vi vet alla att när select-satsen bedömer frågevillkoren, kommer den att ignorera följande och (och)-operationer när den möter eller (eller)-operationer, och värdet 1=1 i ovanstående sats är alltid sant, vilket betyder att oavsett vilket värde som anges i lösenordet kan det klara ovanstående lösenordsverifiering! Lösningen på detta problem är mycket enkel, och det finns många metoder, den vanligaste är att bedöma användarens och lösenordets legitimitet innan verifieringen utförs, och specialtecken som enkla citattecken och likhetstecken är inte tillåtna.
Ovanstående problem, även om de kan verka enkla, existerar. Till exempel hade den tidiga versionen av det berömda onlinespelet "Smiling Proud Jianghu" på internet ett sådant problem, och författaren analyserade också noggrant några av de program han skrivit tidigare efter att ha läst sårbarhetsrapporten om detta spel, och det fanns många sådana kryphål. Det här borde verkligen vara vår uppmärksamhet. Detta avslöjar också bristen på programmeringserfarenhet och säkerhetsmedvetenhet hos unga programmerare, inklusive författaren. Samtidigt påminner det oss också om att programmerare bör ta hänsyn till programmets säkerhet när de utformar det, och inte vara slarviga, och att en till synes liten utelämnande kan orsaka allvarliga konsekvenser.
|
Publicerad på 2014-11-26 15:47:51
|
|
|
