De eerste die in je opkomen zijn:

1. Een SQL-injectieaanval waarbij de databasegebruiker in kwestie alleen het SELECT-recht heeft.
2. Een compromis van de primaire databaseback-ups of de offsite databaseback-ups. Hoewel deze niet alleen-lezen zijn, is de kans klein dat het compromis escaleert door naar back-ups te schrijven.
3. Een compromittering van een shell-account op een databaseserver. Ook al zou je root-privileges op een databasebox kunnen gebruiken om een ​​gebruikersaccount in de database zelf te krijgen, dit zou waarschijnlijk een luidruchtige actie zijn waardoor het compromis zou worden opgemerkt. Je zou nog steeds de volledige database-inhoud kunnen kopiëren zonder opgemerkt te worden.

Het is ook heel goed mogelijk dat de aanvallers in de lekken waar je het over hebt volledige privileges hadden of in ieder geval meer privileges dan alleen-lezen maar koos ervoor om ze niet te gebruiken. Of ze hebben ze wel gebruikt, maar dat gebruik is nog niet ontdekt. Of dat ze de volledige applicatiecode hebben, maar ervoor hebben gekozen om die niet te lekken.

Een interessante gedachte die ik net had toen ik dit schreef over het voorkomen van 1. door het aanvalsoppervlak te verkleinen, is om een ​​aparte databasegebruiker te hebben account dat alleen toegang heeft tot de inlogtabel en uw normale, alleen-lezen gebruiker heeft geen toegang tot deze tabel. Op die manier kan alleen een SQL-injectie in het aanmeldingsformulier uw wachtwoordhashes in gevaar brengen. Elke SQL-injectie in een ander deel van de webtoepassing kan de wachtwoord-hashes (of welke andere gevoelige gegevens dan ook) niet zien.

Database is de goudmijn, daarom betekent het lekken van de gegevens erin alle slechte dingen. De broncode van de applicatie is in sommige gevallen belangrijk, maar als je naar de architectuur van moderne applicaties kijkt, komen de meeste gegevens uit de back-enddatabase. Inloggegevens, PII's, creditcardnummers, financiële en zakelijke gegevens, bijna alles wat u wilt beschermen, bevindt zich in de database.

Het compromitteren van de server (zoals het verkrijgen van de shell) is alleen van belang in het geval van botaanvallen, zodat het botnetwerk wordt uitgebreid. Gerichte aanvallen zijn altijd voor de gegevens. Daarom betekent het compromitteren van de database het bereiken van het doel.

Wat betreft uw "opdrachtaanvallen", de meerderheid van de websites wordt gecompromitteerd door SQL-injectie die rechtstreeks aanvallersvragen op de database uitvoert. Alleen-lezen database is het minimum dat u krijgt bij SQL-injectie. SQLi kan ook resulteren in een volledig compromitteren van de machine door shellcode te uploaden via de "INTO DUMPFILE" -richtlijn en deze roept de shell op via de webapplicatie, wat resulteert in een complete interactieve shell via de browser.

Dus datalek meestal bereiken ze het doel, daarom stoppen aanvallers daar. Als dit niet het geval is, biedt SQL-injectie ook veel andere aanvalsmogelijkheden.

Ik denk dat als ze een SQL-injectie vinden en de gebruiker die de website gebruikt om de database te doorzoeken alleen leestoegang heeft, dan zou het resultaat inderdaad zijn dat hij alleen een alleen-lezen SQL-injectie-aanval kan uitvoeren. Maar ik denk niet dat er een specifieke klasse is voor dat soort aanvallen. In het algemeen voegen we alleen-lezen naam van de aanval

Als de database het enige gecompromitteerde deel van de webapplicatie is, is het bijna altijd een SQL-injectie , die een applicatiefunctie (bijvoorbeeld een zoekformulier) misbruikt om willekeurige gegevens uit de onderliggende database.

Een databaselek kan ook worden veroorzaakt door een interne aanval , uitgevoerd door een medewerker die voldoende rechten had om toegang te krijgen tot de database.

Gedeeltelijk en volledige databasedumps kunnen ook worden gevonden via Google Hacking , dat zoekmachines gebruikt om gevoelige bestanden te ontdekken die zijn geïndexeerd.

Ten slotte zou ik toepassingsfouten die gegevens uit de database kunnen vrijgeven als uitzonderingen niet correct worden afgehandeld.