Webapplikasjon sikkerhet er kritisk. Sikkerhetshull i web-applikasjoner du skriver kan resultere i ditt område blir uleselig, noe som er bare veldig pinlig. Det kan resultere i at brukerens informasjon blir stjålet, noe som er irriterende og kan lande deg i juridisk varmt vann i din jurisdiksjon. Eller det kan resultere i at verten blir brukt for spamming, distribuert denial of service angrep, eller spre ondsinnet programvare, som alle gjør Internett et verre sted for alle andre. Noen enkle trinn, og riktig tankesett, kan redusere risikoen for at dette skjer på grunn av programmene du har skrevet.
Trinn
- 1Unngå SQL-injeksjoner. SQL-injeksjoner er muligens den vanligste måten web programvare er kompromittert i dag. Eksempelet fra Wikipedia følger. Vurdere følgende linje med pseudokode.
Dette fungerer fint hvis "a_variable" kan være klarert. Men hvis det er en selvanskaffet variabel, kan en angriper levere dette:
Som vil resultere i denne spørringen blir utført:
Som åpenbart er en forferdelig ting å ha. Løsningen er å rense eventuelle bruker-leverte variabler, religiøst. PHP har mysql_real_escape_string funksjon for MySQL. Andre databasen biblioteker for andre programmeringsspråk har det samme. Bruk dem, og du vil være mye tryggere. Det er også objekt-relasjonelle mappers (som Django for Python) som sparer deg fra å måtte skrive SQL-kode i det hele tatt, og ta vare på rømmer strenger før de sendes videre til databasen din, bør du vurdere å bruke en av disse. - 2Åpne aldri noe filnavnet basert på en parameter som brukeren forsyninger. For eksempel, hvis du var å vise en fil til en bruker, kan du bli fristet til å ha en nettadresse som display.php file = something.txt, og i din PHP-koden bruke dette?:
Dette er ekstremt farlig, som det vil tillate dem å bruke sekvenser av ".. /" (ta dem til den overordnede katalogen) for å inkludere alle filer i filsystemet, for eksempel ved å gå til display.php? File =.. /.. /.. /.. /.. / etc / passwd.
I beste fall vil dette tillate dem å samle informasjon om din server konfigurasjon, noe som kan gi informasjon som er nyttig for en annen angrep. I verste fall, hvis PHP-er krever eller inkludere funksjoner (eller tilsvarende på ditt språk) brukes til å inkludere innholdet av filen, kan det tillate kjøring av kode (ved å manipulere User-Agent header da inkludert filen / proc / selvstendig / miljø ).
Løsningen på dette er å enten finne en annen måte å inkludere filen som ikke gjøre det basert på brukerundersøkelser, eller svært nøye rense den medfølgende filnavnet. Sjekk hvert tegn for gyldighet, og kast eventuelle forbudte som bruker prinsippet om at tegnene som ikke er tillatt er forbudt, og ikke ved å fjerne skadelige seg. Med andre ord, ikke prøv å erstatte dårlige tegn i en streng. Lag en liste over de som er eksplisitt tillatt og skanne strengen for dem, fjerne alt som ikke er i listen over tillatte seg. Det er 1) enklere 2) beskytter mot angrepsvektorer du ikke hadde tenkt på. - 3Desinfiser alle data du skriver til en side. Koden kan godta en parameter som heter "person" (dvs. index.php person = Bob, og koden din vil inneholde noe sånt som dette?:
Dette tillater en angriper å skrive vilkårlig JavaScript til siden, noe som betyr at hvis de overbevist noen å bare følge en link til nettstedet, kan de få dem til å forårsake en handling med en side-effekt (for eksempel legge ut en kommentar, eller sender en hvilken som helst annen form). Erstatte eventuelle kjente-dårlige karakterer (anførselstegn, <, og> med deres tilsvarende HTML enhet før du skriver det til en side.
Mange templating motorer vil gjøre dette for deg automatisk, og vil bare tillate HTML-tegn i en outputted variabel dersom det uttrykkelig er erklært trygt. Det kan være lurt å vurdere å bruke en.
Hvis du trenger å tillate noen begrenset HTML (for eksempel for å tillate tekstformatering i kommentarer), desinfisere slik HTML å bare tillate tags kjent for å være trygg og ha mindre bivirkninger (for eksempel <em>), forkaste alle andre, og forkaste eventuelle uønskede HTML-attributter. Igjen, bør utgangspunktet være bare tillate det som er eksplisitt tillatt, og strippe alt annet. (Etter dette prinsippet kunne ha forhindret en beryktet WordPress sårbarhet, hvor den renses CSS innenfor en "stil"-attributtet, men forlot det urørt hvis attributten navn var stor bokstav.) - 4Aldri passere en selvanskaffet variabel til et skall. For eksempel kan du ha skrevet et skript for å sende en ping til en gitt host. Det ville ta en parameter som heter vert (for eksempel ping.php host = 127.0.0.1?), Og slik at du kan bli fristet til å gjøre dette:
Dette er ekstremt farlig, fordi ved å levere en "host" parameter med en pipe symbol eller et semikolon, det gir dem å utføre enhver kommando på systemet (for eksempel, noe som gir en rekke "127.0.0.1 | wget").
Løsningen på dette er å unngå å bruke systemet fungerer der det er mulig, påberope seg eksternt program annen måte pcntl_exec er en bedre ide for PHP.. Hvis du må bruke systemet, forsiktig rense eventuelle bruker-leverte data før den sendes til skallet. (Et eksempel for våre "ping" script ville være å sjekke hvert tegn til at det var enten et tall, brev, eller periode, og kast alle tegn som er noe annet.) - 5Bruk funksjoner som php er eval veldig, veldig nøye. Hvis strengen inneholder en selvanskaffet variabel, så vil tillate dem å kjøre vilkårlig kode. Faktisk er det nesten aldri en grunn til å bruke denne, hvis du finner deg selv å bruke det, er koden sannsynligvis forferdelig, og du bør revurdere det.
- 6Sjekk referent på alle HTTP POST-forespørsler som har bivirkninger. Sørg for at den henvisende nettstedet er nettstedet, ellers kunne det har rett og slett vært en bruker som klikker på en knapp i et skjema på et annet nettsted. (Du kan eller ikke kan være lurt å sikre at den henvisende nettstedet er ikke tomme. Referrer kan være blank hvis angriperen-kontrollerte web siden bruker sikker HTTP og din gjør det ikke.). Et annet triks når du bruker en form genererer en unik kode, og lagre den i både en økt variabel og i et skjult felt i skjemaet. Når du sender inn, sjekk om verdien av den skjulte feltet er lik den i økt variabel.
- 7La aldri en HTTP GET-forespørsel for å ha en bivirkning. For eksempel aldri skrive til en database ved hjelp av parametere som leveres i en GET-forespørsel. Husk at en GET-forespørsel kan være en bruker av nettstedet som ble lurt til å klikke på en link.
- 8Kontroller legitimasjon på hvert trinn. Her er et eksempel:
En. Den bruker ber om å utføre en bestemt handling.
3. Du viser en "Er du sikker på at du vil gjøre dette?" side med handlingen uttrykt i skjulte skjemafelt.
Trikset er, hvis du bare bekrefte sin tillatelse til å utføre disse handlingene i trinn 2, men ikke på manuset blir lagt til i trinn 4, gjelder dette om dem ikke er i stand til å endre form gitt til dem i trinn 3 (som tillit er sterkt forlagt), eller selv gå til trinn 4. direkte. - 9Ikke lagre passordene i klartekst. Dette er en begrensende tiltak i tilfelle området er kompromittert. Siden mange brukere gjenbruk passord, kan det bety at alle deres andre online-kontoer bli kompromittert. Standarden mottiltak for dette, er å lagre en kryptografisk hash (for eksempel ved hjelp av SHA-2-algoritme) av summen av et par byte tilfeldige data pluss passordet. Dette vil gjøre det mulig å verifisere om en medfølgende passordet er korrekt, uten å lagre passordet selv.
(For fremtidsrettet, kan det være en god idé å lagre den type algoritmen som brukes også, i tilfelle du trenger å migrere til en annen hash algoritme, bør alvorlige svakheter som finnes i dagens. Dette skjedde med MD5 og SHA- 1, og kan ennå skje med dagens mest troverdige hash algoritmer.) - 10Når du bruker en database, ikke lagre database login informasjon direkte i rotmappen på søknaden din. I stedet, lagre dem i en annen mappe og deretter enten 1) nekte tilgang til mappen ved hjelp av web serverens innstillinger eller. Htaccess 2) lagre filen utenfor dokumentet roten. Deretter inkludere filen; søknaden din påvirkes ikke av webserveren tillatelser. Dette vil stoppe folk fra å gå til http://your-awesome-site.example.com/config.ini å finne ut din database innloggingsinformasjon (men det vil ikke stoppe en angriper som har funnet en fil inkludering sårbarhet som i trinn 3, eller et skall av kode utnytte som i trinn 4).
- 11Ikke avhengig av roboter. Txt å skjule sensitive områder av nettstedet ditt. Det er noen ganger god grunn til å gjøre dette (for eksempel hvis hele området er sensitivt, og du ikke ønsker det indeksert av søkemotorer). Men husk at en av de første tingene en angriper helvete-bøyd på å svekke nettstedet vil gjøre er å se på robots.txt for å se hva du gjemmer. En bedre måte å gjøre dette på er å bruke en meta tag på sidene du ønsker ikke å bli indeksert (for eksempel administrative back-end sider). For eksempel:
<meta name="robots" content="noindex, nofollow" />
- 12Komme inn i riktig tenkemåte. Denne artikkelen er ikke ment å være en omfattende liste over alle sikkerhetsproblem som kan påvirke din side, men det gir noen reelle eksempler på bruk noen viktige prinsipper:
- Aldri stole på noen informasjon som kan leveres av brukeren. Faktisk anta at brukeren er en angriper, og behandle eventuelle bruker-leverte data tilsvarende.
- Når sanitising data, bare tillate det som er trygt, og bånd noe annet. Dette beskytter mot dårlig inngang som du ikke hadde tenkt på da du skrev koden. Et eksempel på dette ville være hvis du utviklet programvaren på og for et Unix-lignende system, og forsvart mot fil-inkludering sikkerhetsproblemene ved å fjerne noen skråstreker fra et gitt filnavn. Dette ville fungere OK, inntil noen utplassert koden på en Windows-boks (som ville tillate en skråstrek som en bane separator).
- Anta at du vil gjøre feil, og anvende prinsippet om forsvar i dybden for å dempe virkningene. (Ovenstående "bare tillater det som er trygt" er et spesialtilfelle av dette.)
- Anta en potensiell angriper vet alt du gjør. Som er å si, skrive koden som om en potensiell angriper ble sittende ved siden av deg å lese den. Dette både oppfordrer deg til å bruke god praksis hvert steg på veien, og demper effekten av programmet bli kompromittert. Ikke skriv dårlig kode tenker at ingen noen gang vil se det, eller finne ut hvor ille det er. Og mens sikkerhet ved uklarhet har sin plass, ikke stole på hemmeligheter som bor hemmelig og tenke som en angriper.
Advarsler
- Aldri anta at din søknad er 100% sikker. Nye exploits kan bli funnet, som vil bli misbrukt av angripere. Sørg for at du holde deg oppdatert med de nyeste beste-praksis for å sikre dine programmer til omfang av dine evner.
- Ikke stol AJAX forespørsler. Husk at dette er veldig, veldig lett å forfalske av alle som vet å bruke Wireshark (for å finne ut hvilke parametre som skal brukes i en HTTP-forespørsel) og vet å bruke curl eller wget.