Új hozzászólás Aktív témák

• #35 ntomka nagyúr sh4d0w #34

  Új Válasz 2012-08-30 16:58:34 #35

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ntomka

  nagyúr

  válasz sh4d0w #34 üzenetére

  Arról nem is beszélve, hogy ő is csak ember. Egyrészt hibázhat, másrészt a tapasztalaton rengeteg múlik. Továbbá olyan dolgokon, mint a JVM nem egy ember dologozik. Mindenki a maga kódjára koncentrál, de mikor összedják olyan hiba is összeállhat, amire nem gondolnak. Ezek olyanok, amiről te is beszélsz.

  Amiről a többiek beszélnek "mindenki bűnös amíg be nem bizonyosodik az ellenkezője" szagú.

• #33 bambano titán sh4d0w #31

  Új Válasz 2012-08-30 16:42:42 #33

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz sh4d0w #31 üzenetére

  simán.
  a sebezhetőségek jelentős része azonos technikákra épít, amik ellen van ismert védelem. ha alap dolgokat sem tesz meg érte a fejlesztő, akkor elvileg felelősségre vonható.
  például c-ben az n-es függvényváltozatok használata indokolt. strcpy helyett pl. strncpy. vagy input mező nem kellő ellenőrzése. úgy átvenni egy input mező tartalmát, hogy legalább a hosszát ne ellenőrizd, azért főbelövés jár, nem ilyen kis felelősségre vonás.

  fentiekből mind buffer overflow lesz, és arra lehet exploitot építeni.

  sql kifejezésben használt bemenetet megnézni, hogy legalább ; meg ' ne legyen benne... hogy ne lehessen sql injectiont csinálni...

  tehát nem lehet minden sebezhetőségre előre felkészülni, de vannak alap dolgok, amikre kötelező lenne. ha ezt sem teszi meg, akkor tsibo.

• #24 bambano titán sh4d0w #23

  Új Válasz 2012-08-30 15:34:00 #24

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz sh4d0w #23 üzenetére

  például úgy, hogyha olyan programozási módszert használt, amiről régóta tudni, hogy rossz, azért felelhetne.

  oké, én sem szeretném, hogy minden hibáért perelhető legyen a fejlesztő. de az sem normális, hogy az oracle-nek lehetősége van arra, hogy tojjon az userek fejére. tehát ha azért nem is kellene perelhetővé tenni a fejlesztőt, hogy beletette a bugot a programba, azért igen, ha elfogadható időn belül nem reagál a biztonsági bejelentésekre. Egyik probléma (hogy bugot írt bele) műszaki, másik probléma (hogy nem vette ki) jogi, a ptk-ban szokásos együttműködési kötelezettség elmulasztása szerintem.

Új hozzászólás Aktív témák