Kolmetoista sääntöä turvallisten Java-sovellusten kehittämiseen

Tietoturva on yksi ohjelmistokehityksen monimutkaisimmista, laajimmista ja tärkeimmistä näkökohdista. Ohjelmistojen tietoturvasta jätetään usein huomiotta tai niitä yksinkertaistetaan vain muutamalla pienellä muutoksella kehitysjakson lopussa. Voimme nähdä tulokset vuosittaisessa suurten tietoturvaloukkausten luettelossa, joka vuonna 2019 oli yli 3 miljardia altistettua tietuetta. Jos se voi tapahtua Capital Onelle, se voi tapahtua sinulle.

Hyvä uutinen on, että Java on pitkäaikainen kehitysympäristö, jossa on monia sisäänrakennettuja turvaominaisuuksia. Java Security -paketti on läpikäynyt intensiivisen taistelutestauksen, ja sitä päivitetään usein uusien tietoturva-aukkojen varalta. Syyskuussa 2017 julkaistu uudempi Java EE Security -sovellusliittymä korjaa pilvi- ja mikropalveluarkkitehtuurien haavoittuvuudet. Java-ekosysteemi sisältää myös laajan valikoiman työkaluja turvakysymysten profilointiin ja raportointiin.

Jopa vankan kehitysalustan kanssa on tärkeää pysyä valppaana. Sovelluskehitys on monimutkainen yritys, ja haavoittuvuudet voivat piiloutua taustameluun. Sinun tulisi miettiä tietoturvaa sovelluksen kaikissa vaiheissa, luokan kielen ominaisuuksista API-päätepisteiden valtuutukseen.

Seuraavat perussäännöt tarjoavat hyvän perustan turvallisempien Java-sovellusten rakentamiselle.

Java-turvasääntö # 1: Kirjoita puhdas, vahva Java-koodi

Haavoittuvuudet piiloutuvat monimutkaisuudessa, joten pidä koodisi mahdollisimman yksinkertaisena toiminnallisuudesta tinkimättä. Käyttämällä todistettuja suunnitteluperiaatteita, kuten DRY (älä toista itseäsi), voit kirjoittaa koodin, joka on helpompi tarkistaa ongelmien varalta.

Paljasta koodissasi aina mahdollisimman vähän tietoja. Toteutustietojen piilottaminen tukee sekä ylläpidettävää että suojattua koodia. Nämä kolme vinkkiä vievät pitkän matkan turvallisen Java-koodin kirjoittamiseen:

Hyödynnä Java-käyttöoikeuksien muokkaajia. Tieto siitä, kuinka ilmoitetaan eri käyttöoikeustasot luokille, menetelmille ja niiden attribuuteille, auttaa suojaamaan koodiasi. Kaiken, mikä voidaan tehdä yksityiseksi, tulisi olla yksityistä.
Vältä pohdintaa ja itsetarkastusta. Joissakin tapauksissa tällaiset edistyneet tekniikat ansaitsevat, mutta suurimmaksi osaksi sinun tulisi välttää niitä. Heijastuksen käyttö eliminoi voimakkaan kirjoittamisen, mikä voi tuoda koodiin heikkoja kohtia ja epävakautta. Luokanimien vertaaminen merkkijonoina on virhealtista ja voi helposti johtaa nimiavaruuden törmäykseen.
Määritä aina pienimmät mahdolliset sovellusliittymä- ja liitäntäpinnat. Irrota komponentit ja anna niiden olla vuorovaikutuksessa pienimmällä mahdollisella alueella. Vaikka yksi sovelluksesi alue olisi tartunnan saanut, muut ovat turvassa.

Java-tietoturvasääntö # 2: Vältä sarjallisuutta

Tämä on toinen koodausvinkki, mutta se on tarpeeksi tärkeä ollakseen oma sääntö. Serialisointi vie etäsyötön ja muuntaa sen täysin varustelluksi objektiksi. Se luopuu rakentajista ja pääsymodifikaattoreista ja sallii tuntemattoman tietovirran tulla juoksevaksi koodiksi JVM: ssä. Tämän seurauksena Java-sarjallisuus on syvästi ja luonnostaan epävarmaa.

Java-sarjallisuuden loppu

Jos et ole vielä kuullut, Oraclella on pitkän aikavälin suunnitelmia poistaa sarjallisuus Java-ohjelmasta. Oraclen Java-alustaryhmän pääarkkitehti Mark Reinhold on sanonut uskovansa, että kolmasosa tai enemmän kaikista Java-haavoittuvuuksista liittyy sarjoitukseen.

Vältä niin paljon kuin mahdollista Java-koodin sarjallisuutta / esivalintaa. Harkitse sen sijaan sarjakuvamuodon, kuten JSON tai YAML, käyttöä. Älä koskaan, koskaan paljasta suojaamatonta verkon päätepistettä, joka vastaanottaa ja toimii sarjakuvavirtaan. Tämä ei ole muuta kuin tervetuliaismatto sekasortolle.

Java-suojaussääntö # 3: Älä koskaan paljasta salaamattomia kirjautumistietoja tai henkilökohtaisia tunnistetietoja

On vaikea uskoa, mutta tämä vältettävä virhe aiheuttaa kipua vuosi toisensa jälkeen.

Kun käyttäjä syöttää salasanan selaimeen, se lähetetään tekstiviestinä palvelimellesi. Sen pitäisi olla viimeinen kerta, kun se näkee päivänvalon. Sinä on pakko salaa salasana yksisuuntaisen koodin kautta, ennen kuin säilytät sen tietokantaan, ja tee se sitten uudelleen aina, kun verrataan kyseiseen arvoon.

Salasanoja koskevat säännöt koskevat kaikkia henkilökohtaisia tietoja (luottokortteja, sosiaaliturvatunnuksia jne.). Hakemukseesi uskottuja henkilötietoja tulisi käsitellä korkeimmalla huolellisuudella.

Salaamattomat tunnistetiedot tai PII tietokannassa ovat aukko turva-aukko, joka odottaa hyökkääjän löytävän. Älä koskaan kirjoita raakoja tunnistetietoja lokiin tai muuten lähetä tiedostoon tai verkkoon. Luo sen sijaan salasanoille suolattu hash. Muista tehdä tutkimuksesi ja käyttää suositeltua hajautusalgoritmia.

Siirry alas sääntöön # 4: käytä aina kirjastoa salaamiseen; älä heitä omaa.

Java-tietoturvasääntö # 4: Käytä tunnettuja ja testattuja kirjastoja

Pidä silmäsi tässä kysymyksessä ja vastauksessa oman turvallisuusalgoritmin käyttämisestä. Tl; dr-oppitunti on: käytä tunnettuja, luotettavia kirjastoja ja kehyksiä aina kun mahdollista. Tämä pätee kaikkialla, salasanan hajautuksesta REST API -valtuutukseen.

Onneksi Javalla ja sen ekosysteemillä on selkäsi täällä. Sovellusturvallisuuden kannalta Spring Security on tosiasiallinen standardi. Se tarjoaa laajan valikoiman vaihtoehtoja ja joustavuutta sovittamaan mihin tahansa sovellusarkkitehtuuriin, ja se sisältää useita suojausmenetelmiä.

Ensimmäisen vaistonne turvallisuuden torjunnassa tulisi olla tutkimuksen tekeminen. Tutki parhaita käytäntöjä ja sitten mitä kirjasto toteuttaa nämä käytännöt puolestasi. Jos esimerkiksi tarkastelet JSON-verkkotunnusten käyttöä todennuksen ja todennuksen hallintaan, katso Java-kirjasto, joka kapseloi JWT: n, ja opi sitten integroimaan se Spring Securityyn.

Jopa luotettavan työkalun avulla on melko helppo yhdistää valtuutus ja todennus. Muista liikkua hitaasti ja tarkista kaikki tekemäsi.

Java-turvasääntö # 5: Ole vainoharhainen ulkoisen syötteen suhteen

Riippumatta siitä, onko käyttäjä kirjoittanut lomakkeeseen, tietopalveluun tai etäsovellusliittymään, älä koskaan luota ulkoiseen tuloon.

SQL-injektio ja sivustojen välinen komentosarja (XSS) ovat vain yleisimmin tunnettuja hyökkäyksiä, jotka voivat johtua ulkoisen syötteen väärästä käsittelystä. Vähemmän tunnettu esimerkki - yksi monista - on "miljardin naurun hyökkäys", jolloin XML-entiteettilaajennus voi aiheuttaa palvelunestohyökkäyksen.

Aina kun saat syötteitä, ne on tarkistettava ja puhdistettava. Tämä pätee erityisesti mihin tahansa, joka voidaan esittää toiselle työkalulle tai järjestelmälle käsittelyä varten. Esimerkiksi, jos jokin voisi loppua argumenttina käyttöjärjestelmän komentoriville: varokaa!

Erityinen ja tunnettu ilmentymä on SQL-injektio, jota käsitellään seuraavassa säännössä.

Java-suojaussääntö # 6: Käytä aina valmisteltuja lauseita SQL-parametrien käsittelemiseen

Aina kun rakennat SQL-käskyn, vaarana on interpoloida suoritettavan koodin fragmentti.

Tietäen tämän, se on hyvä käytäntö aina käytä java.sql.PreparedStatement-luokkaa SQL: n luomiseen. Samanlaiset palvelut ovat olemassa NoSQL-kaupoissa, kuten MongoDB. Jos käytät ORM-tasoa, toteutus käyttää Valmisteltu lausuntos sinulle hupun alla.

Java-suojaussääntö # 7: Älä paljasta toteutusta virhesanomien kautta

Tuotantovirheilmoitukset voivat olla hyödyllinen tietolähde hyökkääjille. Etenkin pinonjäljet voivat paljastaa tietoa käyttämästäsi tekniikasta ja siitä, miten käytät sitä. Vältä pinon jälkien paljastamista loppukäyttäjille.

Epäonnistuneet sisäänkirjautumisilmoitukset kuuluvat myös tähän luokkaan. On yleisesti hyväksyttyä, että virheilmoitus tulisi antaa muodossa "Sisäänkirjautuminen epäonnistui" tai "Ei löytänyt kyseistä käyttäjää" tai "Virheellinen salasana". Tarjoa mahdollisimman vähän apua potentiaalisesti turhille käyttäjille.

Ihannetapauksessa virheilmoitukset eivät saisi paljastaa sovelluksesi taustalla olevaa tekniikkapinoa. Pidä nämä tiedot mahdollisimman läpinäkymättöminä.

Java-tietoturvasääntö # 8: Pidä tietoturvapäivitykset ajan tasalla

Vuodesta 2019 Oracle on ottanut käyttöön uuden lisensointijärjestelmän ja julkaisuaikataulun Javalle. Valitettavasti kehittäjille uusi julkaisutahti ei tee asiat helpommaksi. Siitä huolimatta olet vastuussa tietoturvapäivitysten usein tarkistamisesta ja niiden soveltamisesta JRE: hen ja JDK: hon.

Varmista, että tiedät, mitä kriittisiä korjaustiedostoja on saatavilla, tarkistamalla säännöllisesti Oraclen etusivulta tietoturvavaroitukset. Oracle toimittaa joka vuosineljänneksen automatisoidun korjaustiedoston nykyiselle Java: n LTS (long-term-support) -julkaisulle. Ongelmana on, että korjaustiedosto on käytettävissä vain, jos maksat Java-tukilisenssistä.

Jos organisaatiosi maksaa tällaisesta lisenssistä, noudata automaattisen päivityksen reittiä. Jos ei, käytät todennäköisesti OpenJDK: ta, ja sinun on tehtävä korjaus itse. Tässä tapauksessa voit käyttää binaarista korjaustiedostoa tai yksinkertaisesti korvata nykyisen OpenJDK-asennuksesi uusimmalla versiolla. Vaihtoehtoisesti voit käyttää kaupallisesti tuettua OpenJDK: ta, kuten Azulin Zulu Enterprise.

Tarvitsetko jokaisen tietoturvakorjauksen?

Jos katsot turvallisuushälytyksiä tarkasti, saatat huomata, että et tarvitse tiettyjä päivityksiä. Esimerkiksi tammikuun 2020 julkaisu tulee näkyviin olla kriittinen Java-päivitys; Tarkka lukeminen osoittaa kuitenkin, että päivitys korjaa vain Java-sovelmien suojauksen aukot eikä vaikuta Java-palvelimiin.

Java-tietoturvasääntö # 9: Etsi riippuvuushaavoittuvuuksia

Tarjolla on monia työkaluja, joiden avulla kooditietokanta ja riippuvuudet voidaan tarkistaa automaattisesti haavoittuvuuksien varalta. Sinun tarvitsee vain käyttää niitä.

OWASP, Open Web Application Security Project, on organisaatio, joka on sitoutunut parantamaan koodin turvallisuutta. OWASP: n luettelo luotettavista, laadukkaista automaattisista koodiskannaustyökaluista sisältää useita Java-suuntautuneita työkaluja.

Tarkista koodikanta säännöllisesti, mutta pidä myös silmällä kolmansien osapuolten riippuvuuksia. Hyökkääjät kohdentavat sekä avoimen että suljetun lähdekoodin kirjastoja. Seuraa riippuvuuksien päivityksiä ja päivitä järjestelmäsi, kun uusia suojauskorjauksia julkaistaan.

Java-turvasääntö # 10: Seuraa ja kirjaa käyttäjien toimintaa

Jopa yksinkertainen raakavoimainen hyökkäys voi olla onnistunut, jos et seuraa aktiivisesti sovellustasi. Käytä seuranta- ja lokityökaluja seurataksesi sovelluksen kuntoa.

Jos haluat olla vakuuttunut siitä, miksi seuranta on tärkeää, istu vain katsomalla TCP-paketteja sovellusten kuunteluportissa. Näet kaikenlaisia aktiviteetteja, paljon enemmän kuin yksinkertaiset käyttäjien vuorovaikutukset. Osa toiminnasta on robotteja ja pahantekijöitä, jotka etsivät haavoittuvuuksia.

Sinun tulisi kirjata ja seurata epäonnistuneita kirjautumisyrityksiä ja ottaa käyttöön vastatoimia estääkseen etäasiakkaita hyökkäämästä rankaisematta.

Valvonta voi varoittaa selittämättömistä piikeistä, ja kirjaaminen voi auttaa selvittämään, mikä meni pieleen hyökkäyksen jälkeen. Java-ekosysteemi sisältää runsaasti kaupallisia ja avoimen lähdekoodin ratkaisuja kirjaamiseen ja seurantaan.

Java-tietoturvasääntö # 11: Varo palvelunestohyökkäyksiä (DoS)

Aina kun käsittelet mahdollisesti kalliita resursseja tai teet mahdollisesti kalliita toimintoja, sinun on varottava resurssien pakenemista.

Oracle ylläpitää luetteloa tämäntyyppisten ongelmien mahdollisista vektoreista Secure Coding Guidelines for Java SE -asiakirjassa, Palvelun estäminen -otsikossa.

Pohjimmiltaan, milloin tahansa suoritat kalliita toimintoja, kuten purat pakatun tiedoston, sinun tulee tarkkailla räjähtävää resurssien käyttöä. Älä luota tiedostomuotoihin. Luota vain todelliseen levyn tai muistin kulutukseen, tarkkaile sitä ja varo palvelinta polviin viemistä.

Vastaavasti joissakin käsittelyissä on tärkeää tarkkailla odottamattomia ikuisia silmukoita. Jos silmukka epäillään, lisää suoja, joka varmistaa, että silmukka etenee, ja oikosulje se, jos se näyttää menneen zombiksi.

Java-suojaussääntö # 12: Harkitse Java-suojauksen hallinnan käyttöä

Java: lla on suojauksenhallinta, jota voidaan käyttää käynnissä olevan prosessin resurssien rajoittamiseen. Se voi eristää ohjelman levyn, muistin, verkon ja JVM-pääsyn suhteen. Näiden sovelluksesi vaatimusten supistaminen vähentää hyökkäyksestä mahdollisesti aiheutuvien haittojen määrää. Tällainen eristäminen voi olla myös hankalaa, minkä vuoksi Turvallisuuspäällikkö ei ole oletusarvoisesti käytössä.

Sinun on itse päätettävä, työskenteletkö TurvallisuuspäällikköVankat mielipiteet ansaitsevat ylimääräisen suojaustason sovelluksillesi. Oracle-asiakirjoista saat lisätietoja Java-tietoturvahallinnan syntaksista ja ominaisuuksista.

Java-suojaussääntö # 13: Harkitse ulkoisen pilvitodennuspalvelun käyttöä

Joidenkin sovellusten on yksinkertaisesti omistettava käyttäjätiedot; muille pilvipalvelujen tarjoaja voisi olla järkevää.

Tee hakuja ympärilläsi ja löydät joukon pilvitodennuksen tarjoajia. Tällaisen palvelun etuna on, että palveluntarjoaja on vastuussa arkaluontoisten käyttäjätietojen suojaamisesta, et sinä. Toisaalta todennuspalvelun lisääminen lisää yrityksen arkkitehtuurin monimutkaisuutta. Jotkut ratkaisut, kuten FireBase-todennus, sisältävät SDK: t pinon yli integroimiseksi.

Johtopäätös

Olen esittänyt 13 sääntöä turvallisempien Java-sovellusten kehittämiseksi. Nämä säännöt ovat kokeiltuja ja totta, mutta kaikkien suurin sääntö on tämä: ole epäilyttävä. Ohjelmistokehitykseen on aina suhtauduttava varovasti ja turvallisuuspoliittisesti. Etsi haavoittuvuuksia koodistasi, hyödynnä Java-tietoturvasovellusliittymiä ja paketteja ja käytä kolmannen osapuolen työkaluja koodisi valvontaan ja kirjaamiseen suojausongelmiin.

Tässä on kolme hyvää korkean tason resurssia pysymään ajan tasalla alati muuttuvasta Java-tietoturvasta: