Új hozzászólás Aktív témák
-
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 
-
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.
-
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.)
-
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 -
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. -
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.
-
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.
-
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...)
-
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. -
-
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.
-
"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.
-
#58
talpalavalo
aktív tag
csongi
#57
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
-
#56
intercooler
őstag
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
-
#54
Realradical
őstag
Geller72
#53
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.
-
#53
Geller72
veterán
Realradical
#49
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?
-
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. -
Geller72
veterán
Előző cégemnél a rendszergazda jogosultsága nagyjából kimerült abban, hogy ha valami gáz volt, akkor elővette a kis telláját és hívta a megfelelő számot. Aztán a szerződött partner szépen kiballagott és megoldotta a problémát. Az admin meg kinyitotta a szobát és alátolt egy széket, aztán együtt jártak kávézni.
-
ddekany
veterán
"E bejegyzésből kiderül, hogy a Sony Europe is plain text módon, vagyis titkosítás nélkül tárolta a személyes adatokat."
Feltételezem itt csak a jelszavakra gondolt az illető... többit nincs sok értelme titkosítva tárolni, már olyan értelemben titkosítva, hogy egy SQL lekérdezés ne adja őket vissza.
Amúgy, SQL injection... mert primitív eszközökkel dolgoznak primitív programozók. String összefűzéssel nem szabad SQL mondatokat kreálni. Kész. És mégis, csak példának, és ha jól tudom a legelterjedtebb PHP-s adatbázis kezelő könyvárak csak ezt a dilettáns string összefűző módszert támogatják. (OK, mysqli kivétel, arra emlékszek... de nem (volt?) elterjedt a szokványos olcsó webhelyeken.)
-
#45
Realradical
őstag
Jim Tonic
#43
Realradical
őstag
válasz
Jim Tonic
#43
üzenetére
Nem arra értettem a leállásos dolgot, hogy a Sony helyében miután 12 szervert megtörnek, utána egy maintenance keretében történő foltozás miatt lelőni a szervert x időre. Amit most csinálnak az egy komoly autista hozzáállás...
Az általánosító kijelentésedre írtam, hogy a rendszergazda lője le a szervert ha észleli, hogy lehet sz@r repült a ventillátorba.
-
rt06
veterán
válasz
Jim Tonic
#41
üzenetére
orulok, hogy tisztaban vagy vele, mert pont nem bekostolas volt - igazabol teszek rad magasrol -, viszont ez egy visszatero hiba (s mint lathatod, nem csak nekem van vele problemam, biztos mindenki teged kostolgat), miszerint a programozok ezen hibai miatt rendszeresen a rendszergazdakat akarjak kikezdeni
olyan aprosagokrol szoktak csak megfeledkezni, hogy:
- a rendszergazda tobbnyire hozza sem fer a forraskodhoz, hogy javitani tudja annak hibait
- ha hozzaferne sem biztos, hogy atlatja annyira a rendszert, hogy tovabbi komolyabb gondok nelkul tudja azt javitani
- ha a rendszergazda csakugy lekapcsolja a rendszert, lehet ugy b*sszak meg, hogy egy hetig nem fog tudni leulni, ugyanis jellemzoen a donteshozot meg akkor sem feltetlen erdekli a sebezhetoseg, miutan azt mar kihasznaltak egyszer/tobbszor, sokkal fontosabb a szolgaltatas folyamatos elerhetosegep.s.: te amugy lathatoan legalabb annyira elvezed, mint azt rolam hiszed, mert szemelyeskedessel kezdtel, azzal folytattad, es most, mikor hozol par ervet is vegre, meg mindig nem tudsz elszakadni tole
-
#43
Jim Tonic
nagyúr
Realradical
#42
válasz
Realradical
#42
üzenetére
Nem akarok vitázni az elírásomon, elismerem. Kifejtettem, mi volt az oka.
Egy önkormányzatnál csak a rendszergazdának vannak ilyen felelősségei, a polgármester nem fog tudni hozzászólni.
De mondom, ebben nem akarok vitázni, nagyobb méretekben nyilván százszor jobban tudjátok, mint én.Milyen gyanú miatt? 12 szerver feltörése korábban SQL-injecttel az gyanú? Na neee....
-
#42
Realradical
őstag
Jim Tonic
#30
Realradical
őstag
válasz
Jim Tonic
#30
üzenetére
A programozó és a rendszergazda között nagy különbség van. Az, hogy DBA-ként rálátok és esetleg rá is mutatok bizonyos sebezhetőségekre, attól még nem rajtam múlik azok megoldása/javítása. Durva tévedés volt a rendszergazdás dolog (az ember védi a mundér becsületét). Szerintem ne erőltesd a vitát, vonj inkább vállat aztán legközelebb jól írod, ennyi.
Leállítani a szervert éles környezetben egy esetleges gyanú miatt? Az minimum fegyelmi. Nem így működnek a nagyobb cégek.
A Sony-n már mosolyogni se nagyon tudok, tényleg nem értem milyen szakembereket alkalmaznak...
-
Beismertem, ki is javítottam. Abból az egyszerű okból volt az elírás, hogy én kisebb méretekben gondolkodom, és pl. a kollégáim, akik önkormányzatoknál rendszergazdák, egyúttal felelősek a biztonságért is. Ha tudják, hogy hasonló rés van az adott szerveren, akkor lezárják az oldalt/szervert, de akár bele is kell javítaniuk a kódba.
Ezzel együtt (ismerve a régi nickedet is) már tisztában, hogy az egy bekóstolás volt, aminek mindenképp a levesembe szarás lett volna a vége.
Ha nem így lenne, most nem kezdenél ennyire belelendülni. Valljuk be, Te ezt élvezed. Nekem meg nem hiányzik. -
buzus
aktív tag
Én másképp gondolkozom. Nem hiszem hogy ez az egész, pár a Sony céggel nem szimpatizáló hacker miatt van. Ha ez így működne hogy "Te, nekem ezeknek nem tetszik az üzletpolitikájuk, most jól meghackelem őket", akkor már a többi nagyvállalatot is megszivatták volna, mert semmivel se roszabb az üzletpolitikájuk mint a Sonyé. Vegyük a mobiltelefon gyártókat, Samsung, LG, HTC, Apple akik a telefont keleten gyártják le 5-10$ anyagköltséggel és 200-500$ ért adják el a világon. Akkor holvan ehez képest a Sony uraim. Szerintem ez szervezett lejárató kampány, ami sok konkurens cégnek lehet az érdeke és erre jött rá a "hype", hogy ha most minden hacker utálja a Sonyt, akkor pistike is megpróbál jelszót lopni tőlök otthonról hogy megmutassa mekkora császár.
-
rt06
veterán
válasz
Jim Tonic
#38
üzenetére
es megelozo jelleggel meg lejjebb sullyedtel? merthogy egy szakmailag pontatlan megszolalas miatt vontalak kerdore, s erre szemelyeskedest kaptam
aztan mikor mas is kerdore vont pontatlansagaid miatt, megintcsak en kaptam szemelyeskedestezek utan imho ez nem VladimirR szintu vita, hanem Jim Tonic szintu hiszti (persze ertem en, biztos sokkal jobb lehet azt leirni, hogy VladimirR egy *****, mint beismerni, hogy hulyeseget irtal)
-
Azért ne mondd, hogy nem sejti hogy nála is probléma van mondjuk az escapinggel vagy egyéb szűrő megoldásokkal, mivel már annyi szervert feltörtek. Emiatt lekapcsolja a szervert.
Nyilván nem az ő hatásköre, de így értettem a rálátást.
De felesleges a téma, mert elsőre rosszul fogalmaztam, és nincs kedvem Vladimirrel egy színvonalas beszélgetésre, már ami a nyelvhasználatot illeti. -
julius666
addikt
Sony-éknak annyi, ezt már párszor leírtam, ez a crackeres történet már sokadik lépcsőfok a Sony balszerencse-sorozatában. Én biztos vagyok benne hogy másodrangú szórakoztatóelektronikai céggé fognak avanzsálni, ha nem azok már most is.
Őszintén szólva meg is érdemlik, magas lóról, nagy pofával nagyot lehet esni, pláne ha még fejest is ugranak a betonba.
-
lgb
tag
Btw, en emlekszem rosszul, hogy van olyan francia tortveny (vagy csak tervezet?), hogy ott nem lehet encode-olva user adatot tarolni, mert akkor keresre nem adhato ki plantext formaban a megfelelo szerveknek? Akkor ez elegge vicces helyzet lenne, es kb Franciaorszagban ellehetetlenitene az IT biztonsagot (es amugy is, mintha ott az adat encryptalas kerdese is elegge korlatozva lenne ...).
-
#24
bitblueduck
senior tag
bitblueduck
senior tag
Szerintem sok esetben a Sony megérdemli, amit kap. Az egy dolog, hogy a szomszéd pistike készít egy fórumot, és sql injection-t benyalja, vagy akár egy javascriptet is betudsz rakni az oldal fórumjára while(true) Alert() jelleggel, de ahol bankkártya és egyéb kritikus adatok vannak, ott ciki.
Meg ők sem ma született báránykák, audio cd-s rootkitekkel és a többi dologgal.
Én csak azt sajnálom, akinek ebből végfelhasználóként kár származik, nem megy neki a PSN családdal, barátokkal, leemelnek a számlájáról, vagy bármiféle kellemetlenség éri jogtalanul. -
Stirlitz
senior tag
válasz
mrhitoshi
#21
üzenetére
Ez hatalmas pofára esés a Sony-nak, még ha nem is akarod elfogadni. Fájdalmasan lassan reagálnak mindenre. Igaza volt annak, aki azt mondta, már az első alkalommal ki kellett volna húzni a kanócot, és ellenőrizni a még sértetlen szerverek biztonságát.
Hogy milyen számban riaszt el ügyfeleket azt nem tudom megbecsülni, de például én az a fajta ember vagyok, aki betegesen ügyel rá, hogy abszolút megbízható helyen legyen csak valóban személyes és fontos adatom tárolva. Ezek után leszek én szerinted Sony ügyfél belátható időn belül? És hányan gondolkodhatnak még hasonlóan?
-
jkorr
csendes tag
válasz
mrhitoshi
#21
üzenetére
Nana, elég sokan akadtak ki már a "szimpla" PSN ügy kapcsán is, és pártoltak el a Sonytól (most ne firtassuk, mennyire készpénznek vehető egy rakás "soha többé sony konzol / termék /stb" megszólalás egy internetes fórumon), hát még azóta a "napi" oldalfeltörések kapcsán. Nem azt mondom, hogy hú, mindenki otthagyja a Sonyt, de jópár ember bizalma megingott, én ezt már merem presztízsrombolásnak nevezni.
-
mrhitoshi
veterán
Nem értem, hogy ez miért is jó ? Most kit/kiket akarnak ezzel szivatni ? Oké, hogy 1-szer, vagy 2-szer feltörik, mert nem tetszik valakinek a Sony, bár azt sem értem, miért is törték fel elsőnek
, de ez már kezd szánalmas lenni, a Sony részéről is, meg az állítólagos "hackerek" részéről is. -
Marhasag.
1) Dramaian csokkenne a kockazatvallalasi hajlam, marpedig a legtobb sikeres vallalkozas, felfedezes, innovacio, stb. indulasakor (is) komoly kockazatot vallalnak a tagok.
2) Ha egy alkalmazott a sajat vagyonaval felelne a donteseiert, akkor a minimum az lenne, hogy a nyeresegbol is reszesedik. Tehat a cegek legfeljebb cegtarsakat vehetnenek be, alkalmazottakat nem.Satobbi.
-
Petyyyyy
addikt
Már annyira mindennapos esemény, hogy az informatikai lapok lassanként rovatot nyithatnak a „Mai Sony-hack” címmel
Ez részben mosolyra fakasztóan vicces..., másrészt viszont eléggé szomorú. Cseppet elgondolkodtat a dolog ami a cikkben is szerepel, hogy vajon a többi a cég hogy kezeli a felhasználói infókat? Tekintve, hogy ott az a rengetet xStore (Pl. egy Nokia vagy Apple...?) egy rakat jelszóval, mail címmel.
-
rt06
veterán
ha jol sejtem, itt pont nem plaintext jelszavak voltak, ugyanis az nincs minden userhez feltunteve
ahol latszik, ott rovid es/vagy a username-bol adodo jelszorol van szo, illetve talalhato a listaban par md5 hash-hre emlekezteto karaktersor ismondjuk nekem kicsit gyanus, hogy egyetlen jelszo sincs tobb, mint 6 karakter, s tobbnyire vagy megegyezik a felhasznalonevvel, vagy annak elso es masodik felcserelve kapjuk
-
-
orbano
félisten
eléggé szánalmas, és jelzi az egész ipar óriási dilettanciáját, hogy egy ekkora cégnél lehetnek ilyen amatőr bakik. nincsen egyébként ilyenkor valami IT-kamara, aki az ilyen rndszereket készítő barmokat felelősségre vonja és megfosztja minden további munkalehetőségtől?
-
Geller72
veterán
Ilynekor is szívesen látnék valami olyan, mint pl. a "független felméréseknél". Pl.
Sony. Powered by "mekkávé"..
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ilyenkor miért nincs?.
.Azért elég durva ez a P. Text..Mondjuk, ha még az elsőnél ilyen lett volna, akkor csak max. az ottani adminokat kellett volna finoman szólva is a munkaügyi központokba küldeni, de hogy a sokadikból sem tanultak, ez azért már inkább röhejes.
De reméljük, a többiek a piacon legalább részben tanulnak az esetből.
Így jobban belegondolva, meg is érdemlik, amit kaptak az elmúlt hónapokban 
NHibernate, EF4, NoSql, stb.
É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.
Egyébként teljesen igazad van, valóban így kellene mindenkinek használnia 
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.
És még szinkronizáljam a telefonkönyvem az interneten. Hát persze, hogyne ,naponta többször is 
.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ilyenkor miért nincs?.Új hozzászólás Aktív témák
- iPhone 13 Pro Max / 128GB / Gold / Gyári kártyafüggetlen (243)
- Zbook 14 Firefly G10 I7 1370P/L14 /T14 G1/T490/T495/Hp 840 G6 I5/830 G6 I7/745 Ryzen 3 Dell X1 yogaH
- Dell Latitude 7440 -14"FHD+1 IPS - i5-1345U 16GB - 512GB - Win11 - 1 év garancia + Dokkoló + 240W DC
- A.R.E.S. L50 hangsugárzó pár
- IPhone 16 Pro max 256GB gyári független 2026.02.26. Apple jótállás
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
- LG 27GN800P - 27" IPS - 2560x1440 - 144 hz 1ms - NVIDIA G-Sync - AMD FreeSync - HDR 10
- Felturbóznád a gèped? Ezt Neked ajánljuk!
- Beszámítás! Lenovo IdeaPad Gaming 3 Gamer notebook - R5 7535HS 16GB DDR5 512GB SSD RTX 3050 6GB W11
- Dell 7400 Intel Core i7-8665U
Állásajánlatok
Cég: FOTC
Város: Budapest