Als internationale standaard databasequery-instructie zijn SQL-instructies veelvuldig gebruikt in diverse programmeeromgevingen. Als een volwassen en stabiel systeem zijn gebruikersinloggen en wachtwoordverificatie essentieel. In mijn dagelijkse programmeerwerk ontdekte ik dat veel programmeurs SQL-statements gebruiken om gebruikerswachtwoorden te verifiëren via een instructie als deze:
sql="Selecteer * uit gebruikerstabel waarbij naam='"+naam+"' en wachtwoord='"+wachtwoord+"'"
De naam en het wachtwoord zijn de gebruikersnamen en wachtwoorden die door de gebruiker zijn ingevoerd, en bovenstaande statements worden uitgevoerd om te verifiëren of de gebruiker en het wachtwoord legitiem en geldig zijn. Door analyse blijkt echter dat er fatale mazen in de bovenstaande uitspraken zitten. Wanneer we de volgende string invoeren in de gebruikersnaam: 111'or'1=1, en vervolgens het wachtwoord casual invoeren, zetten we het op aaaa. Nadat de variabele is vervangen, wordt de SQL-instructie de volgende string:
sql="Selecteer * uit gebruikerstabel waarbij naam='111'of'1=1' en wachtwoord='AAAAA'
We weten allemaal dat wanneer de select-instructie de queryvoorwaarden beoordeelt, deze de volgende en (en) bewerkingen negeert bij het tegenkomen van of (of) operaties, en de waarde van 1=1 in bovenstaande uitspraak altijd waar is, wat betekent dat ongeacht welke waarde in het wachtwoord wordt ingevoerd, het bovenstaande wachtwoordverificatie kan doorstaan! De oplossing voor dit probleem is heel eenvoudig, en er zijn veel methoden; de meest gebruikte is het beoordelen van de legitimiteit van de gebruiker en het door de gebruiker ingevoerde wachtwoord voordat de verificatie wordt uitgevoerd, en speciale tekens zoals enkele aanhalingstekens en gelijke tekens zijn niet toegestaan.
De bovenstaande problemen, hoewel ze eenvoudig lijken, bestaan wel. Zo had de vroege versie van het beroemde online spel "Smiling Proud Jianghu" op het internet zo'n probleem, en de auteur analyseerde ook zorgvuldig enkele programma's die hij eerder had geschreven na het lezen van het kwetsbaarheidsrapport over dit spel, en er waren veel van zulke mazen in de wet. Dit zou echt onze aandacht moeten zijn. Dit legt ook het gebrek aan programmeerervaring en beveiligingsbewustzijn van jonge programmeurs, inclusief de auteur, bloot. Tegelijkertijd herinnert het ons er ook aan dat programmeurs bij het ontwerpen volledig rekening moeten houden met de veiligheid van het programma, en dat ze niet slordig moeten zijn, en dat een ogenschijnlijk kleine omissie ernstige gevolgen kan veroorzaken.
|