Trinajst pravil za razvoj varnih aplikacij Java

Varnost je eden najbolj zapletenih, najširših in najpomembnejših vidikov razvoja programske opreme. Tudi varnost programske opreme je pogosto prezrta ali poenostavljena na le nekaj manjših prilagoditev na koncu razvojnega cikla. Rezultate lahko vidimo na letnem seznamu večjih kršitev varnosti podatkov, ki je leta 2019 znašal več kot 3 milijarde izpostavljenih evidenc. Če se to lahko zgodi Capital One, se lahko zgodi tudi vam.

Dobra novica je, da je Java dolgoletna razvojna platforma z veliko vgrajenimi varnostnimi funkcijami. Paket Java Security je bil intenzivno preizkušen v bitkah in se pogosto posodablja zaradi novih varnostnih ranljivosti. Novejši API za varnost Java EE, izdan septembra 2017, obravnava ranljivosti v arhitekturah v oblaku in mikro storitvah. Javski ekosistem vključuje tudi široko paleto orodij za profiliranje in poročanje o varnostnih težavah.

Toda tudi s trdno razvojno platformo je pomembno, da ostanemo pozorni. Razvoj aplikacij je zapleten, ranljivosti pa se lahko skrijejo v ozadju. O varnosti bi morali razmišljati na vseh stopnjah razvoja aplikacij, od jezikovnih funkcij na ravni razreda do avtorizacije končne točke API.

Naslednja osnovna pravila so dobra osnova za izdelavo varnejših aplikacij Java.

Pravilo Java Java št. 1: Napišite čisto, močno Java kodo

Ranljivosti se radi skrivajo v zapletenosti, zato naj bo vaša koda čim bolj preprosta, ne da bi pri tem žrtvovali funkcionalnost. Uporaba preizkušenih načel oblikovanja, kot je SUHO (ne ponavljajte se), vam bo pomagala napisati kodo, ki jo je lažje pregledati zaradi težav.

V svoji kodi vedno izpostavljajte čim manj informacij. Skrivanje podrobnosti izvedbe podpira kodo, ki je tako vzdržna kot varna. Ti trije nasveti bodo daleč pri pisanju varne kode Java:

Dobro izkoristite Javine modifikatorje dostopa. Vedeti, kako razglasiti različne ravni dostopa za razrede, metode in njihove atribute, bo daleč pomagalo zaščititi vašo kodo. Vse, kar lahko postane zasebno, bi moralo biti zasebno.
Izogibajte se razmišljanju in samoogledovanju. V nekaterih primerih so takšne napredne tehnike zaslužne, vendar se jim večinoma izogibajte. Uporaba refleksije odpravlja močno tipkanje, kar lahko vnese šibke točke in nestabilnost v kodo. Primerjava imen razredov kot nizov je nagnjena k napakam in lahko zlahka privede do trčenja imenskega prostora.
Vedno določite najmanjšo možno površino API in vmesnika. Ločite komponente in omogočite interakcijo na najmanjšem možnem območju. Tudi če je eno področje vaše aplikacije okuženo s kršitvijo, bodo druga na varnem.

Javino pravilo št. 2: Izogibajte se serializaciji

To je še en namig za kodiranje, vendar je dovolj pomemben, da je samostojno pravilo. Serializacija sprejme oddaljeni vhod in ga pretvori v popolnoma obdarjen predmet. Odpravlja konstruktorje in modifikatorje dostopa ter omogoča, da tok neznanih podatkov postane delujoča koda v JVM. Kot rezultat, je serializacija Java globoko in sama po sebi negotova.

Konec serializacije Java

Če še niste slišali, ima Oracle dolgoročne načrte za odstranitev serializacije z Jave. Mark Reinhold, glavni arhitekt skupine za platformo Java v podjetju Oracle, je dejal, da verjame, da tretjina ali več ranljivosti Java vključuje serializacijo.

Kolikor je le mogoče, se izogibajte serializaciji / deserializaciji v svoji kodi Java. Namesto tega razmislite o uporabi serializacijske oblike, kot sta JSON ali YAML. Nikoli in nikoli ne izpostavljajte nezaščitene končne točke omrežja, ki sprejema in deluje na tok serializacije. To ni nič drugega kot dobrodošla preproga za zločin.

Pravilo varnosti Java 3: Nikoli ne izpostavljajte nešifriranih poverilnic ali osebnih podatkov

Težko je verjeti, toda ta napaka, ki se ji je mogoče izogniti, vsako leto povzroča bolečino.

Ko uporabnik v brskalnik vnese geslo, se pošlje na vaš strežnik kot odprto besedilo. To bi moralo biti zadnjič, ko zagleda luč sveta. Ti mora šifrirajte geslo prek enosmerne šifre, preden ga vztrajate v zbirki podatkov, in nato znova, kadar primerjate s to vrednostjo.

Pravila za gesla veljajo za vse podatke, ki omogočajo osebno prepoznavo (osebne podatke): kreditne kartice, številke socialne varnosti itd. Z vsemi osebnimi podatki, ki so zaupani vaši prijavi, je treba ravnati z najvišjo stopnjo skrbnosti.

Nešifrirane poverilnice ali osebne podatke v zbirki podatkov je zevajoča varnostna luknja, ki čaka, da jo napadalec odkrije. Prav tako nikoli ne pišite surovih poverilnic v dnevnik ali kako drugače pošiljajte v datoteke ali omrežja. Namesto tega ustvarite nasoljeni hash za svoja gesla. Ne pozabite raziskati in uporabiti priporočenega algoritma zgoščevanja.

Skok na pravilo št. 4: vedno uporabljaj knjižnico za šifriranje; ne valjajte svojega.

Pravilo Java Java št. 4: Uporabite znane in preizkušene knjižnice

Uživajte v tem vprašanju in odgovoru o uporabi lastnega varnostnega algoritma. Lekcija tl; dr je: kadar je le mogoče, uporabljajte znane, zanesljive knjižnice in okvire. To velja v celotnem spektru, od zgoščevanja gesel do avtorizacije REST API.

Na srečo sta tu tudi Java in njen ekosistem. Za varnost aplikacij je de facto standard Spring Security. Ponuja široko paleto možnosti in prilagodljivost, ki se prilega kateri koli arhitekturi aplikacije, in vključuje vrsto varnostnih pristopov.

Vaš prvi nagon pri reševanju varnosti bi moral biti raziskovanje. Raziščite najboljše prakse in nato raziščite, katera knjižnica bo te prakse izvajala namesto vas. Če na primer uporabljate spletne žetone JSON za upravljanje preverjanja pristnosti in avtorizacije, poglejte knjižnico Java, ki vsebuje JWT, in se nato naučite, kako jo vključiti v Spring Security.

Tudi z uporabo zanesljivega orodja je dokaj enostavno razbremeniti avtorizacijo in preverjanje pristnosti. Pazite, da se premikate počasi in preverite vse, kar počnete.

Pravilo varnosti Java 5: bodite paranoični glede zunanjega vnosa

Ne glede na to, ali gre za vnos uporabnika v obrazec, shrambo podatkov ali oddaljeni API, nikoli ne zaupajte zunanjemu vnosu.

Vbrizgavanje SQL in skriptiranje na več mestih (XSS) sta le najpogostejša napada, ki sta lahko posledica nepravilnega ravnanja z zunanjim vhodom. Manj znan primer - eden izmed mnogih - je "napad milijard smehov", pri katerem lahko razširitev entitete XML povzroči napad zavrnitve storitve.

Kadarkoli prejmete prispevek, ga je treba preveriti in sanirati. To še posebej velja za vse, kar bi lahko predstavili drugemu orodju ali sistemu za obdelavo. Na primer, če bi se kaj lahko končalo kot argument za ukazno vrstico OS: pozor!

Poseben in dobro znan primer je vbrizgavanje SQL, ki je opisano v naslednjem pravilu.

Pravilo Java Java št. 6: Za obdelavo parametrov SQL vedno uporabite pripravljene stavke

Vsakič, ko sestavite stavek SQL, tvegate interpoliranje fragmenta izvršljive kode.

Če vemo to, je dobra praksa nenehno uporabite razred java.sql.PreparedStatement za ustvarjanje SQL. Podobne zmogljivosti obstajajo tudi za trgovine NoSQL, kot je MongoDB. Če uporabljate plast ORM, bo uporabila izvedba PreparedStatements za vas pod pokrovom.

Pravilo varnosti Java 7: ne razkrivajte izvedbe s sporočili o napakah

Sporočila o napakah v produkciji so lahko ploden vir informacij za napadalce. Sledovi skladov lahko zlasti razkrijejo informacije o tehnologiji, ki jo uporabljate, in kako jo uporabljate. Izogibajte se razkrivanju sledov skladov končnim uporabnikom.

V to kategorijo spadajo tudi opozorila o neuspeli prijavi. Na splošno velja, da je treba sporočilo o napaki podati kot »Prijava ni uspela« v primerjavi z »Nisem našel uporabnika« ali »Napačno geslo«. Ponudite čim manj pomoči potencialno zlobnim uporabnikom.

V idealnem primeru sporočila o napakah ne smejo razkriti osnovnega svežnja tehnologij za vašo aplikacijo. Te informacije naj bodo čim bolj nepregledne.

Pravilo Java Java št. 8: Posodabljajte varnostne izdaje

Od leta 2019 je Oracle uvedel novo shemo licenciranja in razpored izdaje za Javo. Na žalost za razvijalce nova kadenca izdaje stvari ne olajša. Kljub temu ste odgovorni za pogosto preverjanje varnostnih posodobitev in njihovo uporabo na svojih JRE in JDK.

Prepričajte se, da ste seznanjeni s kritičnimi popravki, tako da redno preverjate varnostno opozorilo na domači strani Oracle. Vsako četrtletje Oracle dostavi samodejno posodobitev popravkov za trenutno izdajo LTS (dolgoročna podpora) Jave. Težava je v tem, da je popravek na voljo samo, če plačujete licenco za podporo Javi.

Če vaša organizacija plačuje takšno licenco, sledite poti samodejnega posodabljanja. Če ne, verjetno uporabljate OpenJDK in popravke boste morali opraviti sami. V tem primeru lahko uporabite binarni popravek ali pa preprosto zamenjate obstoječo namestitev OpenJDK z najnovejšo različico. Lahko pa uporabite komercialno podprt OpenJDK, kot je Azul's Zulu Enterprise.

Ali potrebujete vsak varnostni popravek?

Če pozorno spremljate varnostna opozorila, boste morda ugotovili, da ne potrebujete določenega sklopa posodobitev. Na primer izdaja januarja 2020 se prikaže biti kritična posodobitev Java; vendar natančno branje kaže, da posodobitev popravlja samo luknje v zaščiti programčkov Java in ne vpliva na strežnike Java.

Pravilo varnosti Java 9: Poiščite ranljivosti odvisnosti

Na voljo je veliko orodij za samodejno pregledovanje vaše kode in odvisnosti glede ranljivosti. Vse, kar morate storiti, je, da jih uporabite.

OWASP, projekt odprte zaščite spletnih aplikacij, je organizacija, namenjena izboljšanju varnosti kode. Seznam zaupanja vrednih visokokakovostnih orodij za samodejno skeniranje kod OWASP vključuje več orodij, usmerjenih v Java.

Redno preverjajte svojo kodno bazo, vendar bodite pozorni tudi na odvisnosti drugih proizvajalcev. Napadalci ciljajo na knjižnice z odprto in zaprto kodo. Bodite pozorni na posodobitve odvisnosti in posodobite sistem, ko bodo objavljeni novi varnostni popravki.

Pravilo Java Java št. 10: Spremljanje in beleženje aktivnosti uporabnika

Tudi preprost napad s surovo silo je lahko uspešen, če svoje aplikacije ne spremljate aktivno. Uporabite orodja za spremljanje in beleženje, da spremljate zdravje aplikacij.

Če se želite prepričati, zakaj je nadzor pomemben, samo posedite in si oglejte pakete TCP na vratih za poslušanje aplikacij. Videli boste vse vrste dejavnosti, ki presegajo preproste interakcije uporabnikov. Nekatere od teh dejavnosti bodo roboti in zlobneži, ki iščejo ranljivosti.

Morali bi beležiti in spremljati neuspešne poskuse prijave in uvesti protiukrepe, da preprečite, da bi oddaljeni odjemalci napadli nekaznovano.

Spremljanje vas lahko opozori na nepojasnjene konice, beleženje pa lahko pomaga razkriti, kaj je šlo narobe po napadu. Ekosistem Java vključuje obilo komercialnih in odprtokodnih rešitev za beleženje in spremljanje.

Pravilo Java Java št. 11: Pazite na napade Donial Service (Donial Service)

Kadar koli obdelujete potencialno drage vire ali izvajate potencialno drage operacije, se morate varovati pred porabljenimi viri.

Oracle vzdržuje seznam potencialnih vektorjev za to vrsto težav v svojih smernicah za varno kodiranje za dokument Java SE pod naslovom "Zavrnitev storitve".

V bistvu morate kadar koli opraviti drago operacijo, na primer razpakiranje stisnjene datoteke, in nadzorovati, kako eksplodira poraba virov. Ne zaupajte manifestom datotek. Zaupajte samo dejanski porabi na disku ali v pomnilniku, spremljajte jo in se varujte pred presežki, ki jih strežnik spravi na kolena.

Podobno je pri nekaterih obdelavah pomembno paziti na nepričakovane večne zanke. Če sumite na zanko, dodajte zaščito, ki zagotavlja, da zanka napreduje, in jo kratek stik, če se zdi, da je šel zombi.

Pravilo varnosti Java # 12: razmislite o uporabi upravitelja varnosti Java

Java ima varnostni upravitelj, s katerim lahko omejite vire, do katerih ima dostop proces. Program lahko izolira glede na dostop do diska, pomnilnika, omrežja in JVM. Z zožitvijo teh zahtev za vašo aplikacijo se zmanjša odtis možne škode zaradi napada. Takšna izolacija je lahko tudi neprijetna, zato SecurityManager ni privzeto omogočen.

Sami se boste morali odločiti, ali se boste ukvarjali SecurityManagerMočno mnenje je vredno dodatne zaščite za vaše aplikacije. Oglejte si dokumentacijo Oracle, če želite izvedeti več o sintaksi in zmožnostih varnostnega upravitelja Java.

Pravilo varnosti Java 13: razmislite o uporabi zunanje storitve overjanja v oblaku

Nekatere aplikacije morajo preprosto imeti v lasti svoje uporabniške podatke; v preostalem bi lahko ponudnik storitev v oblaku imel smisel.

Poiščite in našli boste vrsto ponudnikov overjanja v oblaku. Prednost takšne storitve je, da je za varovanje občutljivih uporabniških podatkov odgovoren ponudnik, ne vi. Po drugi strani dodajanje storitve overjanja poveča zapletenost vaše poslovne arhitekture. Nekatere rešitve, kot je preverjanje pristnosti FireBase, vključujejo SDK-je za integracijo prek sklada.

Zaključek

Predstavil sem 13 pravil za razvoj varnejših aplikacij Java. Ta pravila so preizkušena in resnična, a največje pravilo je naslednje: bodite sumljivi. K razvoju programske opreme vedno pristopite previdno in z varnostjo. Poiščite ranljivosti v svoji kodi, izkoristite varnostne API-je in pakete Java ter uporabite orodja drugih proizvajalcev za nadzor in beleženje kode zaradi varnostnih težav.

Tu so trije dobri viri na visoki ravni, da ostanete na tekočem z nenehno spreminjajočo se varnostno pokrajino Java: