Suojausvinkit sovelluskehittäjille

Tämä viesti julkaistiin alun perin Software Engineering -blogissa heinäkuussa 2012.

WhiteHat Security julkaisi äskettäin vuoden 2012 verkkosivustotilastoraporttinsa (PDF), joka antaa laajan kuvan verkkosivustojen turvallisuuden tilasta. Puhuin WhiteHat Securityn staattisen koodianalyysin johtajan Jerry Hoffin kanssa saadakseni kuvan siitä, kuinka vaikeat verkkosivustojen tietoturvaongelmat ovat, miksi meillä on edelleen näitä ongelmia ja mitä ohjelmistokehittäjät voivat tehdä niiden korjaamiseksi. Valitettavasti huolimatta aikaisempien vuosien huomattavista parannuksista, juhlalle ei ole juurikaan syytä.

Raportti

Raportti osoittaa, että vakavien haavoittuvuuksien kokonaismäärä on dramaattisesti laskenut: 1111 vuonna 2007 230: een vuonna 2010 ja nyt "vain" 79 vuonna 2011. Vaikka tämä on upea pudotus prosentteina, tosiasia, että keskimääräisellä verkkosivustolla on 79 haavoittuvuutta, on huolestuttava. Vielä häiritsevämpiä ovat haavoittuvuustyypit vuodesta 2011 (suluissa on prosenttiosuus sivustoista, jotka näyttävät nämä haavoittuvuudet): Sivustojenvälinen komentosarja (55%), Sivustojenvälinen pyyntöväärennys (19%) ja vaarallisin (minun mielipide) joukosta, SQL-injektio (11%). Vaikka tämä on pieni osa havaituista haavoittuvuuksista, nämä erityiskysymykset pakottavat minut loppumaan, koska niitä ei saisi olla vuonna 2012; asianmukaiset verkkokehykset, työkalut ja kirjastot tekevät hienoa työtä näiden ongelmien lieventämiseksi. Kun näen sovelluksen tai verkkosivuston, jolla on näitä ongelmia, tiedän, että kulissien takana on kehittäjä, joka käsin koodaa asioita, yleensä ilman syytä, ja selvästi ilman asianmukaisia ​​taitoja tai tietoja, jotta tällaista tavaraa voidaan koodata käsin. Mielestäni SQL Injection -heikkoudet ovat erityisen loukkaavia, koska nykyään on huomattavasti enemmän työtä luoda heille alttiita koodeja kuin suojattuja koodeja.

Herra Hoff ja minä puhuimme melko vähän näiden ongelmien taustalla olevista syistä. Jotain, josta olemme ehdottomasti sopineet, on se, että monet kehittäjät eivät osaa puuttua tietoturvaongelmiin. Täällä ei todellakaan ole mitään uutta, olemme nähneet tämän ongelman jo pitkään ja heittäneet ongelmaan vain yhä enemmän tekniikkaa kompensoimaan. Esimerkiksi WhiteHat Security -raportissa 71% löydetyistä haavoittuvuuksista voidaan kytkeä sovelluksen palomuurilla. Mutta ajatelkaa sitä hetkeksi ... 71% haavoittuvuuksista on niin yleistä, että automatisoitu sääntöpohjainen työkalu voi salata ne. Tämä kertoo minulle, että heti lepakosta 71%: n ongelmista ei pitäisi olla ensi sijassa.

Ongelman ydin on, että "päteväksi ohjelmistokehittäjäksi" tarvittavan tietomäärän määrä kasvaa jatkuvasti, kun taas tiedon hyödyllinen käyttöikä vähenee jatkuvasti. Päivässä ei yksinkertaisesti ole tarpeeksi tunteja, jotta joku voisi työskennellä kokopäiväisesti ohjelmistokehittäjänä ja saada täydennyskoulutuksen, joka vaaditaan päteväksi ohjelmistokehittäjäksi, elleivät he ole valmiita uhraamaan valtavasti henkilökohtaista aikaa tai työtä yksi harvinaisista yrityksistä, joka todella tukee oppimista. Vielä pahempaa on, että hyvä ohjelmistokehittäjä on vähintään 5–10 vuoden kokemus (riippuen tekemästäsi ja ympäristöstä, jossa työskentelet) alkuperäisen perustason oppimisen lisäksi. Joten kun kehittäjät todella lyövät askeleensa, he ovat ensisijaisella alueella elämätapahtumille, kuten avioliitto, lapset, ja yleensä hidastavat elämänsä vauhtia. Voin kertoa sinulle henkilökohtaisesta kokemuksesta, että viimeisen kuuden vuoden aikana, kun aloin kirjoittaa TechRepublicille, menin "yksinäisestä, lapsettomasta aikuisesta, jolla ei ole mitään tekemistä työn jälkeen paitsi pelata videopelejä ja tehdä enemmän ohjelmointia" "naimisissa oleviin aikuisiin, joilla on kaksi lasta joka on katsellut viime vuonna kaksi elokuvaa, jotka eivät sovellu lapselle. "

Useita viikkoja sitten, Dr. Dobb julkaisi fantastisen palkkakyselyn. Hyppää eteenpäin sivulle 9 pahimmasta potkusta, jonka saat koko viikon. Kaavio osoittaa, että keskimääräinen tietotekniikan työntekijän palkka on välillä 36–55 ja laskee sieltä alkaen. Lisäksi bändin 36 - 45 ja 46 - 55 bändin keskipalkka on sama . Toisin sanoen on olemassa massiivinen 20 vuoden urajakso, jolloin jonkun arvo ei kasva. Verrattuna IT-päälliköt näyttävät käyrän, jonka odotat paremmin, missä palkka nousee edelleen 46–55-bändiin saakka ja osoittaa sitten pudotusta.

Täällä ei ole sattumaa. Kuinka tiedän? Sivu 10 on viikon toiseksi pahin potku: IT-työntekijöiden irtautuminen iän perusteella. Näemme laskun 35 prosentista IT-työntekijöistä 46–55-vuotiaissa 14 prosenttiin 55 vuotta täyttäneissä. On selvää, että kehittäjillä on säilyvyys ja viimeinen käyttöpäivä on noin 55 vuotta.

Kaikki maailman koulutus ei kannata pavuvuoria, ellet voi sisällyttää sitä, ja se vaatii paljon kovia reaalimaailman oppitunteja, sellaiset, jotka vain ne, joilla on paljon kokemusta, ovat oppineet. Yleinen "vaadittavien taitojen" taso (eli sellainen, josta puhut työhaastattelussa tai asettamasi jatkamiselle) ei ole noussut viimeisen viiden vuoden aikana ja jos se on vähentynyt, mutta minun perustiedotuksen pohja on jatkanut kasvua. Nykypäivän Justin James tietää kauhistuttavasti enemmän turvallisista, terveistä koodauskäytännöistä kuin Justin James 2005, kun aloin kirjoittaa TechRepublicille, tai Justin James 2000, kun suoritin opinnot, tai Justin James ennen sitä. Tiesin vuonna 2000 paljon enemmän kuin tyypillinen web-kehittäjä, koska olin aloittanut vuonna 1995, kun Perl oli vasta alkamassa tulla hot tech -tehtäväksi tehdä verkkosivuista vuorovaikutteisia ja dynaamisia. Vuoteen 2001 mennessä olin ottanut käyttöön huomattavia osia HTTP-protokollaa käsin ja tyhjästä, ja olen oppinut prosessin aikana paljon web-tietoturvan toiminnasta.

turvallisuus

Tämä palauttaa minut takaisin turvallisuuskysymykseen. Epäilemättä, jos minulla ei olisi ollut lähes 20 vuoden kokemusta, jolla minulla on ollut kirjoitusohjelmiston kirjoittaminen, puhaltaisin koodia täynnä reikiä. Tiedän tämän, koska olen nähnyt liian monen vähemmän kokeneen kehittäjän tekevän yhä uudelleen ja uudelleen saman luokan virheitä, joita tein vuonna 1997 tai 2003, jopa silloin, kun "tiesin paremmin". Tiedän, miksi tein nuo virheet - se oli joko "voin rullata omaa paremmin kuin hyllyltä" -kohdan ymmärrys tai ajatus siitä, että jotain nopeasti lyömällä yhteen olisi hienoa "toistaiseksi" ja maksan tekninen velka pois myöhemmin. Olin väärässä molemmissa tapauksissa, joka kerta.

Sen jälkeen olen tietänyt turvallisuuden suhteen seuraavan (tuskin vakuuttava ja ei erityisessä järjestyksessä):

  • Puhdista kaikki, mukaan lukien tietokannoista, tiedostoista, verkkopalveluista tai muusta sellaisesta, joka ei ole kirjaimellinen lausekoodi koodistasi.
  • Käytä valmiiksi valmistettuja työkaluja, kehyksiä, kirjastoja, koodikomponentteja jne. Taakan poistamiseksi olkapäiltäsi. On parempi työskennellä uudelleen yrityksesi logiikan avulla, jotta käytetään ennalta testattua koodinpätkää, kuin luoda itsellesi oma itsensä ja olla jumissa yrittäessään saada tietoturvaelimet toimimaan.
  • Älä laatikoi nurkkaan, jossa on integrointeja, jotta perusjärjestelmä on "päivityskestävä" tai jopa "päivityskestävä". Sovellukset saavat kriittiset tietoturvakorjaukset koko ajan; Jos et voi tehdä mitä tarvitset tai haluat tehdä järjestelmälle estämättä perusjärjestelmän korjaamista tai päivittämistä, sinun on joko arvioitava tarpeesi uudelleen tai on käytettävä toista järjestelmää. Tarinan loppu.
  • Älä koskaan luo SQL-käskyjä sovelluksessa. Jos vaadit oman SQL-tiedoston kirjoittamista (vihje: et todennäköisesti osaa kirjoittaa sitä paremmin kuin koodigeneraattori, ellei tehtävä ole epätavallinen tai olet SQL-ohjattu toiminto, ja useimmat tehtävät eivät ole niin epätavallisia, etkä todennäköisesti ole ohjattu SQL), laita se tallennettuihin menettelyihin. Jos ajaisin maailmaa, kääntäjät ilmoittaisivat SQL-virheen virheenä ja kieltäytyisivät kääntämästä.
  • Suorita säännöllisiä turvatarkastuksia käytettävissä olevien automaattisten työkalujen avulla.
  • Käsittele tietoturvakorjauksia tärkeimmistä ominaisuuksista.
  • Lähesty koodisi hyökkääjän ajattelutavan avulla. Jos haluat hajottaa järjestelmän, tuhota tietoja tai implantoida käyttäjille pieniä pommeja, mitkä ikkunat ovat auki ja mitkä ovet ovat auki?
  • Jatka oppimista, jatka työskentelyä, jatka opiskelua ja keskustele ihmisten kanssa. Hanki altistuminen eri ideoille. Selvitä, kuinka muut ihmiset ratkaisevat ongelmia, ja tutkia niitä!

© Copyright 2020 | mobilegn.com