☰

» »

Petindvajset najnevarnejših programerskih napak

Petindvajset najnevarnejših programerskih napak

Slo-Tech - Tudi letos so strokovnjaki za računalniško varnost iz približno trideset organizacij sestavili seznam 25 najnevarnejših programerskih napak, ki na široko odpirajo vrata zlikovcem. Letošnji seznam je zelo podoben lanskemu. Glavni krivci ostajajo enaki, tj. XSS (cross-site scripting), SQL injection in buffer-overflow. Teh 25 napak je krivih za skoraj vse napade na spletu, med drugim tudi za zloglasni kitajski napad na Google in druga zahodna podjetja. Poleg napak je še obsežna razlaga, kaj točno je problematično in kako se pomanjkljivostim izogniti. Predlagajo pa še eno rešitev za odpravo napak, in sicer vključitev klavzule v pogodbe z razvijalci, da so za hrošče odgovorni oni.

7 komentarjev

denial ::

Predlagajo pa še eno rešitev za odpravo napak, in sicer vključitev klavzule v pogodbe z razvijalci, da so za hrošče odgovorni oni.

Načeloma se strinjam s klavzulo. Za programske napake so vedno odgovorni razvijalci, čeprav nekateri krivdo valijo na PEBKAC. Ne vidim logike kako naj bo uporabnik odgovoren za BoF/XSS/SQLi v aplikaciji? Vendar IMO klavzula ne sme biti absolutna. Torej, razvijalec naj odgovarja za bug in naj poskrbi za popravek, nato pa naj bo dolžnost uporabnika, da popravek tudi mamesti.
SELECT finger FROM hand WHERE id=3;

jimmb0 ::

Se strinjam s tabo denial.Vendar mora biti tudi uporabnik, obvescen o popravku ;)

fiction ::

Ceprav se slisi super, IMHO odgovornost razvijalcev koncnim uporabnikom ne bi prinesla kaj bistveno drugega kot drazji software. Pri vecji konkurenci bi lahko ze slaba reklama zaradi ranljivosti naredila svoje. Oz. ok ne ravno zaradi ranljivosti, ce bi slo tako, bi vsakdo zadeve skrival, bolje je reci zaradi slabe varnostne prakse (pomanjkljivo testiranje, skrivanje, pocasen odziv na varnostne ranljivosti itd).

Ker se vse skupaj hitro razvija, je vcasih tezko reci kaj je varnostna ranljivost in kaj ne. Software pa jasno nikoli ne more biti cisto brez vseh bugov, tako da zmeraj obstaja moznost miljonskih tozb (v primeru vdora zaradi kaksne napake).

Kako je potem z open-source softwarom, ali pa npr. s programsko opremo, ki recimo uporablja kodo, ki je pod BSD licenco? Tam krivca ponavadi tezko pocukas za rokav. Vcasih je tudi precej tezko definirati kdo je sploh kriv. Npr. napaka v neki knjiznici, ki se zgodi zaradi cudnega klica tiste metode - je kriv programer, ki ni prebral manuala ali tisti, ki je pri cudnem vhodu naredil nekaj cudnega? Tudi kar se tice uporabnika ni vse tako crnobelo kot v redkih opisanih primerih (npr. ko gre za buffer overflow). Velikokrat tudi koncni uporabnik "pripomore" k vdoru.

cryptozaver ::

Všeč mi je zadnji stavek članka. Je nekako logičen... ;((

shubell ::

lol... razvijalci odgovorni.. zakon ane... zdej bodo še programrje začel tožit zato ker je nekdo spustil nepretestiran software strankam...

BlueRunner ::

Zakona ni nihče omenjal.

Razvijalce oziroma razvojna podjetja se že danes toži, če ne izpolnjujejo pogodbenh določil. Kar se predlaga je samo dodatno pogodbeno določilo in kdor si bo prebral okvirno besedilo, bo ugotovil, da sploh ni takšen bav, bav. Dejansko dobavitlja samo zavezuje k temu, da bo sprejel vse primerne ukrepe za zmanjšanje verjetnosti, da bo v kodi varnostna napaka.

Nekako tako, kot vsako razvojno podjetje s ščepcem pameti vpelje razvojne postopke s katerimi zagotavlja, da bodo stvari delale to, kar naročnik zahteva in, da bodo stvari narejene v dogovorjenih rokih, tako so določila usmerjena v to, da razvojni postopki v vseh korakih upoštevajo tudi varnostni vidik. Končen produk pa se ne smatra za dokončan, dokler niso vse v testiranju odkrite varnostne pomankljivosti odpravljene.

OSS, FOSS, GPL, BSD, MS, ... so tukaj nepomembne stvari. Pomeben je odnos med naročnikom in dobaviteljem.

Je pa res, da bo dobavitelju težko pojasniti zakaj rešitev vključuje IE6 z znanimi varnostnimi luknjami, klavzula pa preprečuje prevzem takšne rešitve, dokler znane varnostne luknje niso odpravljene. V takšnih primerih se stvar velikokrat zalomi na strani naročnika, ki gleda na varnost s figo v žepu (ah, to so revizorji nekaj težili, saj produkt konec koncev deluje) in sprejme tudi izdelek, ki je sicer funkcionalno ustrezen, znane varnostne napake pa niso odpravljene. Potem pa se dogajajo TJX-i in podobno...

noraguta ::

eh seznam je malo dane že dolgočasen. korenina problema pri doberšnem delu napak je pa kar izbrana tehnologija.dostikrat je vse skupaj povezano tudi z zgodovino.najbolj trapasto pri vsem skupaj pa je , da se bodo ene teiste napake pojavljale še dolgo. sql se da prav prisrčno evaluirat glede varnosti v compile timu, pa tega praktično ni v nobeni mainstream tehologiji.
Pust' ot pobyedy k pobyedye vyedyot!

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Zaščita pred zaganjanjem tujih aplikacij na Xbox 360 končno premagana

Oddelek: Novice / Varnost		2710322 (8500) Looooooka
»

YouTube in App Store žrtvi napadov

Oddelek: Novice / Omrežja / internet		84282 (3483) Dragi
»

Napad z ničelno predpono na SSL/TLS certifikate že "v divjini"

Oddelek: Novice / Varnost		416376 (4754) McMallar
»

Ali Severna Koreja uporablja hekanje v vojaške in obveščevalne namene?

Oddelek: Novice / Varnost		184990 (4990) iro

Več podobnih tem