Dolibarr-jogosultságok: a menü elrejtése nem védelem
A jogosultság nem menüpont: négy friss Dolibarr-javítás ugyanazt a tévhitet bontja le
Bérdokumentum, áfafizetés, AJAX-végpont és szállítási API: négy friss javítási javaslat mutatja meg, miért nem elég elrejteni egy gombot vagy menüt az ERP-ben.
2026. szeptember 14-én néhány órán belül több Dolibarr-javítási javaslat is ugyanarra az alapelvre világított rá: attól, hogy egy felhasználó nem lát egy menüpontot vagy gombot, a mögötte lévő adat még nincs feltétlenül megvédve. A hozzáférést ott kell ellenőrizni, ahol a szerver a dokumentumot megnyitja vagy a műveletet végrehajtja.
A cikkben szereplő #40430, #40420, #40415 és #40414 pull request a forrásellenőrzéskor nyitott volt. Ezekből nem következik automatikusan, hogy minden stabil Dolibarr-verzió érintett, és az sem, hogy a javasolt kód változatlanul bekerül egy kiadásba. A pontos érintettséget a telepített verzió és a későbbi biztonsági közlemény alapján kell megállapítani.
Négy ajtó, ugyanaz a kérdés
| Friss javaslat | Védett üzleti terület | A mögöttes kérdés |
|---|---|---|
| #40430 | Bérdokumentumok | A dokumentum lekérésekor is érvényesül-e a megfelelő hozzáférési jog? |
| #40420 | Áfafizetési oldal | A közvetlen URL ugyanúgy védett-e, mint a navigáció? |
| #40415 | Béradatot kiszolgáló AJAX-végpont | Az objektum azonosítója mellett a felhasználó olvasási köre is ellenőrzött-e? |
| #40414 | Rendelésből indított szállítási API | A művelet célja mellett a forrásrendeléshez való hozzáférés is bizonyított-e? |
A négy cím eltérő modulokat érint, mégis egy közös mintát rajzol ki: az ERP-ben nem elég azt kérdezni, hogy „belépett-e a felhasználó?”. Azt is bizonyítani kell, hogy ezt az objektumot, ebben az entitásban, ezzel a művelettel jogosult-e elérni.
A felület nem biztonsági határ
Egy elrejtett menüpont hasznos felhasználói élmény: nem mutat olyan funkciót, amelyet valaki nem használhat. Biztonsági kontrollként azonban kevés. Közvetlen URL, AJAX-kérés, REST API vagy egy integráció ugyanahhoz a szerveroldali művelethez más útvonalon is eljuthat.
Ez az úgynevezett objektumszintű hozzáférés-ellenőrzés lényege. A szerver nem bízhat abban, hogy a kliens csak „megengedett” azonosítót küld. Minden kérésnél újra össze kell kapcsolnia a bejelentkezett identitást, a kért rekordot, az entitást és a szükséges jogosultságot.
Ki kér? Melyik objektumot? Melyik szervezetben vagy entitásban? Mit akar vele tenni? Ha bármelyik kérdés válasza hiányzik, a hozzáférési döntés befejezetlen.
Miért különösen érzékeny ez egy ERP-ben?
Egy ERP nem egyetlen adattípust őriz. Ugyanabban a rendszerben lehet bérinformáció, adófizetés, partnerár, rendelés, szállítás és számla. Ráadásul ugyanaz a munkatárs eltérő szerepeket tölthet be: egy rendelést olvashat, béradatot nem; szállítást készíthet, pénzügyi bizonylatot nem hagyhat jóvá.
Ezért a „modulhoz hozzáfér” gyakran túl durva szabály. A gyakorlatban olvasási, létrehozási, módosítási, törlési és jóváhagyási jogot, külső felhasználói korlátozást, valamint többentitásos adatelválasztást is vizsgálni kell. Egy kapcsolt objektum — például a szállítás forrásrendelése — saját hozzáférési döntést igényelhet.
Hat ellenőrzés, amelyet most is el lehet végezni
- Ne következtessünk érintettségre pusztán a PR címéből. Jegyezzük fel a telepített Dolibarr-verziót és ágat, majd kövessük a javaslatok állapotát és a hivatalos kiadási jegyzeteket.
- Teszteljünk közvetlen URL-lel is. Egy korlátozott szerepkör ne csak a menüben ne lássa az oldalt; a cím megnyitására is szabályos megtagadást kapjon.
- Vizsgáljuk az API-t ugyanazzal a szerepkörrel. A webes felület és az API ne adjon eltérő hozzáférést ugyanahhoz az üzleti objektumhoz.
- Próbáljunk más rekordazonosítót. Saját vagy engedélyezett rekord után egy másik felhasználóhoz, partnerhez vagy entitáshoz tartozó azonosító ne legyen olvasható vagy módosítható.
- Ellenőrizzük a kapcsolt objektumokat. Szállítás, dokumentum vagy számlasor elérésekor a forrásobjektum jogosultsága se maradjon ki.
- Naplózzuk a megtagadást is. A sikertelen hozzáférési próbák segíthetnek hibás integrációt, túl tág kulcsot vagy tényleges visszaélési kísérletet felismerni.
Mit jelent ez az egyedi Dolibarr-moduloknál?
A tanulság nem csak a Dolibarr magjára vonatkozik. Egy egyedi modul minden oldala, letöltése, AJAX-végpontja és REST-metódusa önálló belépési pont. A menü perms feltétele nem helyettesíti a céloldal szerveroldali ellenőrzését; az objektum betöltése pedig nem helyettesíti annak vizsgálatát, hogy a felhasználó az adott rekordot is elérheti-e.
Frissítés előtt ezért a funkcionális teszt mellé negatív jogosultsági teszt is kell: mit nem láthat az értékesítő, a külső partner, a könyvelő vagy egy másik entitás felhasználója? A jó teszt nemcsak azt bizonyítja, hogy a jogosult felhasználó célba ér, hanem azt is, hogy minden más út zárva marad.
Nem a menü, nem a gomb és nem az URL rejti el az adatot. A valódi határ a szerveroldali döntés: az aktuális felhasználó az aktuális objektumon elvégezheti-e az aktuális műveletet.
Források
- Dolibarr – hivatalos pull request lista, a 2026. szeptember 14-én megnyitott javítások állapotának ellenőrzéséhez.
- #40430 – hiányzó hozzáférés-ellenőrzés a bérdokumentumoknál.
- #40420 – hiányzó hozzáférés-ellenőrzés az áfafizetési oldalon.
- #40415 – béradatot érintő AJAX-végpont objektumszintű hozzáférési javítása.
- #40414 – forrásrendelés hozzáférésének ellenőrzése a szállítási API-ban.
- OWASP API Security Top 10 (2023) – az objektumszintű jogosultság-ellenőrzés általános biztonsági háttere.
Forrásállapot: 2026. szeptember 17. A hivatkozott Dolibarr-javaslatok ekkor még nyitott fejlesztések voltak. Telepítési vagy frissítési döntés előtt ellenőrizni kell a célverzió hivatalos kiadását és a javaslatok végleges állapotát.
Nézze meg, milyen Dolibarr-folyamat illeszkedhet a vállalkozásához, vagy küldje el röviden a saját helyzetét.
Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.