Siirry pääsisältöön

Production Hardening

Avaa ChatGPT:ssä

webforJ:n server-driven model ja sisäänrakennetut suojat yleisiä uhkia vastaan kattavat paljon, mutta turvallinen käyttöönotto riippuu silti siitä, miten käytät sovellusta. Alla olevat vaiheet täydentävät kokonaiskuvaa.

Salakirjoita jokainen yhteys

Käytä tuotantoliikennettä vain HTTPS:n yli. Päätä TLS kontissa, proxyssä tai kuormantasaimessa sovelluksen edessä, ja ohjaa jokaiseen tavalliseen HTTP-pyyntöön sen turvallinen vastine, jotta tunnistetiedot ja istuntotunnukset eivät koskaan kulje salaamattomina.

Älä luota mihinkään selaimesta

Manipuloitu asiakas voi lähettää mitä tahansa. Vahvista jokainen arvo, jonka koodisi vastaanottaa, jopa arvot, jotka käyttöliittymäsi on jo rajoittanut, ennen kuin tallennat tai käytät niitä. Asiakas/palvelin -vuorovaikutus -artikkeli selittää, miksi palvelin on ainoa paikka, jossa sääntö voi todella pitää.

webforJ:n tietojen sitominen ja validoiminen auttaa tässä: koska sitominen tapahtuu Javassa palvelimella, mallit, joihin lisäät rajoja, mukaan lukien Jakarta-validointi, valvotaan palvelinpuolella eikä vain selaimessa. Käsittele tätä eheyden kerroksena, ei puolustuksena injektointi- tai muotoilu hyökkäyksiä vastaan, jotka tarvitsevat edelleen käsittelyä, joka on kuvattu Yleisissä uhkissa -artikkelissa.

Poistettu ja piilotettu eivät ole turvallisuutta

setEnabled(false) ja setVisible(false) ovat käyttöliittymän vihjeitä, eivät pääsynvalvontaa. webforJ heijastaa ohjaimen poistettua tilaa asiakkaalle, mutta se ei estä manipuloitua asiakasta palauttamasta ohjainta käyttöön ja käynnistämästä sen toimintoa. Älä koskaan luota poistettuun tai piilotettuun ohjaimeen estääksesi jotain tapahtumasta.

Laita todellinen sääntö palvelinpuolen käsittelijään: varmista, että käyttäjällä on oikeudet ja että ennakkoehdot ovat voimassa ennen toimintoa, juuri kuten toimisit, jos ohjain olisi ollut koko ajan käytössä. Poistetila opastaa rehellisiä käyttäjiä; palvelinpuolen sääntö estää epärehellisiä.

Rajaa näkymäsi

Rajoita näkymiä reittiturvalla, jotta jokainen vaatii oikean todistamisen ja roolit. Anna ihmisille kapein mahdollinen pääsy, joka mahdollistaa heidän työnsä, ja suosii oletusarvoista turvattua lähestymistapaa, jossa merkitsemätön reitti vaatii edelleen sisäänkirjautumisen.

Pidä salaisuudet ulkopuolella

Tunnistetiedot, avaimet ja tokenit eivät kuulu koodiin tai varastoosi. Hae ne ympäristöstä tai ulkoisesta lähteestä sen sijaan, kuten on esitetty Salausten hallinnassa.

Pidä kehitystyökalut pois päältä

craftforJ on kehitysympäristö, joka tarkkailee toimivaa sovellusta ja kirjoittaa muutokset takaisin sen Java-lähteeseen. Se vaatii sekä webforj.debug että webforj.devtools.craftforj.enabled, ja oletuksena se vastaa vain koneelle, jossa sovellus toimii. Projekti, joka on luotu startforJ avulla tai webforJ:n archetypestä, on molemmat asetukset käytössä kehitykselle, joten varmista ne sen sijaan, että olettaisit.

Tarkista, että molemmat ominaisuudet ovat asetettuina joko pois päältä tai false konfiguraatiossa, jonka todella otat käyttöön, mukaan lukien ympäristömuuttuja tai profiili, joka koskee vain tuotantoa. Lataa sitten otettu sovellus ja varmista, että mitään craftforJ:ta laukaisevaa tapahtumaa ei näy sivulla. Katso craftforJ:n turvallisuudesta täydellisen kuvan saamiseksi.

Pidä riippuvuudet ajan tasalla

Kirjastot, jotka otat käyttöön, ovat suurempi riskilähde kuin oma koodisi. Seuraa ilmoituksia, päivitä webforJ:tä ja muita riippuvuuksia säännöllisesti, ja kun korjattu versio välittömästä kirjastosta julkaistaan ennen kirjastoa, joka tuo sen käyttöön, lukitse korjattu versio pom.xml:ssäsi.

Epäonnistu hiljaisesti

Älä anna pinojälkien, tiedostopolkujen tai sisäisten tunnisteiden saavuttaa loppukäyttäjiä. Tallenna tiedot palvelinlokkeihisi ja esitä yksinkertainen, yleinen viesti käyttöliittymässä. Rekisteröi mukautettu käsittelijä webforJ:n virheenkäsittelyssä, jotta käsittelemättömät poikkeukset näyttävät hallitun sivun raakojen diagnostiikoiden sijaan.

Ilmoita vastuullisesti

Löysitkö mahdollisen virheen itse webforJ:ssä? Ilmoita siitä yksityisesti GitHubin yksityisen haavoittuvuuden raportoinnin kautta sen sijaan, että avaisit julkisen ongelman tai vetopyynnön, jotta korjaus voi saapua ennen kuin tiedot ovat tiedossa.