streamalism.org

1. Oversigt

I denne hurtige artikel undersøger vi et af de mest almindelige sikkerhedsproblemer i JVM verden - Log smedning. Vi viser også et eksempel på en teknik, der kan beskytte os mod denne sikkerhedsproblem.

2. Hvad er logsmedning?

Ifølge OWASP, log smedning er en af ​​de mest almindelige angrebsteknikker.

Sårbarheder ved logsmedning opstår, når data kommer ind i et program fra en ikke-betroet kilde, eller dataene skrives til en applikations- / systemlogfil af en eller anden ekstern enhed.

Som pr OWASP retningslinjer log smedning eller injektion er en teknik til at skrive uvalideret brugerinput til logfiler, så det kan give en hacker mulighed for at smede logindgange eller injicere ondsindet indhold i logfilerne.

Kort sagt, ved at logge smedning, forsøger en angriber at tilføje / ændre postindhold ved at udforske sikkerhedshuller i applikationen.

3. Eksempel

Overvej et eksempel, hvor en bruger indsender en betalingsanmodning fra internettet. Fra applikationsniveau, når denne anmodning er behandlet, logges en post med beløbet:

privat endelig Logger logger = LoggerFactory.getLogger (LogForgingDemo.class); offentlig ugyldig addLog (strengbeløb) {logger.info ("Beløb krediteret = {}", beløb); } public static void main (String [] args) {LogForgingDemo demo = new LogForgingDemo (); demo.addLog ("300"); }

Hvis vi ser på konsollen, ser vi noget som dette:

web - 12-04-2017 17: 45: 29,978 [main] INFO com.baeldung.logforging.LogForgingDemo - Beløb krediteret = 300

Antag nu, at en hacker leverer input som “\ N \ nweb - 2017-04-12 17: 47: 08,957 [main] INFO Beløbet tilbageført med succes”, så vil loggen være:

web - 2017-04-12 17: 52: 14,124 [main] INFO com.baeldung.logforging. LogForgingDemo - Beløb krediteret = 300 web - 2017-04-12 17: 47: 08,957 [main] INFO Beløb tilbageført med succes

Bevidst har angriberen været i stand til at oprette en forfalsket post i applikationsloggen, der ødelagde værdien af ​​logfilerne og forvirrer enhver revisionstypeaktivitet i fremtiden. Dette er essensen af ​​logsmedning.

4. Forebyggelse

Den mest oplagte løsning er ikke at skrive brugerinput i logfiler.

Men det er muligvis ikke muligt under alle omstændigheder, da brugeroplysningerne er nødvendige for fejlfinding eller revision af applikationsaktiviteten i fremtiden.

Vi er nødt til at bruge et andet alternativ til at tackle denne slags scenarier.

4.1. Indfør validering

En af de nemmeste løsninger er altid validering af input inden logning. Et problem med denne tilgang er, at vi bliver nødt til at validere en masse data ved kørsel, hvilket vil påvirke den samlede systemydelse.

Også, hvis valideringen mislykkes, bliver dataene ikke logget og går tabt for evigt, hvilket ofte ikke er et acceptabelt scenario.

4.2. Databaselogning

En anden mulighed er at logge dataene i databasen. Det er mere sikkert end den anden tilgang siden '\ N' eller newline betyder intet for denne sammenhæng. Dette vil dog skabe endnu en ydeevnehensyn, da et stort antal databaseforbindelser vil blive brugt til logning af brugerdata.

Hvad mere er, denne teknik introducerer en anden sikkerhedssårbarhed - nemlig SQL-injektion. For at tackle dette kan vi ende med at skrive mange ekstra kodelinjer.

4.3. ESAPI

Ved brug af ESAPI er den mest delte og tilrådelige teknik i henhold til denne sammenhæng. Her er hver brugerdata kodet, før de skriver ind i logfilerne. ESAPI er en open source API tilgængelig fra OWASP:

 org.owasp.esapi esapi 2.1.0.1 

Den er tilgængelig i Central Maven Repository.

Vi kan kode dataene ved hjælp af ESAPI'S Koder grænseflade:

offentlig strengkode (streng besked) {besked = besked.placering ('\ n', '_') .placering ('\ r', '_') .placering ('\ t', '_'); besked = ESAPI.encoder (). encodeForHTML (besked); returnere besked; }

Her har vi oprettet en indpakningsmetode, der erstatter alle vognretur og linjefeedninger med understregninger og koder for den ændrede besked.

I det tidligere eksempel, hvis vi koder meddelelsen ved hjælp af denne indpakningsfunktion, skal loggen se sådan ud:

web - 12-04-2017 18: 15: 58,528 [main] INFO com.baeldung.logforging. LogForgingDemo - Beløb krediteret = 300 __web - 2017-04-12 17: 47: 08,957 [main] INFO Beløb tilbageført

Her er det ødelagte strengfragment kodet og kan let identificeres.

Når det er vigtigt at bemærke, er det at bruge ESAPI vi skal medtage ESAPI. Ejendomme fil i klassestien ellers ESAPI API kaster en undtagelse ved kørsel. Det er tilgængeligt her.

5. Konklusion

I denne hurtige vejledning lærte vi om logsmedning og teknikker til at overvinde denne sikkerhedsmæssige bekymring.

Som altid er den fulde kildekode tilgængelig på over på GitHub.