Phenquestions
Kwetsbaarheid van SQL-afkorting bestaat meestal in MySQL-databases. Deze kwetsbaarheid werd voor het eerst beschreven in CVE-2008-4106, die verband hield met WordPress CMS.
Hoe SQL-afbrekingsaanvallen werken
Deze aanval werkt door het inkorten van gebruikersinvoer in databases met behulp van de functies 'selectie' en 'invoegen'.
- Wanneer invoer wordt gegeven in het formulierveld, controleert de functie 'select' op redundantie die overeenkomt met invoer in de database.
- Na controle op redundantie controleert de 'insertion'-functie de lengte van de invoer, en de gebruikersinvoer wordt afgekapt als de lengte groter is dan.
Stel dat een ontwikkelaar de tabel "gebruikers" maakt via de volgende query:
tabelgebruikers aanmaken(user_id INT NIET NULL AUTO_INCREMENT,
gebruikersnaam VARCHAR (20) NIET NULL,
wachtwoord VARCHAR(40) NOT NULL,
PRIMAIRE SLEUTEL ( user_id )
);
Gebruik dit schema als de ontwikkelaar een beheerdersaccount maakt met het volgende:
user_name = 'admin'wachtwoord = "secret_p4ssw0ord"
Het is duidelijk dat deze inloggegevens niet openbaar zijn. Er is slechts één beheerdersaccount in de database en als een aanvaller probeert een ander account te registreren met de 'admin'-gebruikersnaam, zal de aanvaller falen vanwege de redundantiecontroles van de database. De aanvaller kan die redundantiecontrole nog steeds omzeilen om een ander beheerdersaccount toe te voegen door misbruik te maken van het beveiligingslek met betrekking tot SQL Truncation. Stel dat de aanvaller een ander account registreert met de volgende invoer:
Gebruikersnaam = 'adminxxxxxxxxxxxxxxxxxxwillekeurig'(x zijn de spaties)
&
Wachtwoord = "Willekeurige Gebruiker"
De database neemt de 'user_name' (26 karakters) en controleert of deze al bestaat. Vervolgens wordt de invoer gebruikersnaam afgekapt en wordt 'admin' ('admin' met spatie) in de database ingevoerd, wat resulteert in twee dubbele beheerdersgebruikers.
De aanvaller kan dan een 'admin'-gebruiker maken met zijn eigen wachtwoord. Nu heeft de database twee admin 'user_name'-vermeldingen, maar met verschillende wachtwoorden. De aanvaller kan inloggen met de nieuw aangemaakte inloggegevens om een beheerderspaneel te krijgen, omdat zowel gebruikersnamen "admin" als "admin" gelijk zijn voor het databaseniveau. Nu zullen we kijken naar een voorbeeld van een praktische aanval.
Voorbeeldaanval
In dit voorbeeld nemen we een scenario van de website over thewire.org. De overthewire-community biedt wargame-CTF's waarop we onze beveiligingsconcepten kunnen oefenen. Het scenario van SQL-afkapping vindt plaats in natas-spel Level 26->27. We hebben toegang tot het niveau met behulp van het volgende:
URL: http://natas27.natas.laboratoria.over de draad.orgGebruikersnaam: natas27
Wachtwoord: 55TBjpPZUUJgVP5b3BnbG6ON9uDPVzCJ
Dit niveau is beschikbaar op: https://overthewire.org/wargames/natas/natas27.html. U krijgt een inlogpagina te zien die kwetsbaar is voor een SQL Truncation-aanval.
Bij het inspecteren van de broncode, zult u zien dat de gebruikersnaam 64 is, zoals hieronder weergegeven:.
Er bestaat al een gebruiker met de naam 'natas28'. Ons doel is om nog een gebruiker met de naam 'natas28' te maken met behulp van de SQL_truncation-aanval. We zullen dus natas28 invoeren, gevolgd door 57 spaties en een willekeurig alfabet (in ons geval a), gebruikersnaam en elk wachtwoord. De letter 'a' is niet zichtbaar in de schermafbeelding vanwege de gebruikersnaam van 65 tekens. Na het aanmaken van het gebruikersaccount, ziet u de 'een.'
Als de database sql_truncation-kwetsbaarheid bevat, zou de database nu twee 'natas28'-gebruikersnamen moeten hebben. Eén gebruikersnaam bevat ons wachtwoord. Laten we proberen de inloggegevens op de inlogpagina in te voeren.
Nu zijn we ingelogd als de 'natas28'-gebruiker.
Mitigatie
Om deze aanval af te zwakken, moeten we rekening houden met meerdere factoren.
- We mogen niet toestaan dat kritieke identiteiten worden gedupliceerd, zoals de gebruikersnaam. We zouden van deze identiteiten primaire sleutels moeten maken.
- De truncate-functie moet worden geïmplementeerd voor alle velden van frontend-formulieren, evenals backend-code, zodat databases afgekapte invoer ontvangen.
- De strikte modus moet worden ingeschakeld op databaseniveau. Zonder de strikte modus ingeschakeld, geven databases alleen waarschuwingen in de backend, maar slaan de dubbele gegevens nog steeds op. Met de strikte modus geven databases fouten in het geval van duplicatie en voorkomen ze het opslaan van gegevens.
Laten we bijvoorbeeld de strikte modus controleren met behulp van de volgende query:
mysql> selecteer @@sql_mode
We zullen een database maken en de tabel 'gebruikers'.'
mysql> CREATE DATABASE-testQuery OK, 1 rij beïnvloed (0.02 seconden)
mysql> Gebruik test
Database gewijzigd
mysql> CREATE TABLE-gebruikers (gebruikersnaam VARCHAR (10), wachtwoord VARCHAR (10));
Query OK, 0 rijen beïnvloed (0.05 seconden)
Vervolgens zullen we een admin-gebruiker met inloggegevens maken met behulp van de INSERT-query.
mysql> INSERT INTO gebruikerswaarden ('admin', 'password1');Query OK, 1 rij beïnvloed (0.01 seconden)
We kunnen de tabelinformatie 'gebruikers' zien met de optie 'select * from users' users.
De gebruikersnaam is 10 tekens lang. Nu gaan we de SQL-afkapaanval proberen try.
Wanneer we proberen het volgende in te voeren:
Gebruikersnaam = 'adminxxxxxxa'(x zijn de spaties)
&
Wachtwoord = 'pas2'
We krijgen een foutmelding, wat betekent dat de strikte modus volledig effectief is.
mysql> INSERT INTO gebruikerswaarden('admin a', 'pass2')ERROR 1406 (22001): Gegevens te lang voor kolom 'gebruikersnaam' in rij 1
Als de strikte modus niet is ingeschakeld, geeft de database waarschuwingen af, maar worden de gegevens nog steeds in de tabel ingevoegd.
Conclusie
Aanvallers kunnen toegang krijgen tot accounts met hoge bevoegdheden als de sql_trunction-kwetsbaarheid in uw toepassing bestaat. De aanvaller kan gemakkelijk informatie krijgen over een gebruikersnaam en de lengte van de database met behulp van de kritieke velden en vervolgens dezelfde gebruikersnaam maken, gevolgd door spaties en willekeurig alfabet na de minimale lengte, wat resulteert in het maken van meerdere accounts met hoge bevoegdheden. Dit beveiligingslek is van cruciaal belang, maar kan worden vermeden als u enkele veiligheidsmaatregelen neemt, zoals het activeren van de strikte modus voor gebruikersinvoer en het gevoelige veld de primaire sleutel in de database maken.
