Amiből sosem elég, avagy alapvető biztonsági kérdések Laravel applikációkban

Amiből sosem elég, avagy alapvető biztonsági kérdések Laravel applikációkban

Ez az a téma, amiről nem lehet eleget beszélni, sőt nemcsak beszélni kell róla, hanem tenni is érte.

A fejlesztők között sokszor szóba kerül a rendszerbiztonság kérdése és általában ki is merül abban, hogy „Persze, persze, biztonságos...”. Azok a kérdések nagyon ritkán merülnek fel, amelyek valóban fontosak lennének az oldalunk, rendszerünk védelmében. Ilyenek például a „Milyen támadási módok léteznek?” vagy a „Mit tehetünk ellene?”.

Először foglalkozzunk a támadási módok kérdésével. Sajnos ezekből sokféle létezik, és ebben a cikkben a terjedelmi korlátok miatt csak a legfontosabbakat vehetjük górcső alá.

  • SQL Injection: Talán az egyik legveszélyesebb és legkönnyebb támadási mód. Nem szükséges hozzá komolyabb tudás, és óriási károkat tud okozni. Ennek a lényege, hogy a támadó SQL kódot illeszt be egy beviteli mezőbe, majd az szépen lefut az adatbázisban, amennyiben nem védekezünk ellene.
  • Object Injection: Ez egy kevésbé ismert támadás, amelynek lényege, hogy a PHP objektumoknak vannak automatikusan lefutó metódusai. Ezt kihasználva a támadó futtathat veszélyes kódokat a szerverünkön. Ezeket a metódusokat „Gadget”-nek nevezzük.
  • Ha a fenti támadás sikeres, akkor sajnos akár hozzáférhetnek a szerverünkhöz is, és ott egy terminált is indíthatnak. A terminálon keresztül elérhetnek a rendszer szempontjából kritikus funkciókat, kódokat, scripteket, mint például automatizált munkafolyamatokat. Ha ezeket ráadásul adminisztrátorként futtatjuk, akkor akár teljes hozzáférést is tudnak szerezni a szerverhez.

A jó hír, hogy ezeknek a sebezhetőségeknek az elkerülésére elegendő pár szabályt betartanunk:

  • Soha ne bízzunk meg a felhasználó által bevitt adatokban. Soha. Tisztítsuk meg és ellenőrizzük a bevitt értékeket.
  • Soha ne futtassunk nyers adatbázis lekérdezéseket. Használjunk MySQL változókat, és ha keretrendszerben dolgozunk, akkor használjuk annak beépített lekéréseit, amennyiben rendelkezik a támadások elleni beépített védelemmel.
  • Egy-egy sebezhetőség felfedezése után, az esetek többségében pár napon belül, javításokat adnak ki a szerveren futó csomagokhoz, applikációkhoz. Frissítsük a csomagokat és nézzük át a saját kódunkat is.
  • Lehetőleg csak azt futtassuk a szerveren adminisztrátorként, amit semmiképpen nem lehet más módon megoldani.
  • Kerüljük a lustaságot. Sok hiba és sebezhetőség tárul fel, amikor a fejlesztő nem veszi a fáradtságot egy adott szerver vagy applikáció beállításainak helyes elvégzésére, vagy nem ellenőrzi a kódját, nem teszteli a működést minden oldalról. Mondják, hogy a „Lustaság fél egészség”, azonban nem a rendszerünk számára.

A legtöbb esetben nem foglalkozunk ezekkel a kérdésekkel, mert vagy nincs idő rá, vagy abba az álomképbe ringatjuk magunkat, hogy úgysem történhet baj, eddig sem történt, ezután sem fog. Amikor mégis bekövetkezik az elképzelhetetlen, a megoldás minden esetben jóval megterhelőbb lesz, mind anyagi, mind professzionális szempontból, mintha már eredetileg is a megelőzést alkalmaztuk volna.

Itt egy idevágó előadás a 2019-es nyári Laracon Europe konferenciáról, ahol bemutatják, hogy mit is tehetnek a támadók, ha nem tartjuk be az alapszabályokat: Link

Amennyiben nem biztos benne, hogy rendszere biztonságos, keressen minket bizalommal a contact@nevis.hu címen, egy rövid, ingyenes tanácsadásra.