streamalism.org

1. Áttekintés

Ebben a rövid cikkben az egyik leggyakoribb biztonsági kérdést tárjuk fel JVM világ - Rönk kovácsolás. Mutatunk egy olyan technikát is, amely megvédhet minket ettől a biztonsági problémától.

2. Mi a rönkhamisítás?

Alapján OWASP, a rönkhamisítás az egyik leggyakoribb támadási technika.

A naplóhamisítással kapcsolatos biztonsági rések akkor fordulnak elő, amikor az adatok nem megbízható forrásból kerülnek be az alkalmazásba, vagy ha az adatokat valamely külső entitás az alkalmazás / rendszer naplófájljába írja.

Szerint OWASP irányelvek naplóhamisítás vagy beinjekciózás az érvénytelen felhasználói bemenetek naplófájlokba írásának technikája, amely lehetővé teszi, hogy a támadók naplóbejegyzéseket hamisítsanak, vagy rosszindulatú tartalmakat fecskendezhessenek a naplókba.

Egyszerűen fogalmazva: a naplóhamisítással a támadó megpróbálja rekordtartalmat hozzáadni / módosítani az alkalmazás biztonsági réseinek feltárásával.

3. Példa

Vegyünk egy példát, amikor a felhasználó fizetési kérelmet nyújt be az internetről. Az alkalmazás szintjén, miután a kérelmet feldolgoztuk, egy bejegyzést naplózunk az összeggel:

private final Logger logger = LoggerFactory.getLogger (LogForgingDemo.class); public void addLog (Karakterlánc összege) {logger.info ("Hitelesített összeg = {}", összeg); } public static void main (String [] args) {LogForgingDemo demo = új LogForgingDemo (); demo.addLog ("300"); }

Ha megnézzük a konzolt, valami ilyesmit fogunk látni:

web - 2017-04-12 17: 45: 29,978 [main] INFO com.baeldung.logforging.LogForgingDemo - jóváírt összeg = 300

Tegyük fel, hogy egy támadó a bemenetet adja meg „\ N \ nweb - 2017-04-12 17: 47: 08,957 [main] INFO összeg sikeresen megfordítva”, akkor a napló a következő lesz:

web - 2017-04-12 17: 52: 14,124 [main] INFO com.baeldung.logforging. LogForgingDemo - jóváírt összeg = 300 web - 2017-04-12 17: 47: 08,957 [main] INFO összeg sikeresen megfordítva

A támadó szándékosan hamis bejegyzést tudott létrehozni az alkalmazásnaplóban, amely megrongálta a naplók értékét, és a jövőben összezavarja az esetleges audit típusú tevékenységeket. Ez a rönkökovácsolás lényege.

4. Megelőzés

A legkézenfekvőbb megoldás az, hogy nem írunk be felhasználói adatokat naplófájlokba.

De ez nem minden körülmények között lehetséges, mivel a felhasználó által megadott adatok szükségesek az alkalmazás későbbi hibakereséséhez vagy auditálásához.

Valamilyen más alternatívát kell használnunk az ilyen jellegű forgatókönyv kezeléséhez.

4.1. Vezesse be az érvényesítést

Az egyik legegyszerűbb megoldás a bemenet validálása naplózás előtt. Ennek a megközelítésnek az egyik problémája, hogy futás közben sok adatot kell hitelesítenünk, ami hatással lesz a rendszer teljes teljesítményére.

Továbbá, ha az érvényesítés nem sikerül, az adatok nem kerülnek naplózásra, és örökre elvesznek, ami gyakran nem elfogadható forgatókönyv.

4.2. Adatbázis naplózása

Egy másik lehetőség az adatok naplózása az adatbázisba. Ez biztonságosabb, mint a másik megközelítés azóta „\ N” vagy a newline nem jelent semmit ebben a kontextusban. Ez azonban újabb teljesítményproblémákat vet fel, mivel hatalmas számú adatbázis-kapcsolatot fognak felhasználni a felhasználói adatok naplózásához.

Sőt, ez a technika egy újabb biztonsági rést vezet be - mégpedig SQL injekció. Ennek megoldása érdekében végül sok extra kódsort írhatunk.

4.3. ESAPI

Használata ESAPI ebben a kontextusban a leginkább megosztott és ajánlott technika. Itt minden egyes felhasználói adatot kódolunk, mielőtt a naplókba írnánk. ESAPI egy nyílt forráskódú API, amely elérhető OWASP:

 org.owasp.esapi esapi 2.1.0.1 

Ez elérhető a Central Maven Repository-ban.

Az adatokat kódolhatjuk ESAPI’S Encoder felület:

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

Itt létrehoztunk egy burkoló módszert, amely az összes kocsi-visszatérést és sortáblázatot aláhúzással helyettesíti, és kódolja a módosított üzenetet.

A korábbi példában, ha az üzenetet ezzel a burkoló funkcióval kódoljuk, akkor a naplónak ilyennek kell kinéznie:

web - 2017-04-12 18: 15: 58,528 [main] INFO com.baeldung.logforging. LogForgingDemo - jóváírt összeg = 300 __web - 2017-04-12 17: 47: 08,957 [main] INFO összeg sikeresen megfordítva

Itt a sérült sztring töredék kódolva van, és könnyen azonosítható.

Egyszer fontos megjegyezni, hogy használni kell ESAPI be kell vonnunk ESAPI.tulajdonságok fájlt az osztályútvonalon másképp ESAPI Az API futás közben kivételt vet. Itt érhető el.

5. Következtetés

Ebben a gyors bemutatóban megismerkedtünk a rönkök kovácsolásával és a biztonsági aggály leküzdésének technikáival.

Mint mindig, a teljes forráskód is elérhető a GitHubon.