kodetest.dk✨

Sikkerhed på hjemmesiden: Query String

Af: Rune Jensen | 💬 0 kommentarer | Kommentér

Resumé: Både for sikkerhed og for SEO, kan det være en fordel at begrænse hvilke data, der kan sendes i query string.

Hvad er query string?

Kigger du i adressebaren, vil du se, at nogle adresser efterfølges af et spørgsmålstegn.

Spørgsmålstegnet angiver, at her begynder query string.

Kigger du yderligere, vil du se, at query string er opbygget som variable med et = (lighedstegn) imellem.

Og at variable adskilles af ; (semikolon).

Disse variable samt deres værdier kan aflæses af et script på hjemmesiden og bruges til alskens formål. For eksempel, søgetermer i et søgefelt sendes igennem query string til en anden side, som yderligere bruge indholdet af søgeterm variablen til at sortere og vise resultater fra en database.

Som udgangspunkt er der ingen andre restriktioner på hvad query string kan indeholde andet end hvad standarden siger, og hvordan din browser tolker den standard.

Fordi query string er en del af adressen, kan denne også manipuleres af brugeren, og et sådant manipuleret link kan sendes til andre brugere.

Det kan gøre din side potentielt sårbar, hvis ikke du validerer brugerinput, før du bruger det andre steder.

Principle of least priviledge: Brug af hvidliste

Prøv at forestille dig, at man i stedet for at tillade alle input i query string, i stedet opstiller en minimal liste over, hvilke variable, som er tilladte og hvilke værdier som er tilladte. Og at denne rutine køres først på alle sider.

Det giver angribere et meget mindre råderum for mange slags angreb igennem query string, fordi man allerede på forhånd ved, hvilke vartiable og hvilken type af variable man har med at gøre.

Hvis du ved lidt om programmering, kan det smmenlignes med at kræve dimensioning af sine variable og typesikre dem.

Hvis man således bruger en variabel, som ikke førsrst er dimensioneret, eller giver en variabel en forkert type værdi, giver programmet en fejlmelding.

Dette kendes også som Strict Mode.

Men kan det lade sig gøre at sætte query string i Strict Mode?

Det er nemt på mindre sider med få krav. På større sider, skal man have tungen lige i munden.

Men det hjælper altid at have en klar forståelse for, hvilke variable og hvilke typer af variable man behøver i query string på sin side.

Introduktion af variabel typer

Her er en liste over variabeltyper tilladt i query string på denne hjemmeside:

  • _bt Variabelnavne med denne endelse tillader alene nuemriske værdier
  • _an Variabelnavne med denne endelse tillader alene alfa-numeriske værdier, dvs kun bogstaver og tal (inkluderet æ,ø og å)
  • _ar Denne type variabel er den mest krtiiske, da den tillader alle input. Til gengæld, så ved vi også, hvor en eventuel fare logisk vil ligge, og vi kan programmere efter det.

Man kan gå mere eller mindre i detaljer med endelserne.

Man kunne jo for eksempel forestille sig en _mt variabel, som alene tillod værdier imellem 1 og 12 (dvs. de tolv måneder).

Men at gå alt for meget i detaljer, vil også give for store restriktioner for én selv, så det kan være svært at vedligeholde.

Det er måske bedre i stedet at lægge den validering i selve det script, som skal bruge månedsvariablen.

I det mindste véd man på daværende tidspunkt, at variablen allerede er valideret til at være numerisk, hvis den har endelsen _bt.

Hvidliste på variabelnavne

Fordi jeg ved ret sikkert, hvilke variable jeg vil tillade hvor, og fordi jeg på forhånd ved, jeg ikke skal bruge alt for mange variabler i query string til en simpel blog, har jeg også en white list på selve variabelnavnene.

Her er listen direkte fra mit script fra dags dato:

"$filter_vrd$ $liste_byt$ $id$ $t$ $t_var$ $t_vrd$ $month$ $s_vrd$ $year$ $date$ $day$ $time$ $file_var$ $test_var$ $test_chk$ $id_chk$ $side$ $page$ $billede$ $search_var$ $term_vrd$ $footprint_var$"

Hvidlisten er en function (isQueryStringOK), som laver et loop over alle variable i query string, og to grundlæggende valideringsrutiner kaldes for hver variabel:

Den ene kontrollerer, at query string variablen i det hele taget findes i hvidlisten, og returnerer sand eller falsk.

Den anden validerer værdien af variablen udfra variabelendelsen, og den returnerer også sand eller falsk alt efter om typen er overholdt.

Hvis hele loopet gennemføres uden af valideringsrutinerne giver falsk, er hvidlisten overholdt, og hvidlistfunktionen returnerer sand. Ellers returneres falsk.

Hvad sker der, hvis man giver input, som ikke er tilladt i hvidlisten?

Umiddelbart, så strippes URLen for query stringen, og man omdirigeres med 301 Permanently Moved til den nye adresse. Dvs. at alt indhold af query string fjernes, og scriptet forsøger at give den nye side, hvis denne findes.

Prøv for eksempel at skrive

http://www.kodetest.dk/index.asp?a=1

Variablen a findes ikke i hvidlisten, og man bliver derfor omdirigeret til URLen uden querystring.

Man kan også prøve at give korrekt variabelnavn, men forkert værdi ifht. hvidliste - så sker det samme:

http://www.kodetest.dk/index.asp?month=november

month-variablen tillader kun numeriske værdier.

En stærk advarsel om omdirigering

Det er vigtigt, når du omdirigerer, at du aldrig bruger værdier fra URLen til dele af den nye adresse.

Brug altid alene interne variable, enten hard coded, eller fra settings-filer (tekstfiler, som alene dui selv styrer) og så de interne variable, som dit kodesprog giver.

Protokollen på denne hjemmeside er dd. http:// og denne del ligger i en tekst-fil, hvorfra den hentes.

Det samme gør underdomænet www.

Så for at danne http://www. så henter jeg to tekstfiler og joiner dem.

Derefter, så har jeg en tekstfil med hostnavnet, som er kodetest.dk

Den sidste del af URLen hentes fra en intern server-variabel, som ligger i ASP, som hedder SCRIPT_NAME. Det er stien på serveren til selve det ASP-script, som udføres, og holdes internt af ASP selv.

OBS at i dette tilfælde, hvor en side med og uden query string giver samme indhold, vil en 301 Permanently Moved til siden uden query string, også være godt for søgemaskine optimering.

Hvad med black listing?

Hvor hvidlister angiver hvad der er tilladt, og afviser alt andet, så er sortlister modsat en række af værdier, som ikke er tilladte.

For eksempel, så kunne man forestille sig, at en variabel, som med type _ar tillader alle input, vil få et et ondartet input.

Nogle af disse ondartede inputs kan tages med en kort black list, som afviser allerede defineret ondartet indhold. Men vær opmærksom på, at fordelen ved hvidlister er, de ikke skal opdateres - det skal sortlister i princippet.

Så med en sortliste kan man tage de mest gængse former for ondartet manipulering af query string, men langt fra alle. Til gengæld, holder man sortlisten på omkring en linje, vil den ikke kræve forholdsvist meget serverkraft, men stadig have en virkning på "script kiddies".

Så, hvad skal blacklistes? Eller hvad kan black listes?

Grundlæggende visse variabelnavne og værdier fra gængse CMSer som WordPress med interne kommandoer eller SQL kommandoer i query string, som har haft beviste sårbarheder netop dér.

Her er den minimale sortliste, jeg har på query string:

"../../ -%3E rand%5B rand[ 1%27 %27a %27=%27 =1' '1= %20-- !-- [document_root]= base_folder= absolute_path= .txt? count( sourcedir= '=' char( Cast( [sysobjects] <script"

Hvad sker der, hvis en bruger angiver værdier, som er i sortlisten?

Hvor query string har en af de sortlistede værdier, giver man bare en 404 File Not Found.

Det er vigtigt, at sortlisten kontrolleres først, for en ondartet input kan også bryde med hvidlisten.

Dette giver så, at for eksempel, hvor...

http://www.kodetest.dk/index.asp?a=1

...bryder med white listen (fordi variablen a ikke er i white listen), og derfor giver omdirigering til side uden query string, så bryder...

http://www.kodetest.dk/index.asp?a'='1

...med black listen (fordi '=' er i black listen). Og da black listen kontrolleres først, så giver denne URL en fejlside i stedet.

OBS: Man kunne også smide brugerens IP på en sortliste, sådan man kan blokere ham for fremtiden, men der er en del fælder ved sådanne IP blacklister, som man i så fald skal forsøge at undgå. Det kommer jeg ind på i et andet blogindlæg, hvordan man løser.

Overordnet white list - den nemme løsning til mindre sider

Man kan også validere direkte på query string uden at skele til variabel navne eller typer.

Hvis man for eksempel ved med sikkerhed, man kun kommer til at bruge alfa-numeriske variabler og varibelværdier, så kan man bruge en rexEx på query string, som sorterer alt fra, som ikke er alfanumerisk (husk dog at white liste tegn, som er en del af query string = tegnet, samt ; og &).

Dette er fint til mindre sider. Jeg har selv brugt dette på et par hjemmesider. Det er meget restriktivt, men det tager stort set alle angreb igennem query string.

Eksempel i pseudo kode:

Function IsQueryStringOK

   Dim R,Q

   Q = Request.Servervariables("QUERY_STRING")

   Set R = New RegEx

   isQueryStringOK = R.test(Q,"[a-zA-Z1234567890\;\&\,\=]")

   Set R = NOTHING

End Function

...som returnerer sand, hvis query string overholder hvidlisten, ellers falsk.

http://www.kodetest.dk

Filed in: 🏷HTML  🏷Desktop  🏷Mobile

Kommentarer

  1. Name

Skriv Kommentar

Regler for kommentarer

Der er som udgangspunkt altid follow på disse links (vigtigt for SEO):

  • Youtube og google search
  • Nordiske domæner som .dk .se .no .fi og .is domæner
  • Andre verificerede .com og .org domæner (dvs. at selve hjemmesiden ikke indeholder spam)
se hvordan et follow link indsættes i en kommentar under "Liste over koder, du kan bruge i kommentaren")

Der er altid nofollow på .ru og .ua og .ch domæner.

Visse link-adresser kontrolleres automatisk - hvis de sender en 404 (Not Found), vil linket ikke blive klikbart

Hvis link-adressen har mistænkeligt indhold vil det enten blive censureret væk eller gjort ikke klikbare, eller, hele kommentaren vil blive afvist.

Alle sprog godtages som udgangspunkt, men der foretrækkes engelsk eller et nordisk sprog (dansk, norsk, svensk).

Bloggen er baseret på Pro Absolut Ytringsfrihed; Med mindre, du sender ren spam (f.eks. forsøg på salg af varer uden at bidrage til debatten), vil alle kommentarer (tekst) blive godtaget. OBS: Footeren er en undtagelse fra reglen om spam. Links er dog ikke klikbare i footeren.

Se hvordan du indsætter en footer under "Liste over koder, du kan bruge i kommentaren"

Sidst, men ikke mindst, botter bliver afvist i døren, så ingen automatisering. Skriv alle kommentarer manuelt ;)

Liste over koder, du kan bruge i kommentaren

Emojis, som bliver oversat til billeder:

  • :) og :-) =
  • :| og :-| =
  • :( og :-( =

Formattering

  • "citat" eller >citat på ny linje = "Citat"-blok
  • "citat" i selve teksten = inline citat
  • *example* = example
  • /example/ = example
  • _example_ = example
  • -example- = example
  • - listepunkt tekst (på ny linje) + ENTER = uordnet listepunkt
  • 1. listepunkt tekst (på ny linje) + ENTER = ordnet listepunkt
  • <http://example.com> = indsæt et klikbart follow link (se også "Regler for kommentarer")
  • http://example.com indsæt et klikbart nofollow link
  • £youtube link£ på ny linje = indsætte en youtube video fra dette punkt i stedet for et klikbart link (maksimum én indsat video pr. kommentar)
  • $code snippet$ = code snippet - OBS: Alle andre formatteringer bliver ophævet indenfor code snippet. Du kan lave det til en blok ved at starte på ny linje og bruge ENTER indenfor formatteringstagget, som vil give en kodeblok med nummerede kodelinjer
  • -- (tankestreg tankestreg mellemrum ENTER til allersidst i kommentaren) = dette er DIN blok på maksimum 5 linjer eller 72 tegn, hvor du kan skrive hvad du vil, fx. et citat du synes om eller at du vil sælge din bil eller lignende. Det bliver vist i kommentaren som en slags "footer" med mindre skriftstørrelse. Hold ALT off topic indenfor dette felt. OBS: Alle formatteringer ophæves indenfor dette felt. Vær også opmærsom på, at alt over 72 tegn bliver skåret væk.
Giv din mening




top af side