- Megrendszabályozza a Pornhubot az EU
- ASUS routerek
- Nagyon gyorsan betilthatja az EU a TikTok újítását
- Bittorrent topik
- Hálózati / IP kamera
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Xiaomi AX3600 WiFi 6 AIoT Router
- Olcsóbb lett a Tesla Full Self-Driving szoftvere
- Windows 10
- SkyShowtime
Új hozzászólás Aktív témák
-
Hiftu
senior tag
Lassan a Sony is kénytelen lesz elgondolkodni, hogy a 21. században használjon 21. századi adatbiztonsági megoldásokat.
(Ennek az egyik legegyszerűbb formája az központilag vezérelt automatizált frissítések bevezetése.)
Esetleg a rendszereinek biztonsági auditálása is szóba jöhetne már.Tessék mondani, lehet itt hazudni? - Kaszt: Decker, Faj: Troll, Működési Terület: Prohardver
-
Angel1981
veterán
Rájuk jár a rúd mostanában...
-
Geller72
veterán
válasz Realradical #49 üzenetére
Szerettem volna bekerülni, nem nem lehetett...
-Tényleg, ilyen helyen nincs időközönkénti külsős audit?
[ Szerkesztve ]
-
Realradical
őstag
Ehh, hát igen király élet lehet, főleg, ha meg is vannak becsülve. (rosszul érintene, ha felém hajítaná egy külsős a kocsikulcsot, hogy parkoljak be vele neki valahová és két cukorral kéri)
Illene lennie. Bár a saját tapasztalatom, hogy külsős secus cégek meg szeretnek hagyni mindig a következő auditra is valamit amit leírhatnak, hogy szükség legyen rájuk x idő múlva is.
Things that try to look like things often do look more like things than things
-
intercooler
őstag
Hát ez gyönyörű, ekkora cégnél ennyire nem ügyelnek a biztonságra grat
Van olyan sejtésem hogy lesznek még támadások ha ilyen "könnyű" betörni
-
csongi
veterán
A cég szerint az adatok elérhetőek voltak a weboldalon... Hát persze hogy el, hiszen feltörték azt. És még szinkronizáljam a telefonkönyvem az interneten. Hát persze, hogyne ,naponta többször is
-
talpalavalo
aktív tag
Igen engem is az utolsó sorok fogtak meg, hogy a weboldalon egyébként is elérhetőek, hát akkor könyörgöm, ha a weboldalon tök simán bárki elérheti, akkor meg pláne lehúzhatják magukat meg milyen oldal már ha csak úgy elérhető mindenkinek a számom email címem, stb....
Olyan mintha ellopják az autómat mert nem zártam be az ajtaját és benne volt vagy ezer ember fizetése, majd azzal védekezek, hogy egyébként is mindig nyitva van az ablak tehát eddig is bárki simán elvehette volna, nincs ebben semmi... Szánalmas... Meg kell tanulnom ezt az SQL injection-t
-
nagyúr
"mert primitív eszközökkel dolgoznak primitív programozók. String összefűzéssel nem szabad SQL mondatokat kreálni. Kész."
Vagy csak simán mindenki szart bele, mert a Sony tejelte a pénzt és onnantól a munka másodlagos, hogy fizettek. Vajon mennyi support díjat kérhettek egy ilyen hulladék rendszerért? És vajon mennyit fognak most kártérítés formájában visszakérni a Sony-nál? Már ha nem szűnt meg jó szokás szerint a szoftvergyártó. A Sony helyében közzé is tenném pirossal a beszállító cég nevét.
Egy ilyen hibát valószínűleg valami generált szarral tudtak előadni, főleg ennyi rendszernél, ami viszont mindent megmutat a hozzáállásról. Ez az ügy azért is nagyon bosszantó, mert a programozókat már általánosítani kezdik.
[ Szerkesztve ]
-
julius666
addikt
Nem igazán. Hiába próbálod mondjuk regexp-el a mókás dolgokat kiszűrni, úgyis lesz valami olyasmi amiről nem tudsz te de a támadó igen. Paraméteres lekérdezés oszt' jónapot, semmivel sem bonyolultabb mint a buzi string összefűzés, viszont az adatbázis-kezelő rendszer készítőiben azért általában meg lehet bízni. Nekik valószínűleg valamivel magasabb a szaktudásuk mint mint az OKJ-s webprogramász jóskapistának.
-
Ribi
nagyúr
válasz julius666 #61 üzenetére
Viszonylag sok olyan tuzfal van amiben meg lehet adni, hogy egyaltalan milyen formátumú dolgokat engedjen tovább. Ha attól különbözik alapdól dobja is el. Nem bonyolult szerintem.
Tipikusan az ilyen SQL inj ellen vannak ezek is. (Web application firewall)[ Szerkesztve ]
-
kokyt
senior tag
válasz julius666 #61 üzenetére
"Hiába próbálod mondjuk regexp-el a mókás dolgokat kiszűrni, úgyis lesz valami olyasmi amiről nem tudsz te de a támadó igen."
Quota-zással minden megoldható Nem azt mondtam, hogy szép, és azt sem, hogy ezt kell használni, csak azt hogy nem lehetetlen.
"Paraméteres lekérdezés oszt' jónapot"
Ha paraméteres lekérdezés alatt a tárolt eljárás paraméterekkel való meghívását érted, akkor abban az esetben is el kell végezni a szűréseket. Abban igazad van, hogy nem bonyolultabb, de biztonságosabbnak sem sokkal biztonságosabb.
"viszont az adatbázis-kezelő rendszer készítőiben azért általában meg lehet bízni."
Én nem tenném Az egyáltalán nem baj (sőt!!!), ha saját kódolású védelmet a fejlesztő is használ, és nem támaszkodik csak a db handler-re.
stevve:
Az attól függ. Ha szerver oldalon állítja össze a lekérdezést, az nem akkora baj, ha kliens oldalon, majd azt küldi el, akkor az viszont ordas nagy. A tárolt eljárás minden szempontból praktikusabb, de ekkor is átcsúszhatnak dolgok, a különbség annyi, hogy ez esetben db oldalon folyik a string build.[ Szerkesztve ]
-
ddekany
veterán
Na, hát itt a baj. Nincs a helyes szemlélet meggyökeresedve... annyira, hogy sok környezetben még a könyvtárak sem támogatják. A dolognak valahogy így kéne kinéznie, vagy hát minimum így (pszeudo kód): rs = querty("SELECT name, price FROM products WHERE on_stock = ? AND price <= ? AND name LIKE ?", onStock, maxPrice, searchPattern); Sehol nem foglalkoztam itt vele, hogy mi SQL-ben a szintaxis. Majd a funkció megnézi milyen típusúak az értékek, aztán csinál vele amit kell. Kényelmesebb és biztonságosabb. Mindez nem keverendő a prepared statement-ekkel vagy a tárolt eljárásokkal. (És ez még egy primitív megoldás volt, mert volt benne SQL mint string, helyett hogy a fő programozási nyelven belül definiált DSL-el lenne az egész megoldva...)
-
ddekany
veterán
"Viszonylag sok olyan tuzfal van amiben meg lehet adni, hogy egyaltalan milyen formátumú dolgokat engedjen tovább"
+1 védelmi vonalnak talán elmegy, de gány megoldás, és adott esetben elgáncsolhat olyan kérelmeket amik teljesen helyénvalóak voltak... És semmi esetre sem ez kéne legyen a fő védelmi vonal.
-
julius666
addikt
Én nem tenném Az egyáltalán nem baj (sőt!!!), ha saját kódolású védelmet a fejlesztő is használ, és nem támaszkodik csak a db handler-re.
Az hogy egy saját védvonalat is beépítesz az persze nem árt, te dolgod, te költséged. Viszont az az alap, hogy ha lekérdezés kell akkor az paraméteres lekérdezés és nem string összefűzés. Ha az adott programozó (bocsánat, programász) nem úgy csinálja, egyszerűen ki kell rúgni. Bármilyen (normális) adatbázis-kezelős kurzuson kb. ezzel kezdenek, nem igaz hogy még mind a mai napig ennyien nem képesek normálisan használni.
ddekany a többit jól leírta.
-
orbano
félisten
válasz Jim Tonic #36 üzenetére
jó értem. Mondjuk inkább a fejétől bűzlik itt a baj, valaki nagyon elfelejtett az első tucat után szólni az illetékeseknek, hogy rakjanak rendet. Már a másodiknál iszonyatos fejhullásoknak kellett volna lenniük. Ok, nagy infrastruktúra, meg minden, de azért érdemes ilyenkor már egy belső átvizsgálást lenyomni valami komolyabb külső szakértővel.
A vér nem válik VAZZE!™
-
kokyt
senior tag
Numerikus érték esetén egyértelmű a típusellenőrzéssel való védekezés Én kifejezetten login felületen történő sql injection-re gondoltam, ott többnyire csak string-ek jöhetnek szóba. Oda azért nem árt egy plusz quota-zás.
Abból kiindulva, hogy az ilyen védelem hiánya még mindig az egyik leggyakoribb hiba a netes rendszerekben, szerintem a sony nem is itt hibázta a legnagyobbat, hanem a titkosítás nélküli jelszó tárolásnál. Ez azért simán megérné a diplomák visszavételét, és a felelősök névlistájának közzétételét.julius666:
"Az hogy egy saját védvonalat is beépítesz az persze nem árt, te dolgod, te költséged. Viszont az az alap, hogy ha lekérdezés kell akkor az paraméteres lekérdezés és nem string összefűzés."Látom nem ment át neked, hogy a paraméteres lekérdezés önmagában még nem minden esetben véd. String átcsúszhat, ezért kellhet a plusz védelem, amivel pont azért érdemes foglalkozni, hogy egy támadás másnapján is legyen hova visszamenni dolgozni Egyébként teljesen igazad van, valóban így kellene mindenkinek használnia
-
ddekany
veterán
De az általam mutatott módszer string-ek esetén is véd, sőt az a lényege. Tehát ott LIKE után a ? helyére idézőjeles és rendesen escape-elt string kerül, csak soha sem látod. (Ill. az is lehet, hogy soha nem is lesz szöveges behelyettesítés, de ez már az adatbázis kliens API-ján múlik és technikai részlet.)
-
nagyúr
Nem is tudom, mikor fordultam programból SQL-lel adatbázishoz utoljára. Tárolt eljárást is már egy éve nem írtam és hívtam direktben. NHibernate, EF4, NoSql, stb.
Olyan perzisztáló réteget kell (enterprise szinten ez volna szerintem a kötelező) építeni, ami felfelé mindent elfed, ergo még esély sincs arra, hogy manipulálhassanak vele. Minden entitás jól definiált, webes felületen pedig a view olyan buta legyen, amennyire csak lehet.
-
kokyt
senior tag
Egy tisztességesen megtervezett és kivitelezett webservice réteg ezt el is végzi. De tovább megyek kicsit, ahol annyi és olyan érzékeny adatot tárolnak mint a sony-nál, ott alapnak kellene lennie a nagyon erős authentikációs mechanizmusnak, a titkosított kommunikációnak, és az említett service rétegnek is hozzáférés-vezéreltnek kell lennie. Erre ezek a majmok (bocs, de finomabban nem megy) még a jelszavakat is plain tárolják Így jobban belegondolva, meg is érdemlik, amit kaptak az elmúlt hónapokban