SQL injectie in Magento: Hoe uw Magento winkel te beveiligen tegen SQL-injectie aanval

Magento is behoorlijk populair bij het bedrijfsleven. Dit is terug te voeren op de open-source oorsprong. Magento was bedoeld om het proces van het beheren en creëren van een winkel te vergemakkelijken. Omdat het open-source is, gebruikt het MySql of MariaDB voor gegevensopslag en -beheer. Database speelt een cruciale rol bij het beheren van de Magento-winkel. Dit betekent ook dat het richten op de Magento-database met Magento SQL-injectie-aanvallen vrij gebruikelijk is. Een Magento SQL-injectie is het resultaat van niet-opgeschoonde gebruikersinvoer. Het is een aanzienlijke bedreiging die opdoemt over de winkels. Een slordige codering kan de hele database blootleggen.

Naast SQL-injectie-aanvallen heeft Magento ook last van Creditcard diefstal oplichting, Cryptojacking, SEO-spam en andere cyberbedreigingen. In dit artikel zullen we ons echter concentreren op Magento SQL-injectie-aanvallen en hoe u kunt voorkomen dat deze in uw winkel plaatsvinden.

Volg de onderstaande links als u op zoek bent naar

• Magento Hack verwijderen
• Magento-beveiligingsgids (voor solide beveiliging tegen XSS, SQLi, creditcardhack, beheerdershack)

Wat kan een Magento SQL-injectie doen?

De database is een van de meest gevoelige componenten van uw winkel. De eerste SQLi werd al in 1998 gerapporteerd. Toch haalt SQLi nog steeds de lijst met OWASP Top 10-kwetsbaarheden. Er is dus een goede reden om er op te letten. Een Magento SQL-injectie kan:

• Lees de inhoud van een database.
• Manipuleer de database. Dit kan de inhoud van de winkel wijzigen.
• Verwijder de hele database.
• Steel creditcardgegevens.
• Geef beheerdersreferenties weer. Dit zou de weg kunnen banen voor verdere aanvallen.
• Verkrijg in sommige gevallen een omgekeerde schaal. Het kan de privileges vervolgens escaleren

Elk jaar worden geavanceerde methoden gevonden om een ​​Magento SQL-injectie te exploiteren. Elke maand worden nieuwe trucs ontwikkeld om filters te omzeilen en Magento-beveiligingsaudits. De dreiging van een Magento SQL-injectie-aanval neemt dus met de dag toe. Er kan nog veel worden gedaan om Magento SQL-injectie te voorkomen.

Uw winkel vertoont tekenen van een Magento SQL-injectie-aanval? Stuur ons een bericht via de chatwidget en we helpen je graag verder.Beveilig nu mijn Magento-website.

Oorzaken van Magento SQL Injection

1) Implementatie van code aan de klantzijde

Vaak besteden de ontwikkelaars geen aandacht aan beveiliging coderingspraktijken. Als gevolg hiervan wordt er code aan de clientzijde uitgevoerd. Omdat het op de computer van de klant wordt uitgevoerd, kan het door de klant worden gewijzigd. Dit kan ertoe leiden dat invoervalidatie wordt omzeild. In termen van de leek: de aanvaller kan uw beveiligingscontrole doorstaan ​​alleen omdat u hem de leiding heeft gegeven. Vraag uw ontwikkelaar om de gevoelige functies aan de serverzijde uit te voerenom Magento SQL-injectie te voorkomen.

2) Niet-gezuiverde invoer

Vaak wordt de input die van de gebruiker wordt ontvangen, niet goed opgeschoond. Elke keer dat een verzoek aan de server wordt gedaan, wordt een nieuwe vraag gegenereerd met behulp van de opgegeven invoer. Deze staan ​​bekend als dynamische query’s. Laten we eens kijken waarom deze gevaarlijk zijn. Kijk bijvoorbeeld naar de volgende vraag:

txtUserId = getRequestString (“Gebruikersnaam”);

txtSQL = “SELECT * FROM Gebruikers WHERE UserId =” ‘+ txtUserId’ “;

Dit stuk code vraagt ​​om UserId en verzendt het vervolgens naar de SQL-query. Alles lijkt in orde, wat kan er mis gaan? Laten we zien. Een aanvaller kan een input leveren zoals105 ‘; DROP TABLE-gebruikers. Dus nu heeft de aanvaller heel duidelijk de ene stelling over de andere gestapeld. De tweede zoekopdracht wordt dus na de eerste uitgevoerd. Dus de laatste query die zal worden uitgevoerd, is

SELECTEER * FROM Gebruikers WAAR UserId = 105; DROP TABLE-gebruikers;

Op deze manier kan de aanvaller de inhoud van de database wijzigen. Daarom is het het beste om dynamische zoekopdrachten te vermijden. Maak je ook geen zorgen. Er is een alternatief voor dynamische zoekopdrachten. Dit worden voorbereide statements genoemd die Magento SQL-injectie helpen voorkomen.

3) Tautologieën

Ten eerste gebruikt dit soort aanvallen verklaringen die als waar worden geëvalueerd. Het helpt dus om inlogbeperkingen te omzeilen. Slechte coderingspraktijken kunnen ertoe leiden dat de beperkingen worden omzeild. Kijk bijvoorbeeld naar de broncode van een inlogpagina hieronder:

<? php

$ _POST[‘gebruikersnaam’] = ”;

$ _POST[‘wachtwoord’] = ”;

$ query = “SELECT * VAN gebruikers WHERE user = ‘{$ _POST[‘gebruikersnaam’]} ‘EN

wachtwoord = ‘{$ _POST[‘wachtwoord’]}'”;

mysql_query ($ query);

echo$ query;

?>

Het vergt slechts invoer van gebruikers- en wachtwoordvelden. Evalueert ze vervolgens tegen SQL-query’s. Als de aanvaller nu een invoer alsadmin ‘of 1 = 1–. Dus de uitgevoerde SQL-instructie zal zijn

SELECTEER * VAN gebruikers WAAR gebruiker = ‘beheerder’ EN wachtwoord =” OF 1=1-

Let op de symbolen -zorg ervoor dat alle andere uitspraken nadat deze als commentaar worden behandeld. Daarom heeft de aanvaller de inlogpagina omzeild en is hij nu de admin. Er zijn ook meerdere varianten van’of 1 = 1–. Er is een uitgebreidelijstvan dergelijke parameters. Slechte codering kan uw inlogpagina’s kwetsbaar maken voor Magento SQL-injectie-aanvallen.

4) Foutmeldingen

Foutmeldingen kunnen veel over uw systeem weggeven. Sommigen van hen kunnen de kolommen en de databaseversie onthullen. Kijk bijvoorbeeld naar deze afbeelding hieronder.

Dit bericht onthult hier de database en kolommen. Er zijn dus verschillende berichten voor verschillende databases. Magento draait op My SQL, dus het ziet er ongeveer zo uit. Deze berichten kunnen aanvallers helpen bij het uitvoeren van een Magento SQL-injectie-aanval. Het uitschakelen van fouten kan helpen om Magento SQL-injectie te voorkomen. Maar als foutmeldingen zijn uitgeschakeld, dreigt de mogelijkheid van blinde SQLi nog steeds. Het is echter het beste om foutmeldingen voor de gebruikers uit te schakelen.

5) Databasebevoegdheden

Onjuiste machtigingen kunnen de Magento SQL-injectie-aanval verder voeden. Nadat de database is gecompromitteerd, krijgt de aanvaller beheerdersrechten. Dit gebeurt omdat het exemplaar van de database werd uitgevoerd als admin. Daarom kan de aanvaller de inhoud naar wens manipuleren. Als er geen beheerdersrechten waren, kon de aanvaller alleen de inhoud lezen. Zo kunnen databaseprivileges SQL-commando’s zoals Update, Insert etc. stoppen. Het is dus veilig om DBA in te stellen op False.

6) Versleuteling

Als de gevoelige tabelwaarden niet versleuteld zijn, wordt het vuur gevoed. Het opslaan van wachtwoorden in leesbare tekst is dus een grote vergissing! Zorg ervoor dat de codering is ingesteld op True voor uw database. Het kan dus fungeren als schadebeperking in het geval van een Magento SQL-injectie-aanval.

7) Variabele grootte filtering

Als er geen limiet is aan de grootte van variabelen, kan de gebruiker een lange invoer opgeven. Dit is meestal kwaadaardige invoer die SQL-instructies bevat. Dus als er een limiet is voor de variabele grootte, kan dit een Magento SQL-injectie voorkomen. Zo worden Magento SQL-injectie aanvallen voorkomen.

Professionele hulp nodig bij het beveiligen van Magento Store? Stuur ons een bericht via de chatwidget en we helpen je graag verder.Bescherm nu mijn Magento-website.

Magento Security Audit Post SQL-injectie

1) Detectie van kwetsbaarheid voor SQL-injectie

De beste manier om op zoek te gaan naar een Magento SQL-injectie, is door logboeken te graven. Kijk naar de afbeelding hieronder enlaat je logboek zoiets zien?

Zo ja, dan is er een geautomatiseerde SQLi-tool gebruikt. De serverlogboeken geven de verschillende gebruikte SQL-instructies weer. Controleer de databaselogboeken onmiddellijk om te bepalen welke wijzigingen hebben plaatsgevonden. Kijk ook of er nieuwe gebruikers zijn opgedoken.

Schakel de betrokken pagina’s tijdelijk uit totdat de code is opgelost. Zorg er ook voor dat het exemplaar van de database niet als beheerder op de server wordt uitgevoerd. Dit zou het vermogen van een aanvaller om alleen te lezen, beperken. Vanga hier verder voor de Magento-beveiligingsaudit.

2) Gebruikers controleren

Een heuristisch idee kan worden genomen met behulp van het commando toon tafels;. Als er tabellen zoals Sqlmap bestaan, is er hoogstwaarschijnlijk een geautomatiseerde tool tegen de website uitgevoerd. De volgende stap is het zoeken naar nieuwe gebruikers. Gebruik het volgende commando:

Selecteer * van gebruikers als u

EN u.created> UNIX_TIMESTAMP (STR_TO_DATE (‘Okt 15 2018’, ‘% M% d% Y’));

Deze SQL-instructie geeft gebruikers weer die zijn gemaakt na 15 oktober. De datumreeks kan worden gemanipuleerd om terug in de tijd te kijken. Rogue-databases kunnen worden verwijderd met behulp van de volgende SQL-instructie:

laten vallen database databasenaam.dbo;

3) Gebruikers blokkeren

Na detectie van malafide gebruikers is het tijd om ze te blokkeren. Dus de volgende SQL-instructie doet het:

bijwerken gebruikers stellen pass = concat (‘ZZZ’, sha (concat (pass, md5 (rand ()))));

De volgende verklaring werkt de tabelgebruikers bij en stelt een nieuw wachtwoord in. Bovendien is het wachtwoord versleuteld ingesteld. De aanvaller zou dus brute kracht moeten gebruiken en andere bekende technieken moeten gebruiken om platte tekst te krijgen.

4) Database herstellen

Soms heeft de aanvaller de database verwijderd. In dat scenario kan het worden hersteld vanaf de back-up. Voer gewoon de My SQL-opdrachtregelclient uit. Log in met de volgende opdracht.mysql -u root -p ‘uw wachtwoord’ Voer daarna de volgende SQL-instructies uit:

creëren database nieuwe_db;

gebruik nieuwe_db;

\. backupfile.sql

Dit zal de database herstellen. Zo wordt de schade beperkt die wordt veroorzaakt door een Magento SQL-injectiehack. De winkel heeft echter nog steeds een uitgebreide Magento-beveiligingsaudit nodig.

Voorbeeld van SQL Injection Attack in Magento 

example.com/?___from_store=en ‘vereniging selecteer 0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526,0x5e2526 -“`

De _ _store en _ _from_store URL-parameters worden gebruikt in Magento Multistore-installaties om te schakelen tussen versies van de winkel en talen. Hackers vallen deze parameter vaak aan met SQL Injection-query’s.

Dit is typisch gedrag van geautomatiseerde beveiligingstools zoals Sqlmap en Acunetix. Als de tool vermoedt dat “union injection” mogelijk is, zal het eerst proberen te bepalen hoeveel velden het nodig heeft in de union query, en ook kijken welke velden in de output terugkomen. Het hebben van een unieke query als deze helpt om beide te testen, en omzeilt ook enkele beveiligingssystemen waar u niet naar veldindexen in de query kunt verwijzen.

Hoe Magento SQL Injection Attack te voorkomen

1) Beveiligingsparameters

Elke database wordt geleverd met specifieke beveiligingsparameters. Deze helpen bij het voorkomen van Magento SQL-injectie-aanvallen. Kijk bijvoorbeeld naar deze code:

txtUser = getRequestString (“Gebruiker”);

txtPass = getRequestString (“Wachtwoord”);

txtOTP = getRequestString (“OTP”);

txtSQL = “VOEG IN IN Login (Gebruiker, Wachtwoord, OTP Waarden (@0, @1, @2)”;

db. Uitvoeren(txtSQL, txtUser, txtPass, txtOTP);

De invoerparameters worden weergegeven door dus @ marker. Daarom controleert de SQL-engine elke parameter. Bovendien zorgt het ervoor dat ze letterlijk worden behandeld. Dit voorkomt dat ze deel uitmaken van de SQL-instructie. Daarom maakt elke invoer die de gebruiker geeft geen deel uit van de SQL-instructie. Je hebt dus met succes een Magento SQL-injectie voorkomen. Als u echter PHP wilt uitvoeren, is hier de code:

$ stmt = $ dbh-> voorbereiden (“INSERT IN TO Login (Gebruiker, Wachtwoord, OTP) 

 WAARDEN (: usr,: pass,: otp) “); $ stmt-> bindParam (‘: usr’, $ txtUser); $ stmt-> bindParam (‘: pass’, $ txtPass); $ stmt-> bindParam ( ‘: otp’, $ txtOtp); $ stmt-> execute ();

Raadpleeg nu Astra-beveiligingsexperts zoek en repareer een Magento SQL-injectie. Onze krachtige firewall beschermt uw website tegen SQL Injection, XSS, LFI, RFI, Bad bots, geautomatiseerde kwetsbaarheidsscanners en 80+ beveiligingsbedreigingen.Beveilig nu mijn website.

2) Gebruik voorbereide verklaringen

De alternatieve optie voor dynamische query’s zijn de voorbereide instructies. Dit zijn de verklaringen die later worden voorbereid en geparseerd. De database slaat de instructie dus op zonder deze uit te voeren. Het controleert eerst de parameters. Later zorgt het ervoor dat een stringinvoer alleen een string is, enzovoort. Dit zorgt ervoor dat de input niet ondeugend is. Nadat alle parameters zijn gecontroleerd, voert het de instructies uit. Zo zorgt u ervoor dat er geen Magento SQL-injectie-aanval plaatsvindt. Hieronder is een voorbereide instructie-implementatie in My SQL en PHP weergegeven.

Zoals we hier kunnen zien, zijn er ‘?’ in plaats van enkele waarden. Er staat dus dat het specifieke gegevenstype de waarde hier zal vervangen. Het kan een geheel getal, string, blob etc. zijn. Magento gebruikt het Zend framework. In dat geval kunnen dus de componenten van het Zend-framework worden gebruikt. Bind de queryparameters aan de query met de bind van Zend_Db_Select in plaats van een volledige SQL-instructie te gebruiken. Zoals dit:

$ query = $ this -> _ connection-> select () -> from (‘eav_attribute’) -> waar (‘attribute_id =?’, $ attributeId); $ resultaat = $ this -> _ verbinding-> fetchAll ($ query);

3) Beperk bevoegdheden

Zorg ervoor dat de gevoelige kolommen zijn versleuteld. Dus zelfs als de database is gecompromitteerd, moet de aanvaller het wachtwoord bruut forceren. Zorg er ook voor dat de gebruikte wachtwoorden sterk zijn. Beperk bovendien de rol van de database. Verklaringen als Update, Drop etc. niet toestaan

4) Gebruik een firewall voor webtoepassingen

Handmatige inspectie van code om een ​​Magento SQL-injectie-aanval te bepalen, is vervelend. Dus huur de experts ervoor in. Gebruik ook een firewall zodat dergelijke opdrachten niet door de filters kunnen passeren. Astra heeft een geweldige firewall en beveiligingsoplossing die is ontworpen om buiten te blijvenMagentoSQL-injectie-aanval. Magento-beveiligingsaudits kunnen in de toekomst kostbare middelen en tijd besparen!

Neem onze woorden niet op. Overtuig uzelf!

Neem een ​​kijkje in Astra

Vraag nu een demo aan 

Trefwoorden: Magento SQL-injectie, Magento SQL Injection voorbeeld, Voorkom SQL-injectie in Magento

Share this...

Facebook

Pinterest

Twitter

Linkedin