JVM Log Forging

1. Overzicht

In dit korte artikel zullen we een van de meest voorkomende beveiligingsproblemen in JVM wereld - Log Forging. We laten ook een voorbeeldtechniek zien die ons tegen dit beveiligingsprobleem kan beschermen.

2. Wat is houtsmeden?

Volgens OWASPis het vervalsen van logs een van de meest voorkomende aanvalstechnieken.

Kwetsbaarheden bij het vervalsen van logboeken treden op wanneer gegevens een toepassing binnenkomen vanuit een niet-vertrouwde bron of wanneer de gegevens door een externe entiteit naar een toepassing / systeemlogboekbestand worden geschreven.

Vanaf OWASP richtlijnen logs vervalsen of injecteren is een techniek waarbij niet-gevalideerde gebruikersinvoer naar logbestanden wordt geschreven, zodat een aanvaller logboekvermeldingen kan vervalsen of schadelijke inhoud in de logboeken kan injecteren.

Simpel gezegd, door het vervalsen van logs probeert een aanvaller recordinhoud toe te voegen / te wijzigen door beveiligingslekken in de toepassing te verkennen.

3. Voorbeeld

Beschouw een voorbeeld waarin een gebruiker een betalingsverzoek indient vanaf internet. Vanaf het toepassingsniveau wordt, zodra dit verzoek is verwerkt, één invoer gelogd met het bedrag:

private laatste Logger-logger = LoggerFactory.getLogger (LogForgingDemo.class); public void addLog (String bedrag) {logger.info ("Bedrag gecrediteerd = {}", bedrag); } public static void main (String [] args) {LogForgingDemo demo = nieuwe LogForgingDemo (); demo.addLog ("300"); }

Als we naar de console kijken, zien we zoiets als dit:

web - 2017-04-12 17: 45: 29,978 [main] INFO com.baeldung.logforging.LogForgingDemo - Bijgeschreven bedrag = 300

Stel nu dat een aanvaller de invoer levert als "\ N \ nweb - 2017-04-12 17: 47: 08,957 [main] INFO Bedrag succesvol teruggeboekt", dan zal het logboek zijn:

web - 2017-04-12 17:52: 14,124 [main] INFO com.baeldung.logforging. LogForgingDemo - Bedrag gecrediteerd = 300 web - 2017-04-12 17: 47: 08,957 [main] INFO Bedrag succesvol teruggedraaid

De aanvaller heeft opzettelijk een vervalste vermelding in het toepassingslogboek kunnen maken, waardoor de waarde van de logboeken is aangetast en alle activiteiten van het controletype in de toekomst kunnen worden verward. Dit is de essentie van het smeden van houtblokken.

4. Preventie

De meest voor de hand liggende oplossing is om geen gebruikersinvoer in logbestanden te schrijven.

Maar dat is misschien niet onder alle omstandigheden mogelijk, aangezien de door de gebruiker opgegeven gegevens nodig zijn voor het debuggen of controleren van de toepassingsactiviteit in de toekomst.

We moeten een ander alternatief gebruiken om dit soort scenario's aan te pakken.

4.1. Introduceer validatie

Een van de gemakkelijkste oplossingen is om de invoer altijd te valideren voordat u gaat loggen. Een probleem met deze aanpak is dat we tijdens runtime veel gegevens moeten valideren, wat de algehele systeemprestaties zal beïnvloeden.

Als de validatie mislukt, worden de gegevens niet geregistreerd en gaan ze voor altijd verloren, wat vaak geen acceptabel scenario is.

4.2. Database loggen

Een andere mogelijkheid is om de gegevens in de database te loggen. Dat is sindsdien veiliger dan de andere aanpak ‘\ N ' of newline betekent niets voor deze context. Dit geeft echter aanleiding tot een ander prestatieprobleem, aangezien een groot aantal databaseverbindingen zal worden gebruikt voor het loggen van gebruikersgegevens.

Bovendien introduceert deze techniek nog een beveiligingsprobleem, namelijk SQL injectie. Om dit aan te pakken, kunnen we uiteindelijk veel extra regels code schrijven.

4.3. ESAPI

Gebruik makend van ESAPI is de meest gedeelde en aanbevolen techniek in deze context. Hier worden alle gebruikersgegevens gecodeerd voordat ze in de logboeken worden geschreven. ESAPI is een open source API die beschikbaar is vanaf OWASP:

 org.owasp.esapi esapi 2.1.0.1 

Het is beschikbaar in de Central Maven Repository.

We kunnen de gegevens coderen met ESAPI‘S Encoder koppel:

public String encode (String bericht) {message = message.replace ('\ n', '_') .replace ('\ r', '_') .replace ('\ t', '_'); message = ESAPI.encoder (). encodeForHTML (bericht); terug bericht; }

Hier hebben we een wrapper-methode gemaakt die alle wagenretouren en regelfeeds vervangt door onderstrepingstekens en het gewijzigde bericht codeert.

Als we in het eerdere voorbeeld het bericht coderen met behulp van deze wrapper-functie, zou het log er ongeveer zo uit moeten zien:

web - 12-04-2017 18: 15: 58,528 [hoofd] INFO com.baeldung.logforging. LogForgingDemo - Bijgeschreven bedrag = 300 __web - 2017-04-12 17: 47: 08,957 [main] INFO Bedrag succesvol teruggedraaid

Hier wordt het beschadigde stringfragment gecodeerd en kan het gemakkelijk worden geïdentificeerd.

Een belangrijk punt om op te merken is dat je het moet gebruiken ESAPI we moeten opnemen ESAPI.eigenschappen bestand in het klassenpad anders het ESAPI API genereert tijdens runtime een uitzondering. Het is hier beschikbaar.

5. Conclusie

In deze korte zelfstudie hebben we geleerd over het vervalsen van logs en technieken om dit beveiligingsprobleem weg te nemen.

Zoals altijd is de volledige broncode beschikbaar op meer dan op GitHub.