Share
Takket være HTML5 overføres flere og flere av en applikasjons logikk fra server-side til klientsiden. Dette krever at frontend-utviklere fokuserer mer på sikkerhet. I denne artikkelen vil jeg vise deg hvordan du gjør appene dine sikrere. Jeg vil fokusere på teknikker som du kanskje ikke har hørt om, i stedet for bare å fortelle deg at du må unnslippe HTML-data innført av brukere.
Selvfølgelig vil jeg ikke at du skal tjene innholdet ditt med FTP eller vanlig TCP. Hva jeg mener er at hvis du vil at brukerne skal være trygge når du bruker nettstedet ditt, må du bruke SSL (HTTPS). Og ikke bare for innloggingssteder, eller verdifull informasjon. For alt innholdet ditt. Ellers, når noen får tilgang til appen din fra et offentlig nettverk, kan det som de ser, misforstå av noen hacker i dette nettverket. Dette kalles et main-in-the-middle angrep:
Når du bruker SSL, krypteres alle dataene før den sendes, så selv om angriperen får det, ville han ikke kunne endre eller fange den. Dette er langt det viktigste trinnet i å sikre appen din.
Denne HTTP-headeren kan komme til nytte hvis du vil tjene innholdet ditt bare ved hjelp av SSL. Når den er utstedt av serveren (eller en tag, men det vil tillate minst en forespørsel å være HTTP), ingen usikker trafikk kommer fra nettleseren til serveren din. Det brukes slik:
Strenge-Transport-Sikkerhet: Maks-alder = 3600; includeSubDomains
De includeSubDomains del er valgfritt, det tillater deg å erklære at du også vil at alle underdomenene skal åpnes ved hjelp av HTTPS. De max-age alternativet angir hvor lenge (i sekunder) sidene skal vises ved hjelp av SSL. Dessverre, bare Firefox, Chrome og Opera støtter Strict Transport Security.
En annen måte å ytterligere forbedre sikkerheten på både HTTP og HTTPS er disse to cookieattributtene: Sikre og kun http. Den første lar en informasjonskapsel kun sendes på SLL-tilkobling. Den andre kan høres ut som det motsatte, men det er det ikke. Det forteller nettleseren at cookien kun kan nås ved hjelp av HTTP (S) -protokollen, slik at den ikke kan bli stjålet ved hjelp av for eksempel JavaScript document.cookie.
Innholdsikkerhetspolicy lar deg definere opprinnelsen til alle skript, bilder etc. på nettstedet ditt.
Hvis du tror at XSS-filteret ditt vil stoppe alle mulige XSS-angrep, må du kontrollere hvor mange måter det er å utføre disse angrepene, og tenk igjen. Selvfølgelig sikrer appen din om å stoppe alle disse, kanskje et problem, og kan sakte det ned, men det er en løsning.
Det kalles Content Security Policy. Det lar deg definere opprinnelsen til alle skript, bilder etc. på nettstedet ditt. Det blokkerer også alle inline-skript og -stiler, så selv om noen kan injisere et skriptmerke i en kommentar eller post, vil koden ikke bli utført. CSP er en HTTP-header (som også kan settes ved hjelp av HTML tag), som ser slik ut:
Innholdsikkerhetspolicy: policy
Hvor Politikk er et sett med CSP-direktiver. Her er de mulige alternativene:
Hvis et direktiv ikke er angitt, antar nettleseren at alle opphav er tillatt. Dette kan endres ved å sette inn default-src alternativ. Det du setter der vil bli brukt på alle ubestemte direktiver. Det er også en sandkasse alternativ, som gjør at nettsiden lastes som en iframe med sandkasse Egenskap. Et eksempel på bruk av CSP-overskriften vil se slik ut:
Innholdsikkerhetspolicy: standard-src: "selv"; script-src: https://apis.google.com;
Det tillater at alle eiendelene lastes bare fra programmets opprinnelse (den 'selv' attributt) og lar deg også laste inn skript fra Google APIs-serveren. Det er mye fleksibilitet når du definerer CSP, og når det brukes riktig, vil det forbedre sikkerheten til websiden din sterkt.
Tingen å huske når du bruker CSP, er at som standard ikke alle inline JavaScript vil bli utført. Dette inkluderer også:
Accentsconagua
javascript webadresser: som Dette skyldes at nettleseren ikke kan skille din inlinekode fra hackerens inline-kode. Du må erstatte dem ved å legge til hendelseslyttere med addEventListener eller noe rammeverk tilsvarende. Dette er ikke en dårlig ting i siste instans, da det tvinger deg til å skille programmets logikk fra den grafiske representasjonen som du bør gjøre uansett. CSP også (som standard) blokkerer alt eval ()-ish kode, inkludert strenger i setInterval/setTimeout og kode som ny funksjon ('return false').
CSP er tilgjengelig i de fleste av de moderne nettleserne. Firefox, Chrome og Opera (også mobil) bruker standarden Content-Security-politikk Overskrift. Safari (iOS også) og Chrome for Android bruker X-WebKit-CSP Overskrift. IE10 (med støtte begrenset kun til sandkasse direktiv) bruker X-Content-Security-politikk. Så, takket være Internet Explorer, kan du ikke bare bruke bare CSP (med mindre du vil bruke noe som Google Chrome Frame), men du kan fortsatt bruke den til å forbedre sikkerheten på de riktige nettleserne og forberede appen din til fremtiden.
JSONP er for tiden den mest brukte teknikken for å få ressurser fra andre servere til tross for samme opprinnelsespolitikk. Vanligvis oppretter du bare tilbakeringingsfunksjonen i koden din og sender navnet på den funksjonen til nettadressen som du vil hente dataene fra, slik:
funksjon parseData (data) ...
Men ved å gjøre dette skaper du en stor sikkerhetsrisiko. Hvis serveren du får data fra, er kompromittert, kan en hacker legge til sin ondsinnede kode og for eksempel stjele brukerens private data, fordi du faktisk får JavaScript ved hjelp av denne forespørselen - og nettleseren vil kjøre hele koden bare som med en vanlig skriptfil.
Løsningen her er Cross Resource Resource Sharing. Det tillater dataleverandøren å legge til en spesiell header i svar slik at du kan bruke XHR til å hente dataene, deretter analysere og verifisere den. Dette fjerner risikoen for å få skadelig kode utført på nettstedet ditt.
Gjennomføringen krever at leverandøren bare legger til følgende spesielle overskrift i svar:
Access-Control-Allow-Origin: tillatt opprinnelse
Dette kan bare være et par tillatte opprinnelser, skilt med mellomrom, eller et jokertegn: * å la enhver opprinnelse be om dataene.
Alle nåværende versjoner av moderne nettlesere støtter CORS, med unntak av Opera Mini.
Selvfølgelig er det største problemet her at tjenesteleverandører må legge til CORS-støtte, så det er ikke helt avhengig av utvikleren.
En iframe med
sandkasseattributtet vil ikke kunne navigere i vinduet, utføre skript, låse pekeren, vise popup-vinduer eller sende skjemaer.
Hvis du bruker iframes for å laste innhold fra eksterne nettsteder, kan du sikkert også sikre dem. Dette kan gjøres ved hjelp av sandkasse iframe-attributt. En iframe med en slik attributt tom (men nåværende) vil ikke få lov til å navigere i vinduet, utføre skript, låse pekeren, vise popup-vinduer eller sende skjemaer. Rammen vil også ha en unik opprinnelse, så den kan ikke brukes lokal lagring eller noe som er relatert til politikken med samme opprinnelse. Du kan selvfølgelig tillate noen av dem, om du vil, ved å legge til en eller flere av disse verdiene i attributten:
De sandkasse iframe-attributtet støttes i alle moderne nettlesere, med unntak av Opera Mini.
Så det er det. Jeg håper du har lært noen nye teknikker som du kan bruke i fremtidige prosjekter for å beskytte dine applikasjoner. Takket være HTML5 kan vi nå gjøre fantastiske ting med våre nettsteder, men vi må tenke på sikkerhet fra første linje av kode hvis vi vil at de skal være motstandsdyktige mot angrep.
