SQL-injectie is een eenvoudige aanvalsvector die vandaag de dag nog steeds zeer gebruikelijk is. De reden hiervoor is niets minder dan geen patch voor domheid. Waarom zeg je dit, laten we JAVA als voorbeeld nemen om dat te illustreren:
Stel dat er een tabel als deze in de database bestaat:
Gebruik vervolgens de JDBC-actietabel:
De bovenstaande code wordt vaak door sommige ontwikkelaars gebruikt. Stel je een situatie voor waarin de binnenkomende userId-parameter "3; gebruiker van de droptafel; De uitgevoerde SQL-instructie is als volgt:
Nadat de database is gecompileerd en uitgevoerd, wordt de gebruikerstabel verwijderd. Voilà, een eenvoudige SQL-injectie-aanval treedt in! Dit komt doordat de bovenstaande code niet voldoet aan de programmeerspecificaties.
Wanneer we programmeren volgens de specificatie, bestaat SQL-injectie niet. Dit is ook het gevalDe eerste manier om SQL-injectie te vermijden: pregecompileerde statements, de code is als volgt:
Waarom bestaat SQL-injectie niet in bovenstaande code? Omdat de pregecompileerde instructie wordt gebruikt, stelt de pregecompileerde instructie "selecteer naam van gebruiker waar id= ?" Wordt de instructie van tevoren gecompileerd zodat deze alleen vervangen hoeft te worden door de binnenkomende parameters bij uitvoering? Tijdelijke aanduidingen zijn prima. Voor het eerste niet-conforme geval schrijft het programma een SQL-instructie en compileert deze vervolgens met de door de gebruiker doorgegeven inhoud, wat precies het probleem is.
Naast het gebruik van vooraf gecompileerde statements is er een tweede optieManieren om SQL-injectieaanvallen te vermijden: Stored procedures。 Een opgeslagen procedure is een set SQL-instructies die een specifieke functie uitvoeren, gecompileerd en opgeslagen in een database, en de gebruiker kan deze uitvoeren door een opgeslagen procedure aan te roepen en een parameter te geven (als de opgeslagen procedure parameters heeft), die ook SQL-injectieaanvallen kan vermijden
De overeenkomstige opgeslagen procedure in bovenstaande code is als volgt:
Natuurlijk kunnen gebruikers ook tekencontroles uitvoeren op de frontend, wat ook een manier is om SQL-injectie te vermijden: bijvoorbeeld, voor de bovenstaande userId-parameter controleert de gebruiker op een puntkomma en wordt er een foutmelding weergegeven.
De meest fundamentele reden is echter dat SQL-injectieaanvallen bestaan omdat apps geen least privilege gebruiken bij het benaderen van databases. Het lijkt erop dat iedereen het rootaccount gebruikt om toegang te krijgen tot de database.
Dus hoe voorkomt MyBatis SQL-injectie-aanvallen? Of neem de bovenstaande tabelgebruiker als voorbeeld:
Stel dat het mapperbestand is:
De bijbehorende java-bestanden zijn:
Je kunt zien dat de invoerparameter userId van type String is, wanneer we userId="34; gebruiker van de droptafel; Daarna luidt de gedrukte verklaring:
Ongeacht de invoerbare userID, is zijn SQL-instructie als volgt. Dit komt doordat mybatis vooraf gecompileerde statements gebruikt in de onderliggende implementatie. Wanneer de database die instructie uitvoert, gebruikt deze direct de vooraf gecompileerde instructie en vervangt vervolgens de placeholder door de doorgegeven userId? Ga gewoon rennen. Eerst plaatsvervangers plaatsen? Het compilatieproces wordt uitgevoerd, dus er is geen ruimte voor SQL-injectie om te overleven.
Hoe doet MyBatis SQL-precompilatie eigenlijk? In feite wordt de PreparedStatement-klasse onderaan het framework gebruikt. De PreparedStaement-klasse voorkomt niet alleen SQL-injectie, maar bespaart ook (N-1) compilatietijd wanneer dezelfde SQL-instructie N keer wordt uitgevoerd, wat de efficiëntie verbetert.
Als je bovenstaande uitspraak verandert in:
Wanneer we userId="34 invoeren; gebruiker van de droptafel; Daarna luidt de gedrukte verklaring:
Op dit moment gebruikt mybatis geen pregecompileerde instructies, het zal eerst strings stitchen en daarna compilatie uitvoeren, wat precies is hoe SQL-injectie effect heeft.
Probeer daarom bij het schrijven van mybatis-mapping-statements het formaat "#{xxx}" te gebruiken. Als je parameters als "${xxx}" moet gebruiken, moet je ze handmatig filteren om SQL-injectie-aanvallen te voorkomen.
|
Geplaatst op 16-08-2018 10:57:34
|
|
|
