Vlákno názorů k článku
Log4j 2.15.0 a 1.x jsou stále zranitelné, aktualizujte na 2.16.0 od hgfdsa - A máme tu Log4j 2.17.0 Jééé. Vianoce. https://logging.apache.org/log4j/2.x/security.html

Co má co společného logování špatného vstupu a ukládání do MDC? Samozřejmě, že každý normální člověk špatný vstup zaloguje, ale nebude ho už cpát do MDC.

Každý normální člověk to nejprve dá do MDC, aby měl všechny následující logovací zprávy svázané s uživatelem. Když používá bezpečnou logovací knihovnu a ne shell, který bokem umí i logovat, nemusí se bát do MDC uložit cokoli. Jakmile to uděláte jinak, musíte složitě řešit pořadí, co kdy validovat a ukládat do MDC – a nejspíš se vám to nepodaří vyřešit správně, což zjistíte, až ty informace z logu budete potřebovat a zjistíte, že tam nejsou.

Tohle je blábol co nedává smysl. Takže mi přijde pokus o smazáni např. celé databáze, pro jednoduchost s basic auth (, kde nesedí username a třeba i password a já si zaloguju, že uživatel jirsak se snažil smazat celou databázi. 1. už by to měl zaříznout nějaký filter nebo tak něco, který to MDC bude plnit a že když to tím filterem neprojde, tak se neplní do MDC úplnými nesmysly (a předpokládám, že ani vy takhovouhle blbost nikde nemáte) 2. ta logováná informace je totálně špatně, protože má úplně nesmyslný context, jelikož to třeba nebyl uživatel jirsak ale poledny. Vůbec netvrdím, že byste se měl bát dávat do MDC cokoliv, ale měli by tam být informace, které jsou buď nějakým způsobem ověřené pokud se jedná o user input nebo informace které nepochází z user inputu, jinak si logujete naprosté nesmysly a vaše logy jsou úplně k ničemu.

Př.:

[jirsak] Invalid login
[] Invalid login with username jirsak

Teď hledejte co všechno dělal uživatel jirsak v logach v prvním případě vidíte, že udělal invalid login, ale to nemusí být vůbec pravda, to nemusel dělat vůbec jirsak.

Jestli ve vašem kódu nejprve zjistíte, že jde o pokus o smazání celé databáze, a teprve pak zjišťujete, jestli sedí jméno a heslo, tak tedy potěš pánbůh. A i kdybyste to dělal takhle nesmyslně a nebezpečně – co je podle vás lepší, mít v logu zprávu, že se neznámý uživatel pokusil smazat celou databázi, nebo je lepší tam mít, že se uživatel, který se sám identifikoval jako jirsak, pokoušel smazat databázi? Nebude náhodou to druhé lepší, protože budete schopen porovnávat různé z logy z různých systémů, odlišit od sebe alespoň některé požadavky apod.?

Do MDC se ukládají údaje, které slouží k identifikaci logovaných zpráv, které nějak patří k sobě. To, jestli ta informace je nebo není pravdivá, se může zjistit až následně při analýze logu.

Jestli ve vašem kódu nejprve zjistíte, že jde o pokus o smazání celé databáze, a teprve pak zjišťujete, jestli sedí jméno a heslo, tak tedy potěš pánbůh.

Laskavě si to přečtěte ještě jednou a nepište tu zase totální nesmysly. Nikde jsem nic takového nepsal.
Ještě jedno pro vás:

https://jirsak:heslo@xyz.com/deletedb

Přijde request na server a server aplikuje nejprve security filter. Uživatel jirsak bud neexistuje nebo nesedí heslo vrací se 401. Zaloguje se, že se někdo pokoušel o přihlášení s uživatelským jménem jirsak a tím to celé hasne. Proč bych proboha měl nastavovat do MDC, že se jedná o uživatele jirsak?
Dle vaší logiky se uživatel jirsak pokoušel zavolat endpoint, ale to vy nevíte, proto nemůžete tvrdit, že se to pokoušel uživatel jirsak, protože uživatel je neznámý.

Do MDC se ukládají údaje, které slouží k identifikaci logovaných zpráv, které nějak patří k sobě. To, jestli ta informace je nebo není pravdivá, se může zjistit až následně při analýze logu.

Omg .Chudáci co to po vás pak musí analyzovat.

20. 12. 2021, 15:18 editováno autorem komentáře

Proč bych proboha měl nastavovat do MDC, že se jedná o uživatele jirsak?
Protože do MDC se nastavují informace, které máte v tu chvíli k dispozici a tušíte, že by se mohly někdy později hodit. Abyste později u každého logovacího příkazu nemusel přemýšlet, jestli tam tahle informace je nebo není potřeba, rovnou ji vložíte všude.

Dle vaší logiky se uživatel jirsak pokoušel zavolat endpoint
Já jsem ale nic takového netvrdil.

Omg .Chudáci co to po vás pak musí analyzovat.
Aspoň je co analyzovat. Po vás není co analyzovat, protože do logu raději nic nezapíšete, aby to náhodou nemohlo být interpretováno špatně.

Aspoň je co analyzovat. Po vás není co analyzovat, protože do logu raději nic nezapíšete, aby to náhodou nemohlo být interpretováno špatně. A to je napsáno kde? Je rozdíl mezi (když máte layout [username] msg):

[jirsak] Invalid login

a

[] Invalid login with username jirsak

To první je nepravdivá informace, která musí být analyzována. U toho druhého nic takového dělat nemusíte. Takže ano není co analyzovat, protože je to jasné na rozdíl od vašeho nesmyslu, kde pak musíte řešit zda to opravdu byl jirsak nebo někdo, kdo se za něho vydával.

20. 12. 2021, 16:10 editováno autorem komentáře

To je ale váš problém, že ta data špatně interpretujete. Špatně můžete interpretovat i ten váš zápis.

Ne to nemůžete špatně interpretovat. Ten váš zápis má, ale dvě interpretace a nemáte šanci poznat, která je správná. Navíc tvrdit, že něco udělal user, který není autentizovaný je úplně mimo.

Oba dva zápisy se dají interpretovat mnoha různými způsoby. Pokud si nejsem jistý, která interpretace je správná, musím se podívat do dokumentace nebo i do zdrojáků.

Navíc tvrdit, že něco udělal user, který není autentizovaný je úplně mimo.
To ale pořád tvrdíte jen vy. Já tvrdím jenom to, že tohle jméno bylo uvedeno jako součást požadavku. To, že to byl opravdu daný uživatel, je jenom vaše interpretace.

Ne jenom ten váš se dá interpretovat mnoha způsoby a musí být následně analyzováno zda ty informace jsou pravdivé.

To ale pořád tvrdíte jen vy. Já tvrdím jenom to, že tohle jméno bylo uvedeno jako součást požadavku. To, že to byl opravdu daný uživatel, je jenom vaše interpretace.
Ne to je normální praxe. Pokud to děláte jinak, tak je to váš problém a zaděláváte si tím do budoucna, protože to někdo nezná a může to špatně interpretovat. Vezmu si napomoc třeba Spring Security (ale je to obecně všude obdobné Jakarta EE, Micronaut atp.), přece když je uživatel nevalidní/neau­tentikovaný, tak se vám nevytvoří security context s nevalidním uživatelem tj. nenaplní se vám SecurityContext abyste pak dále mohl s tímto contextem dále pracovat a prohlašovat, že to dělá tenhle uživatel. Nedělá se to už jenom z toho důvodu, že to může někdo špatně interpretovat. Co by vás možná mohlo trknout je tenhle log, který je totální nesmysl:

[jirsak] /deletedb - 401 Unauthorized

vs

[] /deletedb - 401 Unauthorized

Teď jistě namítnete, že to nemáte jak poznat, k čemu to patří, ale to je zase úplně jiná debata o tracing.

21. 12. 2021, 11:17 editováno autorem komentáře

Saljack: To, že vy něco děláte špatně, vážně nedokazuje, že to tak musí dělat všichni. Já nevidím nic špatného na tom, že do kontextu vložím nejprve třeba UsernameFromHTTPRe­quest a když uživatele ověřím, tohle z kontextu vyhodím a přidám tam Username. Že vy jste si usmyslel, že neověřené a ověřené uživatelské jméno musí být v kontextu pod jedním klíčem, to je váš problém.