Du har sikkert hørt om HTTPS, og hvordan den grønne hængelås i din browser giver os ro i sindet. Men i app-udviklingens verden er det ikke altid nok at stole blindt på, at certifikatet er gyldigt. Der er en latent risiko, hvor nogen, selv med en krypteret forbindelse, i hemmelighed kan lytte til, hvad der sker mellem din enhed og serveren.
For at imødegå denne sikkerhedssårbarhed er der opstået en teknik kaldet Certificate Pinning . Den fortæller i bund og grund vores applikation: "Stol ikke på en hvilken som helst certifikatmyndighed; accepter kun forbindelsen, hvis serveren præsenterer netop dette certifikat eller denne offentlige nøgle." Det er som at sætte en meget streng gatekeeper ved døren til vores kommunikation.
Hvad er SSL Pinning præcist, og hvorfor har vi brug for det?
For at forstå dette ordentligt, skal vi først huske, at standard HTTPS er baseret på en tillidskæde . Når du opretter forbindelse til en server, sender den dig sit digitale certifikat. Din mobilenhed kontrollerer, at dette dokument er blevet underskrevet af en certifikatmyndighed (CA), som operativsystemet har tillid til. Hvis signaturen er gyldig, og certifikatet ikke er udløbet, er forbindelsen etableret.
Problemet opstår, når en angriber formår at infiltrere forbindelsen midt i processen, det berygtede Man-in-the-Middle (MITM)-angreb . Hvis hackeren får en certifikatmyndighed (CA) til at udstede et falsk, men gyldigt certifikat, eller hvis de formår at installere et ondsindet rodcertifikat på offerets enhed, vil operativsystemet godkende forbindelsen. På det tidspunkt kan angriberen opsnappe og ændre følsomme data, såsom bankoplysninger eller adgangskoder, uden at brugeren bemærker noget usædvanligt.
Det er her, pinning kommer ind i billedet. I stedet for at stole på en anerkendt CA gemmer appen en kopi af serverens certifikat eller offentlige nøgle-hash. Under handshake sammenligner appen det modtagne certifikat med det, den har gemt. Hvis de ikke matcher bit for bit, afbrydes forbindelsen øjeblikkeligt, hvilket forhindrer server-spoofing.
Typer af forankring: Certifikater versus offentlige nøgler
Ikke al fastlåsning udføres på samme måde. Afhængigt af hvad vi beslutter at "fastlåse", har vi to primære tilgange. Den første er Certificate Pinning , hvor vi gemmer hele certifikatfilen (.pem eller .der). Det er den enkleste løsning at implementere, men den mest besværlige at vedligeholde, da vi skal opdatere applikationen i butikken hver gang servercertifikatet udløber og fornyes, ellers mister brugerne tjenesten.
Den anden mulighed er Public Key Pinning . I dette tilfælde gemmer vi kun hashen (normalt SHA-256) af certifikatets offentlige nøgle. Den største fordel er, at den offentlige nøgle kan forblive intakt, selvom certifikatet fornyes, hvilket giver os større certifikatfleksibilitet og reducerer hyppigheden af tvungne appopdateringer. Desuden er koden renere og vanskeligere at udtrække for en person, der forsøger reverse engineering, ved kun at gemme en hash.
Teknisk implementering på forskellige platforme
Hvis vi arbejder med AndroidDen mest moderne måde er at bruge filen network_security_config.xmlI denne XML-fil definerer vi domænerne og hasherne for de certifikater (pins), vi vil autorisere, hvilket giver os mulighed for at Aktivér vigtige sikkerhedsindstillinger på Android native. Så linker vi blot denne fil i AndroidManifest.xmlTidligere blev mere komplekse ting gjort ved at overskrive klassen. DefaultHttpClient og administration af Java-certifikatlagre via keytoolDen XML-baserede konfiguration er dog meget mere effektiv.
I økosystemet af iOSTingene ændrer sig lidt. Vi kan drage fordel af App Transport Security (ATS) ved at konfigurere filen Info.plist at definere de forankrede domæner. For at opnå fuld kontrol er det dog almindeligt at implementere runtime-validering ved hjælp af URLSessionDelegateI autentificeringsudfordringsmetoden udtrækker vi certifikatet fra serveren og sammenligner det med lokalt lagret certifikat i applikationspakken.
Til dem der bruger Kondensator- eller hybridstrukturerDer er plugins som f.eks. @capgo/capacitor-ssl-pinning der forener processen. I disse tilfælde udføres konfigurationen normalt i appens konfigurationsfil, hvor certifikatlisten specificeres og validering aktiveres. Det er vigtigt at teste disse implementeringer med værktøjer som f.eks. Charles Proxy, der simulerer et MITM-angreb for at bekræfte, at applikationen effektivt afviser forbindelsen, når certifikatet ikke er det forventede.
Risici, begrænsninger og vedligeholdelse
Pinning er ikke kun solskin og roser. Den største fare er det, der kaldes udløbsspærring . Hvis servercertifikatet udløber, og du ikke har opdateret appen med den nye pinkode, vil alle dine brugere opleve forbindelsesfejl. For at undgå denne katastrofe er den bedste fremgangsmåde at implementere backup-pinkoder . Vi gemmer hashen af en sekundær offentlig nøgle, som vi kun bruger i tilfælde af en nødsituation eller uventet rotation.
På den anden side kan pinning være en hovedpine for udviklere, der har brug for at debugge deres kommunikation. For at overvågningsværktøjer kan fungere, er det nogle gange nødvendigt at deaktivere pinning i udviklingsmiljøer eller oprette specifikke debug-versioner, og altid sørge for, at denne funktionalitet er aktiveret i den produktionsversion, der når slutbrugeren.
Hvad angår internettet, var Chrome en pioner inden for implementering af lignende koncepter. Det bruger HSTS (HTTP Strict Transport Security) til at håndhæve brugen af HTTPS og vedligeholder en liste over "forudindlæste" websteder for at forhindre sårbarhed ved første kontakt. Selvom HPKP-standarden eksisterede for internettet, gik den til sidst ud af brug, fordi den var for risikabel og kunne gøre websteder utilgængelige, hvis der opstod en konfigurationsfejl.
Implementering af certifikatfastlåsning er en strategisk beslutning, der balancerer maksimal sikkerhed med tjenestens funktionalitet. Ved at begrænse tillid til specifikke enheder beskytter vi kommunikationen mod sofistikerede angreb, forudsat at vi opretholder streng kontrol over livscyklussen for vores nøgler og certifikater for at undgå, at kunderne mister adgang.
