Drošība ir viens no vissarežģītākajiem, plašākajiem un svarīgākajiem programmatūras izstrādes aspektiem. Programmatūras drošība arī tiek bieži ignorēta vai pārmērīgi vienkāršota, veicot tikai dažas nelielas korekcijas izstrādes cikla beigās. Rezultātus mēs varam redzēt galveno datu drošības pārkāpumu gada sarakstā, kas 2019. gadā bija vairāk nekā 3 miljardi atklātu ierakstu. Ja tas var notikt ar Capital One, tas var notikt arī ar jums.
Labā ziņa ir tā, ka Java ir ilgstoša attīstības platforma ar daudzām iebūvētām drošības funkcijām. Pakete Java Security ir intensīvi pārbaudīta, un to bieži atjaunina, lai atrastu jaunas drošības ievainojamības. Jaunākā Java EE Security API, kas izlaista 2017. gada septembrī, novērš mākoņu un mikropakalpojumu arhitektūras ievainojamības. Java ekosistēma ietver arī plašu rīku klāstu drošības problēmu profilēšanai un ziņošanai.
Bet pat ar stabilu attīstības platformu ir svarīgi saglabāt modrību. Lietojumprogrammu izstrāde ir sarežģīts pasākums, un ievainojamības var paslēpties fona trokšņos. Jums vajadzētu domāt par drošību visos lietojumprogrammu izstrādes posmos, sākot no klases līmeņa valodas funkcijām līdz API galapunkta autorizācijai.
Šie pamatnoteikumi piedāvā labu pamatu drošāku Java lietojumprogrammu veidošanai.
Java drošības noteikums Nr. 1: Uzrakstiet tīru, spēcīgu Java kodu
Neaizsargātības patīk slēpt sarežģītībā, tāpēc saglabājiet savu kodu pēc iespējas vienkāršāk, nezaudējot funkcionalitāti. Izmantojot pārbaudītus dizaina principus, piemēram, DRY (neatkārtojiet sevi), jūs varēsit uzrakstīt kodu, kurā ir vieglāk pārskatīt problēmas.
Kodā vienmēr atmaskot pēc iespējas mazāk informācijas. Īstenošanas detaļu slēpšana atbalsta kodu, kas ir gan uzturams, gan drošs. Šie trīs padomi palīdzēs izveidot drošu Java kodu:
- Labi izmantojiet Java piekļuves modifikatorus. Zinot, kā deklarēt dažādus piekļuves līmeņus klasēm, metodēm un to atribūtiem, būs daudz jāaizstāv kods. Visam, ko var padarīt privātu, jābūt privātam.
- Izvairieties no pārdomām un pašpārbaudes. Ir daži gadījumi, kad šādas progresīvas metodes ir pelnījušas, taču lielākoties jums vajadzētu no tām izvairīties. Pārdomu izmantošana novērš spēcīgu rakstīšanu, kas var ievadīt vājās vietas un nestabilitāti jūsu kodā. Klases nosaukumu kā virkņu salīdzināšana ir pakļauta kļūdām un var viegli izraisīt vārda vietas sadursmi.
- Vienmēr definējiet pēc iespējas mazākas API un saskarnes virsmas. Atvienojiet komponentus un ļaujiet tiem mijiedarboties visā iespējami mazākajā apgabalā. Pat ja vienā jūsu lietojumprogrammas apgabalā ir inficēts pārkāpums, citi būs droši.
Java drošības noteikums Nr. 2: Izvairieties no seriālizācijas
Šis ir vēl viens kodēšanas padoms, taču tas ir pietiekami svarīgi, lai tas būtu pats noteikums. Serializēšana prasa attālu ievadi un pārveido to par pilnīgi apveltītu objektu. Tas atsakās no konstruktoriem un piekļuves modifikatoriem, un ļauj nezināmu datu straumei kļūt par skriešanas kodu JVM. Rezultātā Java sērijveidošana ir dziļi un pēc būtības nedroša.
Java serializācijas beigas
Ja vēl neesat dzirdējis, Oracle plāno ilgtermiņā noņemt Java sērijas. Oracle Java platformu grupas galvenais arhitekts Marks Reinholds ir teicis, ka, viņaprāt, trešdaļa vai vairāk no visām Java ievainojamībām ir saistīta ar serializāciju.
Cik vien iespējams, izvairieties no Java koda serializācijas / deserializācijas. Tā vietā apsveriet iespēju izmantot sērijas formātu, piemēram, JSON vai YAML. Nekad, nekad neatklājiet neaizsargātu tīkla galapunktu, kas saņem un darbojas pēc sērijveida straumes. Tas ir nekas cits kā sagaidīšanas paklājs haosam.
Java drošības noteikums Nr. 3: Nekad neatklājiet nešifrētus akreditācijas datus vai PII
Ir grūti noticēt, taču šī kļūda, no kuras var izvairīties, gadu no gada rada sāpes.
Kad lietotājs pārlūkprogrammā ievada paroli, tā tiek nosūtīta uz jūsu serveri kā teksts. Tai vajadzētu būt pēdējai reizei, kad tā redz dienasgaismu. Jūs jābūt pirms saglabājat to datu bāzē, šifrējiet paroli, izmantojot vienvirziena šifru, un pēc tam dariet to vēlreiz, salīdzinot ar šo vērtību.
Paroļu noteikumi attiecas uz visu personu identificējošo informāciju (PII): kredītkartēm, sociālās apdrošināšanas numuriem utt. Jebkura personiskā informācija, kas uzticēta jūsu lietojumprogrammai, jāapstrādā visaugstākajā līmenī.
Nešifrēti akreditācijas dati vai PII datu bāzē ir plaisa, kas gaida, kad uzbrucējs atklās. Tāpat nekad nerakstiet neapstrādātus akreditācijas datus žurnālā vai kā citādi pārsūtiet uz failu vai tīklu. Tā vietā izveidojiet sālītu jaukumu savām parolēm. Noteikti veiciet pētījumu un izmantojiet ieteicamo jaukšanas algoritmu.
Pāreja uz 4. noteikumu: šifrēšanai vienmēr izmantojiet bibliotēku; nerullē savējo.
Java drošības noteikums Nr. 4: izmantojiet zināmas un pārbaudītas bibliotēkas
Izbaudiet acis uz šo jautājumu un atbildi par sava drošības algoritma ieviešanu. Tl; dr nodarbība ir: kad vien iespējams, izmantojiet zināmas, uzticamas bibliotēkas un ietvarus. Tas attiecas uz spektru, sākot no paroles jaukšanas līdz REST API autorizācijai.
Par laimi, Java un tās ekosistēma šeit ir jūsu mugura. Lietojumprogrammu drošībai Spring Security ir de facto standarts. Tas piedāvā plašu iespēju klāstu un elastību, lai tas atbilstu jebkurai lietotņu arhitektūrai, un tajā ir iekļautas dažādas drošības pieejas.
Jūsu pirmajam instinktam drošības problēmu risināšanā vajadzētu būt savam pētījumam. Izpētiet paraugpraksi un pēc tam izpētiet, kura bibliotēka šo praksi ieviesīs jūsu vietā. Piemēram, ja jūs meklējat JSON tīmekļa marķieru izmantošanu autentifikācijas un autorizācijas pārvaldībai, apskatiet Java bibliotēku, kas ietver JWT, un pēc tam uzziniet, kā to integrēt Spring Security.
Pat izmantojot uzticamu rīku, autorizāciju un autentifikāciju ir diezgan viegli apvienot. Pārvietojieties lēnām un pārbaudiet visu, ko darāt.
Java drošības noteikums Nr. 5: esiet paranoisks attiecībā uz ārēju ievadi
Neatkarīgi no tā, vai lietotājs ir ievadījis veidlapu, datu krātuvi vai attālo API, nekad neuzticieties ārējai ievadei.
SQL injicēšana un starpvietņu skripšana (XSS) ir tikai visbiežāk zināmie uzbrukumi, ko var izraisīt nepareiza ārējās ievades apstrāde. Mazāk pazīstams piemērs - viens no daudzajiem - ir "miljardu smieklu uzbrukums", kurā XML entītijas paplašināšana var izraisīt pakalpojumu atteikuma uzbrukumu.
Jebkurā laikā, kad saņemat ieguldījumu, tas ir jāpārbauda veselā prātā un jādezinficē. Tas jo īpaši attiecas uz visu, ko var iesniegt apstrādei citam rīkam vai sistēmai. Piemēram, ja kaut kas varētu kļūt par argumentu OS komandrindai: uzmanieties!
Īpašs un plaši pazīstams gadījums ir SQL injekcija, uz kuru attiecas nākamais noteikums.
Java drošības noteikums Nr. 6: SQL parametru apstrādei vienmēr izmantojiet sagatavotus priekšrakstus
Jebkurā laikā, kad izveidojat SQL priekšrakstu, jūs riskējat interpolēt izpildāmā koda fragmentu.
To zinot, tā ir laba prakse vienmēr SQL izveidošanai izmantojiet klasi java.sql.PreparedStatement. Līdzīgas iespējas pastāv arī NoSQL veikaliem, piemēram, MongoDB. Ja izmantojat ORM slāni, tiks izmantota ieviešana Sagatavots paziņojumss jums zem kapuces.
Java drošības noteikums Nr. 7: neatklāj ieviešanu, izmantojot kļūdu ziņojumus
Kļūdu ziņojumi ražošanā var būt auglīgs informācijas avots uzbrucējiem. Jo īpaši kaudzes pēdas var atklāt informāciju par izmantoto tehnoloģiju un to, kā jūs to izmantojat. Izvairieties atklāt kaudzes pēdas lietotājiem.
Brīdinājumi par neveiksmīgu pieteikšanos arī ietilpst šajā kategorijā. Parasti tiek pieņemts, ka kļūdas ziņojums jāsniedz kā "Pieteikšanās neizdevās" pret "Neatradu šo lietotāju" vai "Nepareiza parole". Piedāvājiet pēc iespējas mazāk palīdzības potenciāli nekrietnajiem lietotājiem.
Ideālā gadījumā kļūdu ziņojumos nevajadzētu atklāt jūsu lietojumprogrammas pamatā esošo tehnoloģiju kaudzi. Saglabājiet šo informāciju pēc iespējas necaurspīdīgāku.
Java drošības noteikums Nr. 8: atjauniniet drošības laidienus
Sākot ar 2019. gadu, Oracle ir ieviesusi jaunu Java licencēšanas shēmu un izlaišanas grafiku. Diemžēl izstrādātājiem jaunā izlaišanas kadence neko neatvieglo. Tomēr jūs esat atbildīgs par drošības atjauninājumu biežu pārbaudi un to lietošanu savos JRE un JDK.
Pārliecinieties, vai zināt, kādi kritiskie ielāpi ir pieejami, regulāri pārbaudot, vai Oracle mājas lapā nav drošības brīdinājumu. Katru ceturksni Oracle piegādā automatizētu ielāpu atjauninājumu pašreizējam Java LTS (ilgtermiņa atbalsts) izlaidumam. Problēma ir tāda, ka plāksteris ir pieejams tikai tad, ja maksājat par Java atbalsta licenci.
Ja jūsu organizācija maksā par šādu licenci, ievērojiet automātiskās atjaunināšanas maršrutu. Ja nē, jūs, iespējams, izmantojat OpenJDK, un jums būs pašam jāveic lāpīšana. Šajā gadījumā jūs varat lietot bināro plāksteri vai vienkārši aizstāt esošo OpenJDK instalāciju ar jaunāko versiju. Alternatīvi, jūs varētu izmantot komerciāli atbalstītu OpenJDK, piemēram, Azul's Zulu Enterprise.
Vai jums ir nepieciešams katrs drošības plāksteris?
Ja uzmanīgi vērojat drošības brīdinājumus, iespējams, jums nav nepieciešams noteikts atjauninājumu kopums. Piemēram, 2020. gada janvāra izlaidums parādās būt kritiskam Java atjauninājumam; tomēr, cieši lasot, tiek parādīts, ka atjauninājums aizlīmē tikai Java sīklietotņu drošības nepilnības un neietekmē Java serverus.
Java drošības noteikums Nr. 9: meklējiet atkarības ievainojamības
Ir pieejami daudzi rīki, lai automātiski meklētu koda bāzi un atkarības no ievainojamības. Viss, kas jums jādara, ir tos izmantot.
Atvērtā tīmekļa lietojumprogrammu drošības projekts OWASP ir organizācija, kas nodarbojas ar koda drošības uzlabošanu. OWASP uzticamo, augstas kvalitātes automatizēto kodu skenēšanas rīku sarakstā ir vairāki uz Java orientēti rīki.
Regulāri pārbaudiet savu koda bāzi, bet arī uzmaniet trešo personu atkarības. Uzbrucēju mērķis ir gan atvērtā, gan slēgta pirmkoda bibliotēkas. Uzmanieties, lai tiktu atjaunināti jūsu atkarības gadījumi, un atjauniniet sistēmu, kad tiek izlaisti jauni drošības labojumi.
Java drošības noteikums Nr. 10: pārraugiet un reģistrējiet lietotāju darbības
Pat vienkāršs brutālu spēku uzbrukums var būt veiksmīgs, ja jūs aktīvi nepārraugāt savu lietojumprogrammu. Izmantojiet uzraudzības un reģistrēšanas rīkus, lai sekotu lietotņu veselībai.
Ja vēlaties būt pārliecināts, kāpēc uzraudzība ir svarīga, vienkārši sēdiet un skatieties TCP paketes lietojumprogrammu klausīšanās portā. Jūs redzēsiet visu veidu darbības, kas pārsniedz vienkāršu lietotāju mijiedarbību. Daļa no šīs darbības būs roboti un ļaundari, kas meklē ievainojamības.
Jums jāpiesakās un jāuzrauga neveiksmīgi pieteikšanās mēģinājumi un jāveic pretpasākumi, lai attāli klienti netiktu uzbrukti nesodīti.
Uzraudzība var brīdināt jūs par neizskaidrojamiem pīķiem, un reģistrēšana var palīdzēt noskaidrot, kas pēc uzbrukuma noticis nepareizi. Java ekosistēma ietver daudz komerciālu un atvērta pirmkoda risinājumu reģistrēšanai un uzraudzībai.
Java drošības noteikums Nr. 11: Uzmanieties no pakalpojumu atteikuma (DoS) uzbrukumiem
Jebkurā laikā, kad apstrādājat potenciāli dārgus resursus vai veicat potenciāli dārgas darbības, jums vajadzētu pasargāties no pārmērīga resursu lietošanas.
Oracle savā drošo kodēšanas vadlīnijās Java SE dokumentam sadaļā "Pakalpojuma atteikums" uztur iespējamo vektoru sarakstu ar šāda veida problēmu.
Būtībā jebkurā laikā, kad dodaties veikt dārgu darbību, piemēram, saspiesta faila izpakošanu, jums jāuzrauga eksplodējoša resursu izmantošana. Neuzticieties failu manifestiem. Uzticieties tikai faktiskajam diska vai atmiņas patēriņam, uzraugiet to un pasargājiet no servera pārmērības.
Tāpat dažos procesos ir svarīgi skatīties uz neparedzētiem mūžīgiem cilpiem. Ja ir aizdomas, ka ir cilpa, pievienojiet aizsargu, kas nodrošina cilpa progresu, un īssavienojiet to, ja šķiet, ka tā ir kļuvusi zombija.
Java drošības noteikums # 12: Apsveriet iespēju izmantot Java drošības pārvaldnieku
Java ir drošības pārvaldnieks, kuru var izmantot, lai ierobežotu resursus, kuriem piekļuve darbojas. Tas var izolēt programmu attiecībā uz diska, atmiņas, tīkla un JVM piekļuvi. Šo prasību samazināšana jūsu lietotnei samazina iespējamo uzbrukuma radīto kaitējumu. Šāda izolācija var būt arī neērta, tieši tāpēc SecurityManager pēc noklusējuma nav iespējots.
Jums būs pašam jāizlemj, vai strādāt apkārt SecurityManagerStingrs viedoklis ir vērts papildu aizsardzības slāni jūsu lietojumprogrammām. Skatiet Oracle dokumentus, lai uzzinātu vairāk par Java drošības pārvaldnieka sintaksi un iespējām.
Java drošības noteikums # 13: Apsveriet iespēju izmantot ārēju mākoņa autentifikācijas pakalpojumu
Dažām lietojumprogrammām vienkārši ir jābūt viņu lietotāju datiem; pārējiem mākoņu pakalpojumu sniedzējiem varētu būt jēga.
Meklējiet apkārt un atradīsit vairākus mākoņa autentifikācijas nodrošinātājus. Šāda pakalpojuma priekšrocība ir tā, ka pakalpojumu sniedzējs ir atbildīgs par sensitīvu lietotāju datu drošību, nevis jūs. No otras puses, autentifikācijas pakalpojuma pievienošana palielina uzņēmuma arhitektūras sarežģītību. Daži risinājumi, piemēram, FireBase autentifikācija, ietver SDK integrēšanai visā kaudzē.
Secinājums
Esmu iepazīstinājis ar 13 noteikumiem drošāku Java lietojumprogrammu izstrādei. Šie noteikumi ir pārbaudīti un patiesi, taču vislielākais noteikums ir šāds: esiet aizdomīgs. Vienmēr programmatūras izstrādē izmantojiet piesardzību un uz drošību vērstu skatījumu. Meklējiet kodā ievainojamības, izmantojiet Java drošības API un pakotņu priekšrocības un izmantojiet trešo pušu rīkus, lai uzraudzītu un reģistrētu kodu drošības problēmu gadījumā.
Šeit ir trīs labi augsta līmeņa resursi, lai sekotu nepārtraukti mainīgajai Java drošības ainavai:
- OWASP Top 10
- CWE Top 25
- Oracle drošā koda vadlīnijas
Šo stāstu "Trīspadsmit noteikumi drošu Java lietojumprogrammu izstrādei" sākotnēji publicēja JavaWorld.
