Trinaest pravila za razvoj sigurnih Java aplikacija

Sigurnost je jedan od najsloženijih, najširih i najvažnijih aspekata razvoja softvera. Softverska sigurnost također se često zanemaruje ili pojednostavljuje na samo nekoliko manjih prilagodbi na kraju razvojnog ciklusa. Rezultate možemo vidjeti na godišnjem popisu velikih kršenja sigurnosti podataka, koji je u 2019. iznosio preko 3 milijarde izloženih zapisa. Ako se to može dogoditi Capital One, može se dogoditi i vama.

Dobra vijest je da je Java dugogodišnja razvojna platforma s mnogim ugrađenim sigurnosnim značajkama. Paket Java Security prošao je intenzivno borbeno testiranje i često se ažurira zbog novih sigurnosnih ranjivosti. Noviji Java EE Security API, objavljen u rujnu 2017., bavi se ranjivostima u arhitekturi oblaka i mikroservisa. Ekosustav Java također uključuje širok raspon alata za profiliranje i izvještavanje o sigurnosnim problemima. 

Ali čak i uz solidnu razvojnu platformu, važno je biti na oprezu. Razvoj aplikacija složen je poduhvat, a ranjivosti se mogu sakriti u pozadinskoj buci. Trebali biste razmišljati o sigurnosti u svakoj fazi razvoja aplikacije, od jezičnih značajki na razini klase do autorizacije krajnje točke API-ja.

Sljedeća osnovna pravila nude dobar temelj za izgradnju sigurnijih Java aplikacija.

Java sigurnosno pravilo br. 1: Napišite čisti, jaki Java kôd

Ranjivosti se vole skrivati ​​u složenosti, zato neka vaš kod bude što jednostavniji bez žrtvovanja funkcionalnosti. Korištenje dokazanih principa dizajna poput SUHOG (nemojte se ponavljati) pomoći će vam da napišete kod koji je lakši za pregled zbog problema.  

Uvijek izložite što manje podataka u kodu. Skrivanje detalja implementacije podržava kod koji je i održiv i siguran. Ova tri savjeta uvelike će doprinijeti pisanju sigurnog Java koda:

  • Dobro iskoristite Java-ove modifikatore pristupa . Znajući kako prijaviti različite razine pristupa za klase, metode i njihove atribute, uvelike će se zaštititi vaš kôd. Sve što se može učiniti privatnim, trebalo bi biti privatno. 
  • Izbjegavajte refleksiju i introspekciju . Postoje slučajevi u kojima su takve napredne tehnike zaslužne, ali u većini biste ih trebali izbjegavati. Korištenje refleksije eliminira jako tipkanje, što može unijeti slabe točke i nestabilnost u vaš kôd. Usporedba naziva klasa kao nizova podložna je pogreškama i lako može dovesti do sudara prostora imena.
  • Uvijek definirajte najmanje moguće API i površine sučelja . Razdvojite komponente i učinite da komuniciraju na najmanjem mogućem području. Čak i ako je jedno područje vaše aplikacije zaraženo kršenjem, druga će biti sigurna. 

Pravilo sigurnosti Java 2: Izbjegavajte serializaciju

Ovo je još jedan savjet za kodiranje, ali dovoljno je važan da bude vlastito pravilo. Serijalizacija uzima udaljeni ulaz i pretvara ga u potpuno obdareni objekt. Odbacuje se s konstruktorima i modifikatorima pristupa i omogućuje da tok nepoznatih podataka postane pokrenut kôd u JVM-u. Kao rezultat toga, Java serializacija je duboko i sama po sebi nesigurna.

Kraj serializacije Java

Ako niste čuli, Oracle dugoročno planira ukloniti serializaciju s Jave. Mark Reinhold, glavni arhitekt grupe Java platformi u Oracleu, rekao je da vjeruje da trećina ili više svih ranjivosti Java uključuje serializaciju.

Što je više moguće, izbjegavajte serializaciju / deserializaciju u vašem Java kodu. Umjesto toga, razmislite o upotrebi formata za serializaciju poput JSON ili YAML. Nikada, nikada ne izlažite nezaštićenu mrežnu krajnju točku koja prima i djeluje na tok serializacije. Ovo nije ništa drugo nego dobrodošla prostirka za haoš.

Pravilo Java br. 3: Nikada ne izlažite nešifrirane vjerodajnice ili osobne podatke

Teško je povjerovati, ali ova pogreška koju je moguće izbjeći uzrokuje bol iz godine u godinu.

Kad korisnik unese lozinku u preglednik, ona se šalje kao otvoreni tekst na vaš poslužitelj. To bi trebao biti zadnji put da ugleda svjetlost dana. Vi mora šifriranje lozinku putem jednosmjerne monograma prije istraju u bazu podataka, a zatim ga opet, kad god se uspoređuju na tu vrijednost.

Pravila za lozinke primjenjuju se na sve podatke koji mogu osobno identificirati (PII): kreditne kartice, brojeve socijalnog osiguranja itd. Sa svim osobnim podacima povjerenim vašoj aplikaciji treba postupati s najvišom razinom brige.

Nešifrirane vjerodajnice ili podaci koji otkrivaju identitet u bazi podataka zjapi rupa u sigurnosti i čekaju da ih napadač otkrije. Isto tako, nikada ne zapisujte neobrađene vjerodajnice u dnevnik ili ih na drugi način prenesite u datoteku ili mrežu. Umjesto toga, stvorite slani hash za svoje lozinke. Obavezno istražite i koristite preporučeni algoritam raspršivanja.

Skakanje na Pravilo # 4: uvijek koristite knjižnicu za šifriranje; ne valjaj svoje.

Pravilo Java zaštite br. 4: Koristite poznate i provjerene knjižnice

Uživajte u ovom pitanju i odgovoru o pokretanju vlastitog sigurnosnog algoritma. Lekcija tl; dr je: koristiti poznate, pouzdane knjižnice i okvire kad god je to moguće. To se odnosi na čitav spektar, od raspršivanja lozinke do autorizacije REST API-ja.

Srećom, Java i njezin ekosustav ovdje su vam leđa. Za sigurnost aplikacija, Spring Security je de facto standard. Nudi širok raspon opcija i fleksibilnost kako bi se uklopila u bilo koju arhitekturu aplikacije, a uključuje niz sigurnosnih pristupa.

Vaš prvi instinkt u rješavanju sigurnosti trebao bi biti istraživanje. Istražite najbolje prakse, a zatim istražite koja će knjižnica primijeniti te prakse umjesto vas. Na primjer, ako želite koristiti JSON Web Tokens za upravljanje provjerom autentičnosti i autorizacijom, pogledajte Java knjižnicu koja obuhvaća JWT, a zatim naučite kako to integrirati u Spring Security.

Čak i koristeći pouzdani alat, prilično je lako raščlaniti autorizaciju i autentifikaciju. Obavezno se krećite i provjerite sve što radite.

Java sigurnosno pravilo br. 5: Budite paranoični u vezi s vanjskim unosom

Bilo da dolazi od korisnika koji upisuje obrazac, pohranu podataka ili udaljeni API, nikad ne vjerujte vanjskom unosu.

SQL ubrizgavanje i skriptiranje na više lokacija (XSS) samo su najčešći napadi koji mogu proizaći iz pogrešnog rukovanja vanjskim unosom. Manje poznat primjer - jedan od mnogih - je "napad milijarde smijeha", pri čemu proširenje XML entiteta može izazvati napad uskraćivanja usluge.

Kad god primite ulaz, to bi trebalo provjeriti i sanirati. To se posebno odnosi na sve što bi moglo biti predstavljeno nekom drugom alatu ili sustavu za obradu. Na primjer, ako nešto može završiti kao argument za naredbenu liniju OS-a: oprez!

Posebna i dobro poznata instanca je ubrizgavanje SQL-a, koje je pokriveno sljedećim pravilom.

Java sigurnosno pravilo br. 6: Uvijek koristite pripremljene izjave za obradu SQL parametara

Kad god izradite SQL izraz, riskirate interpolaciju fragmenta izvršnog koda.

Znajući to, dobra je praksa uvijek koristiti klasu java.sql.PreparedStatement za stvaranje SQL-a. Slični sadržaji postoje za NoSQL trgovine poput MongoDB-a. Ako koristite ORM sloj, implementacija će PreparedStatementza vas upotrijebiti s ispod haube.

Pravilo Java br. 7: Ne otkrivajte implementaciju putem poruka o pogreškama

Poruke o pogreškama u proizvodnji mogu biti plodan izvor informacija za napadače. Tragovi stoga mogu otkriti informacije o tehnologiji koju upotrebljavate i kako je upotrebljavate. Izbjegavajte otkrivanje tragova stogova krajnjim korisnicima.

U ovu kategoriju spadaju i upozorenja o neuspjeloj prijavi. Općenito je prihvaćeno da se poruka o pogrešci daje kao "Prijava nije uspjela" nasuprot "Nisam pronašao tog korisnika" ili "Pogrešna lozinka". Ponudite što manje pomoći potencijalno zlobnim korisnicima.

U idealnom slučaju, poruke o pogreškama ne bi trebale otkriti temeljni tehnološki skup za vašu aplikaciju. Neka ti podaci budu što neprozirniji.

Java sigurnosno pravilo br. 8: Redovito ažurirajte sigurnosna izdanja

Od 2019. Oracle je implementirao novu shemu licenciranja i raspored izdavanja za Javu. Na nesreću programera, nova ritam izdanja ne olakšava stvari. Unatoč tome, odgovorni ste za čestu provjeru sigurnosnih ažuriranja i njihovu primjenu na JRE i JDK.

Obavezno znajte koje su kritične zakrpe dostupne redovitim provjeravanjem Oracle početne stranice radi sigurnosnih upozorenja. Svako tromjesečje Oracle isporučuje automatizirano ažuriranje zakrpe za trenutno LTS izdanje (dugotrajna podrška) Jave. Nevolja je u tome što je ta zakrpa dostupna samo ako plaćate licencu za Java podršku.

Ako vaša organizacija plaća takvu licencu, slijedite rutu automatskog ažuriranja. Ako ne, vjerojatno koristite OpenJDK i zakrpe ćete morati obaviti sami. U tom slučaju možete primijeniti binarnu zakrpu ili jednostavno zamijeniti postojeću instalaciju OpenJDK najnovijom verzijom. Možete koristiti i komercijalno podržani OpenJDK poput Azul-ovog Zulu Enterprisea.

Trebate li svaku sigurnosnu zakrpu?

Ako pažljivo promatrate sigurnosna upozorenja, možda ćete utvrditi da vam nije potreban određeni skup ažuriranja. Na primjer, čini se da je izdanje iz siječnja 2020. kritično Java ažuriranje; međutim, pomno čitanje pokazuje da ažuriranje samo krpi rupe u sigurnosti Java apleta i ne utječe na Java poslužitelje.

Java sigurnosno pravilo br. 9: Potražite ranjivosti ovisnosti

Dostupni su mnogi alati za automatsko skeniranje vaše baze kodova i ovisnosti radi ranjivosti. Sve što trebate je koristiti ih.

OWASP, projekt otvorene sigurnosti web aplikacija, organizacija je posvećena poboljšanju sigurnosti koda. OWASP-ov popis pouzdanih, visokokvalitetnih automatiziranih alata za skeniranje koda uključuje nekoliko alata orijentiranih na Java.

Redovito provjeravajte svoju bazu kodova, ali pripazite i na ovisnosti trećih strana. Napadači ciljaju knjižnice s otvorenim i zatvorenim izvorima. Pripazite na ažuriranja svojih ovisnosti i ažurirajte svoj sustav kad se objave novi sigurnosni popravci.

Java sigurnosno pravilo br. 10: Praćenje i evidentiranje aktivnosti korisnika

Čak i jednostavni napad grubom silom može biti uspješan ako ne pratite aktivno svoju aplikaciju. Upotrijebite alate za nadzor i bilježenje kako biste pripazili na zdravlje aplikacija.

Ako se želite uvjeriti zašto je nadzor važan, samo sjedite i gledajte TCP pakete na priključku za slušanje vaših aplikacija. Vidjet ćete sve vrste aktivnosti, daleko izvan jednostavnih korisničkih interakcija. Neke od tih aktivnosti bit će botovi i zlikovci koji pretražuju ranjivosti.

Trebali biste bilježiti i nadzirati neuspjele pokušaje prijave i primjenjivati ​​protu mjere kako biste spriječili da udaljeni klijenti nekažnjeno napadaju.

Nadgledanje vas može upozoriti na neobjašnjive skokove, a bilježenje može pomoći u razotkrivanju onoga što je pošlo po zlu nakon napada. Ekosustav Java uključuje bogatstvo komercijalnih rješenja i rješenja otvorenog koda za bilježenje i nadzor.

Java sigurnosno pravilo br. 11: Pripazite na napade uskraćivanja usluge (DoS)

Kad god obrađujete potencijalno skupe resurse ili poduzimate potencijalno skupe operacije, trebali biste se zaštititi od korištenja odbjeglih resursa.

Oracle održava popis potencijalnih vektora za ovu vrstu problema u svojim smjernicama za sigurno kodiranje za Java SE dokument, pod naslovom "Odbijanje usluge".

U osnovi, kad god idete izvoditi skupu operaciju, poput raspakiranja komprimirane datoteke, trebali biste nadgledati eksploziju korištenja resursa. Ne vjerujte manifestima datoteka. Vjerujte samo stvarnoj potrošnji na disku ili u memoriji, nadgledajte je i čuvajte se od pretjerivanja u postavljanju poslužitelja na koljena.

Slično tome, u nekoj obradi važno je pripaziti na neočekivane zauvijek-petlje. Ako je sumnja u petlju, dodajte zaštitnika koji osigurava da petlja napreduje i kratko je spojite ako se čini da je zombi.

Pravilo Java zaštite br. 12: Razmislite o upotrebi Java upravitelja sigurnosti

Java ima upravitelja sigurnosti koji se može koristiti za ograničavanje resursa kojima pokrenuti proces ima pristup. Program može izolirati s obzirom na pristup disku, memoriji, mreži i JVM-u. Sužavanje ovih zahtjeva za vašu aplikaciju smanjuje otisak moguće štete od napada. Takva izolacija također može biti nezgodna, zbog čega SecurityManagernije omogućena prema zadanim postavkama.

Morate sami odlučiti je li zaobilaženje SecurityManagerčvrstih mišljenja vrijedno dodatnog sloja zaštite vaših aplikacija. Pogledajte Oracle dokumente kako biste saznali više o sintaksi i mogućnostima Java upravitelja sigurnosti.

Java sigurnosno pravilo br. 13: Razmislite o upotrebi vanjske usluge provjere autentičnosti u oblaku

Neke aplikacije jednostavno moraju posjedovati svoje korisničke podatke; u ostalom, pružatelj usluga u oblaku mogao bi imati smisla.

Pretražite uokolo i pronaći ćete niz pružatelja usluga provjere autentičnosti u oblaku. Prednost takve usluge je ta što je davatelj usluga odgovoran za zaštitu osjetljivih korisničkih podataka, a ne vi. S druge strane, dodavanje usluge provjere autentičnosti povećava složenost vaše poslovne arhitekture. Neka rješenja, poput provjere autentičnosti FireBase, uključuju SDK-ove za integriranje u hrpu.

Zaključak

Predstavio sam 13 pravila za razvoj sigurnijih Java aplikacija. Ova su pravila isprobana i istinita, ali najveće pravilo od svih je ovo: budite sumnjičavi. Uvijek pristupajte razvoju softvera s oprezom i sigurnosnim razmišljanjima. Potražite ranjivosti u svom kodu, iskoristite Java sigurnosne API-je i pakete i upotrijebite alate nezavisnih proizvođača za nadgledanje i evidentiranje vašeg koda zbog sigurnosnih problema.

Evo tri dobra resursa na visokoj razini kako biste bili u toku sa neprestano mijenjajućim sigurnosnim okružjem Java:

  • OWASP Top 10
  • CWE Top 25
  • Oracleove smjernice za sigurni kod

Ovu je priču "Trinaest pravila za razvoj sigurnih Java aplikacija" izvorno objavio JavaWorld.