Hogyan védjem meg a portálomat?
 Sziasztok!
Készítettem egy portált J2EE-ben, és az lenne a kérdésem, hogy milyen lépéseket kell tennem, hogy 'teljesen' biztosnágos legyen?
Én fejlesztő vagyok, a Tűzfalakkal, mások foglalkoznak, tehát első sorban a fejlesztéssel kapcsolatban szeretnék tanácsot kérni.
(Oracle adatbázist használunk linux alatt GlassFish az application server...)
ami a kockázatosabb rész lehet:
* Fájl feltöltés (képek és pdf lehet | csak a kiterjesztést vizsgálom)
* különb.. |
Pl. azt, hogy URL-ben tárolod a session-azonosítót süti helyett. Süti esetében ugyanis az említett hiba nem okozott volna problémát, mert a süti magától is lejárt volna, ráadásul onnan nem olyan egyszerű kivadászni a session-azonosítót, mint az URL-ből, amit ráadásul pl. a böngésző előzményeiből úgy lehet előhívni, hogy nem is kell különösebben bányászni utána (tehát még az egybites júzer is képes rá).
Ezen kívül a sessionben (session tömbben vagy a sessionhöz kapcsolódó perzisztens containerben) magában nem szabad semmilyen olyan adatot tárolni, ami változhat a session során (az oldalletöltések között), beleértve a felhasználó jogait (vagy egyáltalán hozzáférési jogosultságát a rendszerhez) sem, hanem ezeket minden egyes oldalletöltéskor újból be kell tölteni az adatbázisból. Itt annyi engedhető meg maximum, hogy teljesítményokokból pl. ugyan tárolható ez az információ informatív jelleggel, és mondjuk a menü felépítésénél felhasználható, de a konkrét műveletek elvégzése előtt - különös tekintettel a POST oldallekérésekre, amik általában magát a végrehajtást takarják - mindig rá kell ellenőrizni ezekre az adatokra az élő, kurrens adatbázis alapján (ti. hogy rendelkezik -e a felhasználó a megfelelő jogokkal). Egyéb esetben könnyen előfordulhat, hogy a felhasználó elméletileg elveszti a jogait (pl. mert lejár az előfizetése, hozzáférése), de a session mesterséges nyitvatartásával - ha annak életére pl. nincs felső korlát meghatározva - akár még hónapok múlva is hozzáférhet a rendszerhez, olyan jogokkal, amik már rég megvonásra kerültek tőle.
Ezen kívül a sesssion információkat mindig szerveroldalon kell tárolni, nem szabad pl. a <form> részeként, rejtett mezőben ide-oda futtatni sem, hiszen az rendkívül könnyen manipulálhatóvá teszi azt. (Szokás még olyan megoldást alkalmazni, hogy valami egyedi salttal kódolva ill. checksummolva mégis a form adatok részeként tartják nyilván és küldözgetik a session információkat, de ez is elméletileg sebezhető - szemben a szerveroldali tárolással, ami by design manipulálhatatlan -, és egyébként is belassíthatja a kommunikációt ha sok adatot kell ide-oda küldözgetni így minden egyes oldalletöltéskor az oldal ill. visszafelé a form-adatok részeként.)  |
Én egyszer belefutottam abba, hogy kijelentkezéskor nem invalidáltam megfelelően a sessiont, így ha késöbb visszaírta az url-t akkor le lehetett halászni az adatokat.
Milyen hibákat lehet még elkövetni tervezéskor?
|
Kezded kapiskálni  |
hűűha háát szerintem te zseniális vagy... Nagyün ügyes... De tényleg...
Olyannyira, hogy neked sztem nincs is szükséged rá, hogy ezt a fórumot használd! |
Háát igen ezt én is igy tanultam az iskolában..
Csak sajnos a való életben általában úgy van, hogy bejön a megrendelés, aminek tegnapra kész kell lennie, majd ha van idő akkor foglalkozok a részletekkel is...
(Na jó, azért most egy kicsit túloztam, vannak olyan technikáink, amiket mindig alkalmazunk biztonság téren...
(sql injectionnal pl nem lehet matatni...)
Ebben a kérdésben igazábol össze szerettem volna gyűjteni, hogy milyen kockázati tényezők lehetnek egy portálnál.
) |
@google:
java/j2ee develop secure web application
Nem tudom mi ebben a nehéz, csak én tudom használni a googlet??? |
"Készítettem egy portált J2EE-ben"
Bocsi, hogy nem lesz túl hasznos a hozzászólásom, de ez a mondat egyből megütötte a szemem, mivel rossz a sorrend.
Előbb megtervezem a különböző igények, paraméterek figyelembevételével (ilyen a biztonság is), majd a tervek alapján elkészítem. Az előbb elkészítem, aztán majd beletervezem a biztonságot elég reménytelennek tűnik nekem. |
| beszorult az ujjad? :D |
| jspaartaaaaaaaaaaaaaaaaaaaaaaaa |
Én alapvetően nem aggódnék, azért használnak Java-t a biztonságot igénylő helyeken (banki környezetben például szinte csak Java fordul elő), mivel kifejezetten erőlködni kell ahhoz, hogy nagyobb biztonsági lyukak keletkezzenek rajta.
Hát én meg elég paranoid módon állok a biztonsághoz, lehet én teszem rosszul?  |
Én alapvetően nem aggódnék, azért használnak Java-t a biztonságot igénylő helyeken (banki környezetben például szinte csak Java fordul elő), mivel kifejezetten erőlködni kell ahhoz, hogy nagyobb biztonsági lyukak keletkezzenek rajta.
Szerintem abszolút nem ezért használnak, hanem mert
- többplatformos (ti. a Java alkalmazásszerver sok operációs rendszeren futtatható, Windows-tól nagygépig),
- jól illeszthető a tipikus vállalati rendszerekhez (ti. mert megvannak a magasszintű adatbáziskonnektorok, könnyű webszolgáltatások írása és hívása, stb.),
- konzisztens és átfogó alap- (vagy legalábbis standard-)könyvtárkészlettel rendelkezik, amik mind elősegítik az elkészült programok későbbi karbantartását (szemben a C++, PHP, Perl, stb. kódokkal, amelyekhez ahány fejlesztő, annyiféle könyvtárat használ ugyanarra a feladatra, ami nagy ill. hosszú távú fejlesztéseknél hátrány, hiszen az eredeti fejlesztők defektálása esetén nehéz ugyanazzal a skillkészlettel rendelkező másik munkaerőt találni, vagy akár csapatan belül másnak átadni a kód továbbfejlesztésének feladatát).
Biztonsági szempontból amúgy Java-ban és éppen olyan nehéz, vagy könnyű biztonsági rést nyitni, mint pl. PHP-ben, vagy akármilyen másik virtuális gépben futó és/vagy interpretált nyelvben. Ezekben ugyan a puffertúlcsordulásból adódó biztonsági rések keletkezése szinte kizárt (a nyelv szerkezetéből és a futtatás módjából adódóan), ugyanakkor SQL injekcióval, XSS-sel, stb. szemben a Java éppen úgy sebezhető, mint a PHP, C, Delphi, Perl és szinte akármilyen másik nyelv.
A másik oldalon a PHP alapvetően semmivel sem rosszabb biztonsági szempontból, mint akármelyik másik nyelv (sőt, C/C++/Delphi-nél tuti jobb), csak éppen azon programozók nagy részének, akik ezen a platformon fejlesztenek, fingjuk sincs a biztonságról, és ezért nyitnak ill. hagynak praktikusan tervezési biztonsági réseket az alkalmazáson (lásd az előző példát ahol az SQL lekérdezést sztringkonkatenációval állítják elő a normális, paraméteres megoldás helyett). De ez nem a platform, vagy a nyelv hibája, hanem a programozóé (ill. aki annak csúfolja magát). |
amiket olvastam a neten, azok alapján úgy nézki, hogy az MS-es adatbázisok, a Firebird, és a MYSQL van kitéve inkább ennek a veszélynek...
Az hogy a fejlesztő így
sql="insert into tábla (...) values (" + mező1 + ", " + mező2 + ")"
ezt ha nagyon akarom Oracle alatt is megtehetem... |
php strip_tags()
Hm... úgy vettem észre Java-ról van szó.
Namost a Java (JDBC esetén PreparedStatement esetén, de főleg a JPA használatával) by design védett olyasmi ellen, amiről egész eddig beszéltetek PHP tudással átérezve a helyzetet.
Ha nincs szükség valamilyen HTML editorra (CKEditor, stb) a felületen, akkor az XSS is elég könnyen lerendezhető.
Én alapvetően nem aggódnék, azért használnak Java-t a biztonságot igénylő helyeken (banki környezetben például szinte csak Java fordul elő), mivel kifejezetten erőlködni kell ahhoz, hogy nagyobb biztonsági lyukak keletkezzenek rajta.
--
http://www.javaforum.hu |
Nost úgy nézki, hogy a html injectionnal nincs probléma, mivel a glasfish lefordítja a < > jeleket a html nevére...
a oracle meg a paramétereket változóként kezeli...
tehát nem dolgozza fel őket.
Mi tárolt eljárásokat használunk selectet kódbol sosem írok, tehát ha vki ugy csinálja, akkor azt lehet ki kell védeni. (bár sztem ezt is megoldja az oracle...)
amiket olvastam a neten, azok alapján úgy nézki, hogy az MS-es adatbázisok, a Firebird, és a MYSQL van kitéve inkább ennek a veszélynek...
|
Néhány ötlet sql szempontból:
1.) Egy külön user az adatbázisban, akinek csak az adott táblákra van insert, update, delete, select joga, ami kell, semmi több.
2.) A tábláknak olyan nevet adni, amiket jó eséllyel nem fognak beírni az inputokba. Pl: tbl_user, tbl_jogok, stb, amit persze szívesen használunk így  És ezeket kiszűrni bevitelkor. Úgy gondolom ez elég sok lehetőséget ki fog zárni sql szinten.
3.) Ha megtalálod valahol a mysql_real_escape_string működését, annak a mintájára is készíthetsz egy ellenőrzést. |
Az előttem szólókhoz csatlakozva
mezők ellenőrzése!
Halivud Estevez válasza
; drop table users nagyon ütős volt 
php strip_tags() ajánlott a szövegeknél
én a feltöltésnél nem csak a kiterjesztést ellenőrizném
képekre ráküldenék valami képkezelő php függvényt, pl a Width Height méret lekérdezést, hogy érvényes-e a és nem 0x0-ás 
pdf-nél beleolvasnák, hogy '%PDF'-el kezdődik-e? |
| az elég, ha kiszedem az aposztrófot, megg a "< >"-t? |
vagy ha a jelszó mezőben megadhatóm majd sql-be belebele:
'; drop table users |
A következő kódsorozat bevitele, elmentése, majd mondjuk fórum hozzászólásban óvatlan visszaírása kockázatos:
"><script src="http://255.255.255.255/kulsoscript.js"></script>
|
| HTML injection... |
"scriptek bevitelének tiltása/kikerülése " ez alatt mit értesz?
|
| Szia, csak egy alapszintű gondolat, és remélem, hogy csak felesleges aggodalom lesz, de azért elég sokan elfeledkeznek róla, hogy a beviteli mezők tartalmát sosem írjuk be direkt az adatbázisba. Minden esetben megvizsgáljuk, hogy megfelel-e annak a típusnak, amit várunk. (pl. szám esetén tényleg szám-e). Javasolt még a scriptek bevitelének tiltása/kikerülése is. |
Sziasztok!
Készítettem egy portált J2EE-ben, és az lenne a kérdésem, hogy milyen lépéseket kell tennem, hogy 'teljesen' biztosnágos legyen?
Én fejlesztő vagyok, a Tűzfalakkal, mások foglalkoznak, tehát első sorban a fejlesztéssel kapcsolatban szeretnék tanácsot kérni.
(Oracle adatbázist használunk linux alatt GlassFish az application server...)
ami a kockázatosabb rész lehet:
* Fájl feltöltés (képek és pdf lehet | csak a kiterjesztést vizsgálom)
* különböző beviteli mezők, aminek az adatai oracle-ben vannak tárolva.
Fájl feltöltésnél van vírusellenőrzés (Norton)
Köszönöm előre is |
|
