Tietoturvallinen ohjelmointi
Ohjelmoinnin tietoturvaa voi toki edistää useilla tavoilla:
1. Valitse ohjelmointiväline, joka on suunniteltu niin, että se editää tietoturvaa, eikä sisällä ns. sudenkuoppia, jotka tarjoavat mahdollisuuden huomaamattaan kirjoittaa vaarallista koodia, esim. puskurin ylivuotohyökkäyksille tai muotoilumerkkijonoille haavoittuvaista koodia.
2. Ohjelmoi huolellisesti, ja mieti myös, mitä tapahtuu, jos jotain aliohjelmaa kutsutaan virheellisin parametrein, erityisesti, jos jokin parametri ylittää sille sallitun koon.
mutta...
aina on mahdollista, että joku asia jää koodaajalta huomaamatta.
Tällaiset pitäisi ehdottomasti saada siivottua pois ennen koodin laittamista tuotantokäyttöön.
Yksi vaihtoehto voisi olla ns. auomatisoidut hyökkäysvälineet, joilla voisi testitarkoituksessa hyökätä omaa koodiaan vastaan, ja katsoa, pystyykö tuollainen hyökkäysohjelma suorittamaan omaa koodiaan kohdesovelluksessa.
Mutta mistä sitten saisi tuollaisia automaattisia hyökkäysvälineitä, ja luonnollisesti sellaisia, jotka eivät tee mitään oikeasti vahingollista, mutta esim. windows -sovelluksessa pyrkisivät näyttämään esim. MessageBox -winAPI -funktiolla viestin, jossa kerrotaan, että sovelluksen tietoturva on murrettu ja jos mahdollista, asiaan liittyvät koodi- , pino- ja keko -osoitteet sekä tarvittaessa vedokset näistä. Nuo voisi olla hyvä kirjoittaa levylle tekstitiedostoksi, jossa ne ovat varmasti oikein eikä niitä tarvitse käsin kopioida. (varsinkin kun windowsin copy/paste ei toimi MessageBox -ikkunan tekstistä).
Noista välineistä kun ollaan oudon hiljaa, tekosyynä varmaankin se, että nehän eivät voi työvälineinä ottaa kantaa siihen, mitä vastaan hyökätään. (toki voisi esim. sallia hyökkäykset vain tunnettuihin lähiverkko-osoitteisiin, kuten 192.168.x.y sekä 10.x.y.z sekä 172.16-31.x.y).
Toisaalta tuo vaikeneminen on eduksi niille ohjelmistotaloille, jotka myyvät tietoturva-auditointipalveluja, sillä jos jokainen koodaaja voisi itse testata koodinsa, voisi ko. palvelujen kysyntä vähentyä.
En kuitenkaan käsitä, miksi yleisellä tasolla pitäisi pyrkiä estämään koodinsa itse testausta ja näin pakottamaan ostamaan auditoinnit palveluna, ja kuka toisaalta voi taata minkään yksittäisen palveluyrityksen palvelujen laatua ?
Ohjelmoinnin tietoturvaa voi toki edistää useilla tavoilla:
1. Valitse ohjelmointiväline, joka on suunniteltu niin, että se editää tietoturvaa, eikä sisällä ns. sudenkuoppia, jotka tarjoavat mahdollisuuden huomaamattaan kirjoittaa vaarallista koodia, esim. puskurin ylivuotohyökkäyksille tai muotoilumerkkijonoille haavoittuvaista koodia.
2. Ohjelmoi huolellisesti, ja mieti myös, mitä tapahtuu, jos jotain aliohjelmaa kutsutaan virheellisin parametrein, erityisesti, jos jokin parametri ylittää sille sallitun koon.
mutta...
aina on mahdollista, että joku asia jää koodaajalta huomaamatta.
Tällaiset pitäisi ehdottomasti saada siivottua pois ennen koodin laittamista tuotantokäyttöön.
Yksi vaihtoehto voisi olla ns. auomatisoidut hyökkäysvälineet, joilla voisi testitarkoituksessa hyökätä omaa koodiaan vastaan, ja katsoa, pystyykö tuollainen hyökkäysohjelma suorittamaan omaa koodiaan kohdesovelluksessa.
Mutta mistä sitten saisi tuollaisia automaattisia hyökkäysvälineitä, ja luonnollisesti sellaisia, jotka eivät tee mitään oikeasti vahingollista, mutta esim. windows -sovelluksessa pyrkisivät näyttämään esim. MessageBox -winAPI -funktiolla viestin, jossa kerrotaan, että sovelluksen tietoturva on murrettu ja jos mahdollista, asiaan liittyvät koodi- , pino- ja keko -osoitteet sekä tarvittaessa vedokset näistä. Nuo voisi olla hyvä kirjoittaa levylle tekstitiedostoksi, jossa ne ovat varmasti oikein eikä niitä tarvitse käsin kopioida. (varsinkin kun windowsin copy/paste ei toimi MessageBox -ikkunan tekstistä).
Noista välineistä kun ollaan oudon hiljaa, tekosyynä varmaankin se, että nehän eivät voi työvälineinä ottaa kantaa siihen, mitä vastaan hyökätään. (toki voisi esim. sallia hyökkäykset vain tunnettuihin lähiverkko-osoitteisiin, kuten 192.168.x.y sekä 10.x.y.z sekä 172.16-31.x.y).
Toisaalta tuo vaikeneminen on eduksi niille ohjelmistotaloille, jotka myyvät tietoturva-auditointipalveluja, sillä jos jokainen koodaaja voisi itse testata koodinsa, voisi ko. palvelujen kysyntä vähentyä.
En kuitenkaan käsitä, miksi yleisellä tasolla pitäisi pyrkiä estämään koodinsa itse testausta ja näin pakottamaan ostamaan auditoinnit palveluna, ja kuka toisaalta voi taata minkään yksittäisen palveluyrityksen palvelujen laatua ?
Vastaukset 2
Vanhimmat
"1. Valitse ohjelmointiväline, joka on suunniteltu niin, että se editää tietoturvaa, eikä sisällä ns. sudenkuoppia, jotka tarjoavat mahdollisuuden huomaamattaan kirjoittaa vaarallista koodia, esim. puskurin ylivuotohyökkäyksille tai muotoilumerkkijonoille haavoittuvaista koodia."
Väärin. Tällähän tuudittauu helposti uskoon, että kun on eri työväline niin ei sitten tarvisi kiinnittää asioihin huomiota. Oikea tapa on kartoittaa eri työvälineistä ne sudenkuopat ja kirjoittaa koodi sen mukaan ettei näitä käytetä ja varmistaa että ne kierretään aina. Huolimattomuudesta ne tietoturva-aukot tulee.
"2. Ohjelmoi huolellisesti, ja mieti myös, mitä tapahtuu, jos jotain aliohjelmaa kutsutaan virheellisin parametrein, erityisesti, jos jokin parametri ylittää sille sallitun koon."
Kuten äsken sanoin, huolellisuus auttaa. Ja softan valmistuksessa on hyvä ottaa käyttöön jotain checklistejä että käy kaiken koodin läpi että ei jää niitä ongelmia sinne.
Tietoturvan suhteen ei kannata kuitenkaan alkaa masturboiviksi apinoiksi. Ne on bugeja siinä missä muutkin ja usein haavoittuvuuteen liittyy myös jokin bugi.
Tulee meinaan jonkun puolueettomamman osapuolen näkemys siihen hommaan. Ei kai sillä mitään takuita ole tarkotuskaan antaa.