Som en internasjonal standard for databasespørringssetninger har SQL-setninger blitt mye brukt i ulike programmeringsmiljøer. Som et modent og stabilt system er brukerinnlogging og passordverifisering essensielt. I mitt daglige programmeringsarbeid oppdaget jeg at mange programmerere bruker SQL-setninger for å verifisere brukerpassord gjennom en setning som denne:
sql="Velg * fra brukertabell hvor name='"+name+"' og password='"+password+"'"
Navnet og passordet er brukernavnene og passordene som brukeren har oppgitt, og de ovennevnte utsagnene utføres for å verifisere om brukeren og passordet er legitime og gyldige. Gjennom analyse kan man imidlertid finne at det finnes fatale smutthull i de ovennevnte utsagnene. Når vi skriver inn følgende streng i brukernavnet: 111'or'1=1, og deretter skriver inn passordet uformelt, setter vi det til aaaa. Etter at variabelen er byttet ut, blir SQL-setningen følgende streng:
sql="Velg * fra brukertabell hvor name='111'or'1=1' og password='aaaa'
Vi vet alle at når select-setningen vurderer spørringsbetingelsene, vil den ignorere følgende og (og)-operasjoner når den møter eller (eller)-operasjoner, og verdien 1=1 i ovenstående utsagn er alltid sann, noe som betyr at uansett hvilken verdi som legges inn i passordet, kan den bestå passordverifiseringen ovenfor! Løsningen på dette problemet er veldig enkel, og det finnes mange metoder; den vanligste er å vurdere legitimiteten til brukeren og passordet brukeren har skrevet inn før verifisering, og spesialtegn som enkeltstående anførselstegn og likhetstegn er ikke tillatt.
De ovennevnte problemene, selv om de kan virke enkle, eksisterer. For eksempel hadde den tidlige versjonen av det berømte nettspillet "Smiling Proud Jianghu" på Internett et slikt problem, og forfatteren analyserte også nøye noen av programmene han hadde skrevet tidligere etter å ha lest sårbarhetsrapporten om dette spillet, og det fantes mange slike smutthull. Dette burde virkelig være vår oppmerksomhet. Dette avslører også mangelen på programmeringserfaring og sikkerhetsbevissthet hos unge programmerere, inkludert forfatteren. Samtidig minner det oss også om at programmerere bør vurdere programmets sikkerhet fullt ut når de designer det, og ikke være slurvete, og at en tilsynelatende liten utelatelse kan føre til alvorlige konsekvenser.
|
Publisert på 26.11.2014 15:47:51
|
|
|
