10 tärkeää turvallisuusperiaatetta
Tämä kirjoitus perustuu hyvin vahvasti artikkeliin AVOIDING THE TOP 10 SOFTWARE SECURITY DESIGN FLAWS [1]
1. Älä oleta luotettavaksi
periaate: Sovellukset usein koostuvat useista osista. Jos yksikään osista toimii hallitsemattomassa ympäristössä, huomioi että riskit tämän sovelluksen osan kohdalla ovat suuret [1].
Esimerkkejä siitä mitä voi tapahtua [1]:
- Ohjelmoija olettaa, että API kutsut suoritetaan aina samassa järjestyksessä
- Ajatellaan, että käyttöliittymä rajoittaa tarpeeksi käyttäjän lähetettämää dataa
- Luotetaan siihen, että asiakkaalle lähetetty salattu salainen tieto pysyy salassa
Ratkaisuehdotuksia [1]:
- Vältä tärkeiden turvaominaisuuksien suorittamista käyttäjän hallittavissa
- Älä luota ulkopuolelta tulevaan dataan ennenkuin olet varmistanut sen turvallisuuden
- Jos täytyy suorittaa turvallisuuteen vaikuttavaa koodia ympäristössä joka ei ole luotettava, suunnittele ja varmista tilanne huolellisesti. Mielellään erityisasiantuntijan toimesta.
2. Tunnistautuminen
periaate: Käyttäjän tunnistaminen on tärkeää (sekä estää luvaton identiteetin vaihto).
Esimerkkejä mitä voi tapahtua [1]:
- Jokin erikoisempi URL voi jäädä paitsi tunnistautumista ja mahdollistaa hyväksikäyttöä
- Ohjelmoija voi olettaa jonkun resurssin olevan kevollinen tunnistamiseen, kun todellisuudessa sillä ei voi yksilöidä käyttäjää. Esim. IP tai mac osoite.
- Jos tunnistus perustuu "token" menetelmään, arvaamisen mahdollisuus on olemassa, jos token luodaan liian yksinkertaisesti
- Salasanojen kunnollinen hallinta on vaikeaa ja huonot menetelmät voivat johtaa niiden vuotamiseen
Ratkaisuehdotuksia [1]:
- Käytä laadukasta tunnistuskirjastoa tai palvelua, kuten Kerberos
- Säädä tunnisteen vanheneminen
- Kysy uudestaan salasana ennen tärkeitä toimia
- Keskitetyn tunnistautumistoiminallisuuden käyttö
3. Käyttöoikeudet
periaate: Tunnistautumisen lisäksi on tarpeen huolellisesti tarkistaa, että käyttäjällä on oikeus suorittaa toimenpide.
Esimerkkejä mitä voi tapahtua [1]:
- Käyttäjien roolien vaihtuessa, voi unohtua käyttöoikeuksien muuttaminen
- Yrityksessä toiminnon suorittaminen voi vaatia kahden käyttäjän tekemän vahvistuksen. Yhdellä käyttäjällä voi olla mahdollisuus esiintyä kahtena eri käyttäjänä.
- Käyttäjän lisäksi oikeuteen tehdä toiminto voi vaikuttaa käyttäjän aika tai paikka
Ratkaisuehdotuksia [1]:
- Keskitty toiminnallisuuden toteuttaminen
- Uudelleenvahvistaa identiteetin/roolin enne tärkeitä toimintoja
4. Erota tieto ja toiminta
periaate: Tietokoneohjelmaan tulee tietoa ulkopuolelta. Eristä ohjelmaan syötetty tieto ohjelman suoritettavasta koodista.
Esimerkkejä mitä voi tapahtua [1]:
- SQL, JavaScript tai päätekomennon injektio
- Tietokoneet merkitsevät muistiosoitteet suoritettviin ja tietoa sisältäviin, mutta virhe ohjelmoinnissa voi estää tämän turvaominaisuuden toiminnan
- Dynaamisten toimintojen käyttö, kuten EVAL tai "reflection", voi aiheuttaa ongelmia
Ratkaisuehdotuksia [1]:
- Vältä rajapintoja, jotka ottavat tiedon vastaan yksinkertaisena tekstinä
- Jos sinulla on API, joka hyödyntää vain merkkijonoja, lisää yksi lisäkerros käyttäjän ja tämän APIn väliin
- Dynaamisen toiminnon voi tehdä vaihtoehtoisilla tavoilla, kuten koodin generoinnilla
5. Kaikki tieto tulee varmistaa
periaate: Jos odotat tiedon olevan tietyn laista, on tarpeen varmistaa, että se myös on sellaista.
Esimerkkejä mitä voi tapahtua [1]:
- Kun sovellus kehittyy, tiedon tarkastus voi jäädä vanhentuneeksi
- Ulkopuolinen teksti päätyy nettisivulle sisältäen linkin, se saattaa sisältää javascriptiä
- Ulkopuolinen teksti tiedostopolun nimessä voi mahdollistaa pääsyn vääriin tiedostoihin
- Erikoismerkit voivat läpäistä tarkastuksen, jos teksti ei ole tavallisessa muodossaan
- Syötteen rajoittamattomuus voi johtaa resurssien ylikäyttöön
Ratkaisuehdotuksia [1]:
- Nettisovelluksessa tarkista keskitetysti kaikki "request" pyynnöt
- Monimutkainen tieto, kuten kuva, täytyy tarkastaa erityisillä menetelmillä
- Käytä kirjastoista saatavia toimintoja
- Uudelleenvahvista tiedon oikeellisuus tietoa käyttävän koodin läheisyydessä
- Muuta epämääräinen tieto olioksi tai muuksi selkeäksi rakenteeksi
- Estää tietyt riskialttiit merkit merkkijonoissa, tilanteesta riippuen
- Tarkasta tieto tilanteen mukaisesti
6. Käytä salausta oikein
periaate: Salaus ei ratkaise kaikkia ongelmia, mutta auttaa oikein käytettynä
Esimerkkejä mitä voi tapahtua [1]:
- Jos teet omia salausfunktioita, niistä on vaikea saada vedenpitäviä
- Salauskirjastoja täytyy käyttää tarkoituksenmukaisesti ja ohjeiden mukaan
- Salausavainten hallinta voi epäonnistua, esim. tallennetaan väärään paikkaan
- Salausmenetelmät perustuvat satunnaisuuteen, mutta todellista satunnaisuutta on vaikea saavuttaa
- Salausalgoritmien hajanainen käyttö projektissa voi johtaa sekaannuksiin
Ratkaisuehdotuksia [1]:
- Käytä eritysiasiantuntijaa apuna
- Salauskirjastojen käyttö kannattaa asettaa abstraktin API:n taakse, jolloin sen muuttaminen ja käyttö on helppoa
- Jos teet itse, ole erityisen huolellinen
7. Kiinnitä huomiota arkaluontoisen tiedon tunnistamiseen ja hallintaan
periaate: Tunnista ja suunnittele KAIKEN arkaluontoisen tiedon käsittely
Esimerkkejä mitä voi tapahtua [1]:
- Eri alueilla on erilaisia määräyksiä, joita täytyy noudattaa
- Kriittisen tiedon on oltava aina saatavilla
- Automaattisesti voi tallentua arkaluontoista tietoa, kuten sijaintitietoja. Ne täytyy huomioida.
Ratkaisuehdotuksia [1]:
- Kun sovellus muuttuu, tai sovelluksen ympäristö, sinun täytyy jatkuvasti tarkastella ja päivittää suunnitelmaa
8. Huomioi käyttäjän toiminta
periaate: Sovelluksen käyttäjän toimet pitää huomioida kehityksessä: asennus, konfigurointi, käyttö, päivitys jne.
Esimerkkejä mitä voi tapahtua [1]:
- Ihmisen tausta vaikuttaa siihen, kuinka hän sovellusta käyttää (esim. lapset, sokeat)
- Jotkut käyttäjät todennkäköisesti käyttävät sovellusta toisin kuin on tarkoitettu
- Käyttäjät saattavat vähät välittää turvallisuudesta. Käyttäjä ei esimerkiksi aseta vaadittavia turva-asetuksia käyttöönoton yhteydessä
- Kun käyttäjä lopettaa sovelluksen/palvelun käytön, hän ei välttämättä tiedä mitä tietoja jälkeen jää
Ratkaisuehdotuksia [1]:
- Aina huomioi käyttäjä suunnittelussa
- Älä anna käyttäjän säätää kaikkia turvaominaisuuksia
- Oletusasetusten pitäisi olla turvalliset ja helppokäyttöiset
- Huomioi käyttäjien väsymys turvaominaisuuksiin
9. Huomioi sovelluksen ulkopuolisten osien vaikutus hyökkäysmahdollisuuksiin
periaate: Käytä aikaa siihen, että tunnistat "ei itse koodaamasi" toiminnallisuuden turvallisuusriskit.
Esimerkkejä mitä voi tapahtua [1]:
- Lataamasi kirjasto saattaa sisältää jo tunnettuja haavoittuvuuksia
- Käyttämäsi lisäosa saattaa sisältää turhia ominaisuuksia, jotka vain lisäävät riskiä
- Lisäosa aiheuttaa ylimääräisiä latauksia / lähetyksiä tai riippuvuuksien asennuksia
- Lisäosa saattaa sisältää yllättäviä konfigurointivaatimuksia sinulle tai käyttäjälle
Ratkaisuehdotuksia [1]:
- Yritä rajoittaa lisäosan kytkeytymistä sovellukseesi
- Rajoita lisäosan ominaisuuksia vain niihin, joita todella käytät
- Valitse lisäosa oman turvallisuusvaatimuksesi mukaisesti
- Varmista latauksen aitous kryptografian avulla
- Tee työtä pysyäksesi selvillä lisäosien turvallisuudesta
- Käytä automaattisia konfiguraatio ja julkaisutyökaluja, jotta kaikki turvaominaisuudet kytkeytyvät oikein
10. Suunnittele objektit ja toimijat helposti muunneltaviksi
periaate: Sovelluksen turvallisuusominaisuuksien täytyy olla mukautuvia, sen sijaan että olisivat "kiveen hakattuja".
Esimerkkejä mitä voi tapahtua [1]:
- Sovelluksen kehitys on vaiheittainen prosessi. Turvaominaisuuksien on vaikea pysyä mukana, että kaikki tulee testattua yms.
- Voi muodostua uusia hyökkäystapoja, jotka purevat jo julkaistuun sovellukseen myöhemmin
- Jos teet liian suuria muutoksia sovellukseen kerralla, kaikkea voi olla vaikea huomioida ja dokumentoida
- Järjestelmän merkittävissä laajennuksissa voi tulla ongelmia esim. käyttäjätilien kanssa
Ratkaisuehdotuksia [1]:
- Ole valmis vaihtamaan sovelluksen salausavaimet
- Suunnittele sovellusksen kriittinen toiminto toimimaan turvallisesti myös hätätilanteessa
- API tyyppinen turvallisuusjärjestelmä säästää aikaa muutokselta
- Huolehdi siitä, että eri kehittäjien oikeudet sovelluksen eri osiin pysyvät joustavasti ajan tasalla