Unohdetut staging- ja testipalvelimet: osa, jota kukaan ei valvo

Unohdettu staging- tai testipalvelin on kopio verkkosivustostanne tai sovelluksestanne, joka pystytettiin kehitystä varten ja jäi sitten pyörimään internetiin. Sen nimi on yleensä esimerkiksi staging.yourcompany.com, dev.yourcompany.com tai test2.yourcompany.com, kukaan ei enää tarkista sitä, ja siinä on usein vanhempaa koodia ja heikommat asetukset kuin tuotannossa.

Nämä palvelimet ovat merkittäviä, koska ne kuuluvat yrityksenne internetiin näkyvään osaan, vaikka kukaan ei kohtele niitä sellaisina. Ne eivät saa samoja päivityksiä, kirjautumissuojauksia tai valvontaa kuin pääsivusto, mutta jakavat silti usein samat tietokantakopiot, API-avaimet ja ylläpitäjätunnukset.

Hyvä uutinen: ne on helppo löytää, ja kun ne on löydetty, korjaus on yleensä yksinkertainen. Tässä artikkelissa näytämme, miten niitä etsitään ja mitä kullekin tehdään.

Miksi staging-palvelimet unohtuvat

Staging-palvelin luodaan hyvästä syystä: julkaisu testataan, ennen kuin asiakkaat näkevät sen. Sitten julkaisu valmistuu, kehittäjä siirtyy toiseen projektiin tai sopimus kumppanitoimiston kanssa päättyy, ja palvelin jää käyntiin, koska sen sammuttaminen ei koskaan ollut kenenkään tehtävälistalla. Tavallisia piirteitä:

• Täysi kopio tuotannosta, myös tuore tietokantavedos, jotta testaus näyttäisi todenmukaiselta.
• Päälle jäänyt debug-tila, joka näyttää pinojäljet, asetusarvot tai sovelluskehyksen tiedot.
• Oletus- tai yhteiset ylläpitosalasanat, jotka olivat "vain testausta varten".
• Vanhat versiot julkaisujärjestelmästä, lisäosista tai kirjastoista, jotka tuotannossa on jo päivitetty.
• Ei HTTPS:ää tai varmenne, joka vanheni kuukausia sitten.
• Hakukoneindeksointia ei koskaan estetty, joten testisivusto näkyy hakutuloksissa oikean rinnalla.

Mikään näistä ei yksinään ole dramaattista. Yhdessä ne tarkoittavat, että omassa verkkotunnuksessanne on palvelin, joka on heikompi kuin kaikki sen ympärillä.

Miten nämä palvelimet tulevat näkyviin

Staging-palvelimen löytyminen ei vaadi, että joku julkaisee siihen linkin. 3 yleistä tapaa:

1. Certificate Transparency. Kun nimelle staging.yourcompany.com myönnetään selainten luottama varmenne, nimi kirjataan kaikkien nähtäville lokeihin (protokolla on kuvattu dokumentissa RFC 9162). Kuka tahansa voi hakea näistä lokeista, kuten selitämme artikkelissa Certificate Transparency -lokit selitettynä.
2. DNS-tietueet. Tietue, joka yhä osoittaa palvelimeen, tekee siitä tavoitettavan nimellä, ja arvattavia nimiä, kuten dev, test ja beta, kokeillaan ensimmäisinä.
3. Hakukoneet ja arkistot. Testisivusto ilman indeksointisääntöjä voi näkyä hakutuloksissa, ja vanhat sivut säilyvät verkkoarkistoissa.

Miten löydätte omat unohdetut palvelimenne

Aloittakaa nimistä ja tarkistakaa sitten jokainen.

1. Hakekaa palvelusta crt.sh hakulausekkeella %.yourcompany.com ja kerätkää kaikki palvelinnimet.
2. Käykää DNS-vyöhykkeenne läpi nimien, kuten dev, stage, staging, test, uat, beta, old, demo ja preview, varalta.
3. Selvittäkää kunkin osoite ja tarkistakaa vastaus:

dig +short staging.yourcompany.com
curl -sI https://staging.yourcompany.com

1. Avatkaa jokainen palvelin selaimessa ja kysykää: näkyykö siinä oikeita asiakastietoja, kirjautumislomake, debug-sivu, palvelimen oletussivu tai hosting-alustan virheilmoitus?
2. Etsikää tiedostoja, joita ei pitäisi koskaan tarjoilla. OWASPin testausopas käsittelee tätä kohdassa WSTG-CONF-04 ja toteaa, että varmuuskopiotiedostot tarjoillaan yleensä pelkkänä tekstinä sen sijaan, että ne suoritettaisiin. Artikkelissamme avoimista .env-, .git- ja varmuuskopiotiedostoista luetellaan tavalliset nimet.

Jos nimi osoittaa hosting-alustaan, joka näyttää sivun "no such app" tai "bucket not found", käsitelkää asiaa kiireellisenä: se on klassinen asetelma aliverkkotunnuksen kaappaukselle.

Mitä kullekin tehdään

Valitkaa jokaiselle staging- tai testipalvelimelle yksi 3 vaihtoehdosta.

Poistakaa se. Jos kukaan ei osaa nimetä sen omistajaa ja tarkoitusta, sammuttakaa palvelin ja poistakaa DNS-tietue. Poistakaa tietue palvelimen jälkeen, ei ennen, älkääkä koskaan jättäkö CNAME-tietuetta osoittamaan palveluun, josta ette enää maksa.

Rajoittakaa pääsyä. Jos tiimi tarvitsee palvelinta yhä, siirtäkää se tunnistautumisen tai IP-sallintalistan taakse. HTTP Basic -tunnistautuminen on nopea lisätä, mutta MDN huomauttaa, että sitä on käytettävä HTTPS:n yli, koska tunnukset on vain base64-koodattu. VPN tai identiteettiin perustuva välityspalvelin on parempi pitkän aikavälin ratkaisu.

Siivotkaa se. Stagingissa ei pidä olla oikeita asiakastietoja. Käyttäkää generoitua tai peitettyä dataa, erillisiä API-avaimia rajatuin oikeuksin ja kytkekää debug-tulosteet pois.

Hakukoneiden pitäminen poissa on hyödyllistä, mutta se ei ole suojaus. Google dokumentoi noindex-ohjeen tavaksi pitää sivut poissa hakutuloksista, joko tagilla <meta name="robots" content="noindex"> tai otsakkeella X-Robots-Tag (Google Search Central). Sivu on silti kenen tahansa tavoitettavissa, joka tietää osoitteen.

X-Robots-Tag: noindex

Lyhyt tarkistuslista

• Jokaisella tuotannon ulkopuolisella palvelimella on nimetty omistaja ja päättymispäivä.
• Stagingissa ei ole oikeita asiakastietoja.
• Staging vaatii kirjautumisen tai on VPN:n takana.
• Debug-tila pois, erilliset avaimet, ei yhteisiä ylläpitosalasanoja.
• Varmenne on voimassa, muuten palvelin poistetaan.
• DNS-tietueet poistetaan palvelimen mukana.
• Luettelo käydään läpi jokaisen projektin päätyttyä, ei kerran vuodessa.

Datahorsesin rooli

Datahorses valvoo yritystänne ulkoa päivittäin, myös uusia palvelinnimiä verkkotunnustenne alla, unohdettuja aliverkkotunnuksia ja testipalvelimia sekä niillä näkyviä tiedostoja. Jokaisen havainnon mukana tulevat tarkat korjausohjeet kehittäjällenne. Emme mene järjestelmiinne emmekä tarvitse pääsyoikeuksia. Katsokaa, mitä valvomme ja mitä tapahtuu, kun löydämme jotain.