Innskráningarþjónusta island.is - Minningargrein

Þann 2. október síðastliðinn var endanlega slökkt á gömlu Innskráningarþjónustu island.is og lauk þar með áhugaverðum og byltingakenndum kafla í sögu auðkenningar á Íslandi. Í þessu bloggi ætlum við að líta um öxl og sjá hvað við getum lært af þessari vegferð.

Innskráningarþjónustan

Upphafið

Snemma árs 2013 var ný innskráningarþjónusta tekin í notkun af Þjóðskrá Íslands. Innskráningarþjónustan leysti af hólmi svokallaða veflykla RSK, sem höfðu upprunalega verið notaðir til að auðkenna einstaklinga og lögaðila með íslenskar kennitölur á vefsíðu Ríkisskattsstjóra, en höfðu verið teknir í notkun af öðrum opinberum stofnunum í kjölfarið.

Það er ekki orðum aukið að tilkoma innskráningarþjónustunnar hafi verið bylting bæði fyrir opinbera þjónustu sem og einkageirann, enda veitti hún fyrirtækjum og stofnunum tækifæri til að auðkenna alla Íslendinga á einu bretti, þeim að kostnaðarlausu, og þjónuðu þannig tilgangi „nafnskírteinis á netinu“ eins og það var orðað af innviðaráðherra á sínum tíma.

Fyrst um sinn voru svokallaðir íslyklar að mestu notaðir til auðkenningar hjá innskráningarþjónustunni, en þeir voru einfaldlega lykilorð sem hægt var að fá send í heimabanka eða bréfpósti, en ekki leið á löngu þar til rafræn skilríki í farsíma fóru að ryðja sér til rúms og nutu sífellt meiri vinsælda.

Viðtökurnar létu ekki á sér standa, og rúmlega ári eftir að innskráningarþjónustan fór í loftið voru 100 stofnanir, sveitarfélög, félagasamtök og fyrirtæki búin að innleiða þjónustuna og rúmlega 135.000 íslyklar verið gefnir út til einstaklinga. Árið 2020 voru svo 300 þjónustuveitendur búnir að innleiða innskráningarþjónustuna og búið að gefa út rúmlega 290.000 íslykla, en þess ber þó að geta að rúmlega helmingur notenda notaðist þá við rafræn skilríki í farsíma við innskráningu.

Hvernig virkaði þetta?

Þegar sótt var um aðgang að innskráningarþjónustunni, gaf þjónustuveitandi upp endapunkt þar sem hann vildi taka á móti innskráningartóka frá island.is, auk tengiliðaupplýsinga, merkis og annarra tilfallandi upplýsinga. Eftir að umsókn var samþykkt var þjónustuveitandanum svo úthlutað auðkenni, oftast lén þjónustunnar, t.d., ambaga.is. Til að auðkenna notendur gat þá þjónustuveitandi sett inn hlekk sem vísaði á https://innskraning.island.is/?id=ambaga.is. Þegar smellt var á þann hlekk, endaði notandinn á innskráningarsíðu island.is, með merki þjónustuveitandans.

Innskráningarsíða island.is

Eftir að innskráning þar heppnaðist, var notandinn sendur aftur á síðu þjónustuveitendans með POST fyrirspurn á endapunktinn sem gefinn var upp í umsókninni, og þar tók þjónustuveitandinn við innskráningartókanum og skráði notandann inn.

Úr leiðbeiningum Þjóðskrár: Flæði auðkenningar milli þjónustuveitanda og innskráningarþjónustunnar

Auðkenningarflæðið

Það er ekki mjög skýrt á flæðismyndinni að ofan, en einn mikilvægasti þátturinn í þessu innskráningarferli er að tókinn sem innskráningarþjónustan smíðar, sem er sönnunin á því að notandinn hafi auðkennt sig, er sendur til þjónustuveitandans í gegnum biðlarann (e. client). Tókinn fer því ekki beint frá innskráningarþjónustunni til þjónustuveitandans, heldur er biðlari (í flestum tilfellum vafri) notandans notaður til að miðla tókanum.

Útfærslan á þessu er í grófum dráttum þannig.

• Notandi skráir sig inn á innskráningarsíðu auðkenningarþjónustunnar, innskraning.island.is.
• Innskráning heppnast og notandanum er beint á aðra síðu, ennþá á innskraning.island.is.
  • Á þeirri síðu er form sem inniheldur auðkenningartókann.
  • JavaScript er notað til að skila (e. submit) forminu með POST fyrirspurn á endapunkt þjónustuveitandans.
• Þjónustuveitandi tekur á móti POST fyrirspurn með auðkenningartóka og skráir notandann inn í sínum kerfum.

Það sem er mikilvægt að hafa í huga í þessu ferli er notandinn getur ekki bara lesið innhald tókans, heldur hefur fulla stjórn á honum og getur breytt innihaldi hans áður en honum er skilað til þjónustuveitanda.

Þegar viðkvæm skilaboð eins og auðkenningartókar fara yfir ótraustar boðleiðir, þ.e. boðleiðir þar sem hægt er að eiga við skilaboð, er gríðarlega mikilvægt að hægt sé að staðfesta að upplýsingarnar sem komast á endastöð (í þessu tilfelli til þjónustuveitenda) séu réttar og uppruni þeirra sé vottaður.

Þetta vandamál er ekki nýtt innan tölvunarfræðinnar og ein algengasta leiðin til að leysa það, og jafnframt sú leið sem var farin, var að notast við dreifilykladulritun (e. public-key cryptography) til að undirrita auðkenningartókann áður en hann er sendur til þjónustuveitandans.

Undirritanir

Þegar kemur að undirritunum með dreifilykladulritun eru tveir þættir sem skipta mestu máli, þ.e. einkalykillinn (e. private key) og dreifilykillinn (e. public key). Einka- og dreifilykill eru smíðaðir í pörum af handahófi. Einkalykillinn er bara geymdur hjá þeim sem ætlar að undirrita skeyti (í okkar tilfelli Þjóðskrá) og verður að vera haldið leyndum. Leki einkalykillinn brotna allar forsendur. Dreifilykillinn er svo gerður opinber, og í þeim tilfellum þar sem lyklar eru upprunavottaðir og hluti af dreifilyklakerfi (e. public-key infrastructure, PKI), þá er dreifilykillinn kallaður skírteini (e. certificate).

Undirritun á skeyti á sér svo stað nokkurn veginn á þennan máta.

• Sendandi skeytisins undirritar það með einkalyklinum (nákvæm framkvæmd á því skiptir ekki öllu máli).
  • Undirritunin er háð innihaldi skeytisins, þannig ef innihaldið breytist, þá breytist undirritunin.
• Móttakandi skeytisins getur notað dreifilykilinn til að máta innihald skeytisins við undirritunina.
  • Ef undirritunin stemmir við innihaldið þá hefur ekki verið átt við skeytið.

Sé gögnum breytt í undirrituðu skeyti, mun undirritunin ekki stemma við innihaldið

Í sumum tilfellum er dreifilykillinn sendur með skeytinu sem skírteini, en þá er gríðarlega mikilvægt að kanna ekki bara hvort innihaldið stemmi við undirritunina heldur líka að ganga úr skugga um að við treystum skilríkinu og það sé rétt.

Sé uppruni undirritunarskírteinis ekki athugaður getur meinfýsinn aðili útbúið sitt eigið skírteini og undirritað hvaða gögn sem er með því

Þetta er mikil einföldun á því bákni sem stafrænar undirritanir eru og biðjumst við forláts á því ef eitthvað er ónákvæmt eða ekki tæknilega rétt, en þessar útskýringar veita næga innsýn til að hægt sé að skilja þær árásir sem við fjöllum um að neðan.

SAML

En hvernig líta þessir tókar út í raunveruleikanum? Sú leið sem varð fyrir valinu við útfærslu innskráningarþjónustunnar kallast Security Assertion Markup Language (SAML), sem er XML auðkenningarstaðall sem notaður er víða. Hér að neðan má sjá grófa uppbyggingu SAML tóka, en dæmi um fullgildan SAML tóka frá innskráningarþjónustunni má finna hér.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Issuer>Þjóðskrá Íslands</Issuer>
  <Signature>
    <!--
      Þetta tag inniheldur, m.a., undirritunina á skeytinu, ásamt skírteininu sem notað var við undirritunina
    -->
  </Signature>
  <Assertion>
    <Issuer>Þjóðskrá Íslands</Issuer>
    <Conditions>
      <!--
        Upplýsingar um hvenær auðkenningin er gild og hvaða þjónustuveitandi er ætlaður móttakandi hennar
      -->
    </Conditions>
    <AttributeStatement>
      <Attribute Name="UserSSN" FriendlyName="Kennitala">
        <AttributeValue>1234567890</AttributeValue>
      </Attribute>
      <Attribute Name="Name" FriendlyName="Nafn">
        <AttributeValue>Jón Jónsson</AttributeValue>
      </Attribute>
      <!--
        Nánari upplýsingar og lýsigögn
      -->
    </AttributeStatement>
  </Assertion>
</Response>

Veikleikar

Öryggisveikleikar eru eðlilegur hluti af hugbúnaðarþróun, enda oftast um mjög flókin kerfi að ræða, en áhrif þeirra eru mismikil. Sumir veikleikar hafa nánast engin áhrif á meðan aðrir geta haft gríðarlegar afleiðingar. Veikleikar í auðkenningu eru sérstaklega alvarlegir þar sem þeir geta gert meinfýsnum aðila kleift að auðkenna sig sem hvaða notandi sem er og þannig lesið gögn og framkvæmt aðgerðir í nafni allra notenda.

Hver og einn þjónustuaðili útfærir hvernig hann meðhöndlar SAML tókana við auðkenningu. Þar sem um er að ræða rúmlega 300 þjónustuaðila með mismikla þekkingu á SAML, sem nota mismunandi forritunarmál, með mismikinn stuðning við SAML, er við því að búast að gæði og öryggi útfærsla hafi verið mjög mismunandi. Raunin var einmitt sú að sumar útfærslur reyndust öruggar en aðrar innhéldu alvarlega öryggisveikleika.

Hér munum við fara yfir fjóra þekkta veikleika við notkun innskráningarþjónustunnar sem vitað er að hafi fundist hjá þjónustuveitendum.

Signature Not Verified (SNV)

Þessi veikleiki felur í sér að þjónustuveitandi sem tekur á mót SAML tóka athugar ekki hvort undirritunin stemmi við innihaldið, heldur tekur einfaldlega innihald tókans eins og það kemur inn og notar þær upplýsingar til að skrá inn notanda með þeim upplýsingum sem finnast í XML skjalinu. Til að misnota þennan veikleika þarf einungis að útbúa eða fá tilbúið SAML úr innskráningarþjónustunni, breyta kennitölu og nafni, og senda það á innskráningarendapunkt þjónustuveitandans. Í sumum tilfellum er jafnvel hægt að fjarlægja Signature tagið alfarið úr XML skeytinu!

Signature Wrappping (SW)

Áritunarvefja (e. signature wrapping) er þekktur veikleiki sem gæta þarf sérstaklega að þegar unnið er með undirritað XML. Til að skilja þennan veikleika þurfum við að kafa aðeins dýpra í hvernig undirritun SAML tóka er háttað og hvernig hún er staðfest.

Þegar notandi hefur skráð sig inn í innskráningarþjónustuna er tókinn smíðaður, þ.e., XML skjalið er sett saman með upplýsingum um gildistíma, gildissvið, notanda, o.s.frv. Þegar því er lokið er einkalykill innskráningarþjónustunnar notaður til að undirrita innihald XML skjalsins í heild sinni. Við það verður til Signature tagið, sem er svo bætt við undir rót XML skjalsins, og það er svo afhent notandanum til að senda á þjónustuveitenda.

Þegar þjónustuveitandinn tekur á móti SAML skeytinu, þá byrjar hann á því að staðfesta að undirritunin stemmi við innihald skeytisins. Munum samt að XML skjalið sem var undirritað upprunalega innihélt ekki Signature tagið, þar sem því var bætt við eftir undirritun. Ferlið við að staðfesta undirritun felst því að fjarlægja fyrst Signature tagið úr XML skjalinu og kanna svo hvort undirritunin stemmi við skjalið án þess. Stemmi undirritunin og sé skilríkið traust, þá telst tókinn vera gildur og við getum treyst öllum gögnunum sem hann innheldur, er það ekki? Setjum fram sauðakóða þar sem við sækjum kennitölu úr tókanum.

# Tökum við tókanum

saml = get_token()

# Göngum úr skugga um að tókinn sé gildur
verify_token(saml)

# Sækjum kennitölu
kennitala = saml.find_all("//Attribute[@Name='UserSSN']/AttributeValue/text()")[0]

Hér notum við XPath til að sækja öll Attribute tög með nafnið UserSSN og notumst við gildið úr því. Það á bara að vera eitt slíkt tag í gildum SAML tóka þannig okkur er óhætt að nota bara fyrstu (og einu?) niðurstöðuna, er það ekki?

Þetta er mjög gott dæmi um hvernig lítill forsendubrestur eða hugsanaskekkja getur haft gríðarleg áhrif, enda verður sú vísa aldrei of oft kveðin að uppruni flestra veikleika er þegar gert er ráð fyrir einhverju sem er ekki raunin. Vissulega er tókinn gildur og undirritunin stemmir við innihaldið, en ekki öll gögnin í tókanum eru undirrituð. Munum að Signature taginu er bætt við tókann eftir undirritun, þannig innihald þess má alls ekki treysta. En í sýnidæminu að ofan, þá inniheldur saml breytan XML skjalið í heild sinni, þ.m.t. `Signature⁺ tagið.

Meinfýsinn aðili gæti því misnotað sauðakóðann að ofan á eftirfarandi hátt.

• Framkvæmt innskráningu með innskráningarþjónustunni og tekið á móti SAML tókanum sjálfur.
• Bætt við nýju Attribute tagi inni í Signature tagið með kennitölu þess aðila sem hann vill auðkenna sig sem.
• Sent breytta tókann á þjónustuveitandann.

Nýji tókinn myndi þá hafa eftirfarandi form.

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Signature>
    <!-- ... -->
    <Attribute Name="UserSSN" FriendlyName="Kennitala">
      <AttributeValue>0987654321</AttributeValue>
    </Attribute>
  </Signature>
  <Assertion>
    <!-- ... -->
    <AttributeStatement>
      <Attribute Name="UserSSN" FriendlyName="Kennitala">
        <AttributeValue>1234567890</AttributeValue>
      </Attribute>
      <Attribute Name="Name" FriendlyName="Nafn">
        <AttributeValue>Jón Jónsson</AttributeValue>
      </Attribute>
      <!-- ... -->
    </AttributeStatement>
  </Assertion>
</Response>

Þegar þessi tóki fer í gegnum sauðakóðann að ofan, þá mun hann talinn vera gildur því undirritunin stemmir við innihaldið, gildistíminn er réttur, o.s.frv. Þegar kemur að því að sækja kennitöluna, aftur á móti, eru tvö tög sem uppfylla XPath skilyrðin. Þar sem kóðinn notast við það fyrsta sem hann finnur, þá eru gögnin úr Signature taginu sótt, sem meinfýsni aðilinn hefur fullkomna stjórn á, og hann getur því skráð sig inn sem hver sem er.

Self-signing (SS)

Eins og fram hefur komið að ofan inniheldur SAML tókinn bæði undirritunina og skírteinið sem notað var til undirritunar. Þegar tekið er á móti SAML tóka er því ekki nóg að kanna einungis hvort undirskriftin stemmi við innihaldið m.v. uppgefið skilríki, heldur þarf líka að kanna hvort skilríkið sé trúverðugt, þ.e., kanna hvort það sé hluti af traustri skilríkjakeðju og útgefandinn sé réttur. Vanti þetta skref getur meinfýsinn aðili einfaldlega útbúið sitt eigið lyklapar og auðkenningartóka og undirritað hann sjálfur og sett sitt skilríki með. Allir geta smíðað skilríki og lykla (t.d. með openssl), og því er ekkert því til fyrirstöðu að smíða skilríki sem hafa sömu lýsigögn og raunveruleg skilríki innskráningarþjónustunnar og undirrita með þeim. Við köllum slík skeyti eiginhandarárituð (e. self-signed).

Meinfýsinn aðili getur því nýtt sér þennan veikleika til að undirrita SAML með hvaða upplýsingum sem er, og þannig auðkennt sig hjá þjónustuveitanda sem hvaða notandi sem er.

Audience Not Verified (ANV)

Þegar verið er að sannreyna tóka er ekki nóg að skoða bara hvort undirritunin sé í lagi, heldur þarf einnig að kanna gildistíma tókans og síðast en ekki síst þarf að kanna hvort tókinn sé ætlaður þér sem þjónustuveitenda. Gildistíminn og áætlaður móttakandi (e. audience) er að finna í Conditions taginu í SAML tókanum.

<Conditions NotBefore="2024-09-02T11:56:46.186368Z" NotOnOrAfter="2024-09-02T12:02:16.186368Z">
  <AudienceRestriction>
    <Audience>sjodir.rannis.is</Audience>
  </AudienceRestriction>
</Conditions>

En af hverju er mikilvægt að staðfesta móttakanda? Segjum sem svo að meinfýsinn aðili sæki um aðgang að innskráningarþjónustunni fyrir einfaldan leik, happdrætti eða eitthvað sem gæti trekkt fólk að. Fólk myndi eflaust ekki hugsa sig tvisvar um þegar það skráir sig inn á slíka síðu með innskráningarþjónustunni. En bara við það að skrá sig inn, fær meinfýsni aðilinn afhendan fullgildan undirritaðan tóka fyrir þína auðkenningu. Þannig ef önnur þjónusta, segjum Ambankinn, er ekki að staðfesta móttakanda, getur meinfýsni aðilinn notað tóka hvaða notanda sem skráir sig inn hjá honum til að skrá sig inn á Ambankann (innan gildistímans) sem sá notandi.

Aðrir veikleikar

Þessir fjórir veikleikar eru engan vegin tæmandi upptalning á því sem farið gæti úrskeiðis við innleiðingu innskráningarþjónustunnar, heldur aðeins þeir algengustu og alvarlegustu sem við höfum rekist á. Við höfum t.d. ekki rætt um afleiðingar þess að staðfesta ekki gildistímann, en áhrif þess veikleika eru ekki jafn alvarleg sé allt annað í lagi. Þess má einnig geta að bara það að velja að nota XML fyrir tókann býður upp á hættu á veikleikum eins og XXE og þjónusturofsveikleikum (e. Denial-of-service, DoS).

Það skal ítrekað að þessir tæknilegu veikleikar eru ekki í innskráningarþjónustunni sjálfri, heldur í útfærslu þjónustuveitenda, þ.e. þeirra fyrirtækja og stofnanna sem nýta sér innskráningarþjónustuna.

Lærdómur

Af hverju erum við að skrifa blogg um veikleika í innskráningarþjónustu sem er búið að taka úr notkun? Skiptir þetta einhverju máli? Ný innskráningarþjónusta island.is er eingöngu ætluð opinberum stofnunum og sveitarfélögum og því hafa undanfarið sprottið upp nýjar einkareknar innskráningarþjónustur sem þjónusta eiga einkageirann og félagasamtök. Það er því mikilvægt að líta yfir farinn veg, sjá hvort einhver mistök hafi átt sér stað og læra af þeim svo sagan endurtaki sig ekki.

Ábyrgð

Byrjum fyrst á að ræða ábyrgð. Ef að einhver þessara veikleika kæmi upp hjá mér sem þjónustuveitanda, hver ber ábyrgð? Svarið við því er einfalt, það er ég sem ber ábyrgð. Ég skrifaði kóðann, ég gerði hlutina ekki rétt, það er mér að kenna. En hvað ef 100 þjónustuveitendur eru með veikleika? Ábyrgðin er ennþá í öllum lagalegum skilningi þeirra, en þá erum við samt komin með vísbendingar um kerfislægt vandamál sem þarf að kanna betur.

Leiðbeiningarnar

Samhliða opnun innskráningarþjónustunnar, voru gefnar út leiðbeiningar, en fyrsta útgáfa leiðbeininganna er dagsett 10. janúar 2014. Útgáfa 2.0 er dagsett 8. apríl 2014 og er hún síðasta merkta útgáfa á leiðbeiningunum þó þær hafi tekið breytingum seinna, en meira um það seinna.

Úr leiðbeiningunum: Öryggi SAML-skeytis (bls 11)

Leiðbeiningarnar eru 26 blaðsíðna PDF skjal sem fer yfir auðkenningarferlið, innihald SAML skeytanna og ýmis atriði sem þarf að hafa í huga við notkun þjónustunnar. Einnig er gefið dæmi um SAML tóka og svo eru gefin „sýnidæmi“ um hvernig hægt sé að taka á móti í þremur forritunarmálum, þ.e., C# (.NET), PHP og Java .

Engin forritasöfn (e. library), pakkar (e. packages) eða forritseiningar (e. modules) voru formlega gefnar út, og því þurftu þjónustuveitendur að skrifa sínar útfærslur sjálfir, byggðar á sýnidæmunum.

.NET sýnidæmið

Köfum aðeins dýpra í .NET sýnidæmið. Í árdaga innskráningarþjónustunnar var stór hluti hugbúnaðar á Íslandi skrifaður í .NET, og því má leiða að því líkur að þetta sýnidæmi hafi verið notað sem grunnur að mörgum innleiðingum á innskráningarþjónustunni.

Skoðum fyrst hvernig undirritun er staðfest. Hér er skilríkið fundið í SAML skeytinu og kallið í CheckSignature(cert, false) staðfestir ekki aðeins að undirritunin stemmi við skilríkið, heldur kannar einnig hvort skilríkið sé traust, þ.e., að skilríkið sé hluti af skilríkjakeðju sem stýrikerfið treystir. Eins og athugasemdin fyrir ofan segir til um, er það aðeins gert þegar seinni færibreytan er false.

Eini gallinn við það er að skilríkið sem innskráningarþjónustan notaði var ekki hluti af neinni skilríkjakeðju sem Windows treysti, og því varð að bæta skilríkinu sérstaklega við sem traustu skilríki til að fá þessa staðfestingu til að virka. Þessi staðreynd kom ekki skýrt fram í leiðbeiningunum og því hefur það eflaust ruglað einhverja þegar sýnidæmið hefur ekki virkað í þeirra uppsetningu. Dæmi eru um að forritarar hafi breytt seinni færibreytunni í true, séð allt virka þannig og ekki áttað sig á að þá hafi undirritunin aðeins verið staðfest, og útfærlsan því veik fyrir SS.

XmlDocument doc = new XmlDocument();
doc.PreserveWhitespace = true;
doc.LoadXml(samlString);

SignedXml signedXml = new SignedXml(doc);
//Sækjum undirritun og skoðum
XmlNodeList nodeList = doc.GetElementsByTagName("Signature");
XmlNodeList certList = doc.GetElementsByTagName("X509Certificate");
signedXml.LoadXml((XmlElement)nodeList[0]);
byte[] certData = Encoding.Default.GetBytes(certList[0].InnerText);
X509Certificate2 cert = new X509Certificate2(certData);

//Hér er mikilvægt að setja ekki true í seinna gildi nema útfærð sé
//aðgerð sem sannreynir gildi skilríkis sérstaklega
bool signatureOk = signedXml.CheckSignature(cert, false);

Skoðum næst hvernig gildistíminn er staðfestur. Hér er tvennt sem við þurfum að hafa í huga, annars vegar að doc breytan inniheldur allt XML skjalið (með undirritun) og GetElementByTagName fallið leitar að tögum í öllu XML skjalinu. Þessi kóði er þvi veikur fyrir áritunarvefju og því er hægt að stjórna gildistíma skeytisins. Komist meinfýsinn aðili yfir útrunnið SAML skeyti notanda getur hann þannig notað áritunarvefju til að framlengja gildistíma þess og auðkennt notandann um ókomna tíð.

DateTime nowTime = DateTime.UtcNow;
//Sækjum tíma í Conditions og berum saman
XmlNodeList condNodeList = doc.GetElementsByTagName("Conditions");
DateTime fromTime = DateTime.Parse(condNodeList[0].Attributes["NotBefore"].Value);
DateTime toTime = DateTime.Parse(condNodeList[0].Attributes["NotOnOrAfter"].Value);

bool timeOk = false;
if (nowTime > fromTime && toTime > nowTime)
{
    timeOk = true;
    message += "SAML time valid. ";
}
else if (nowTime < fromTime)
    message += "From time has not passed yet. ";
else if (nowTime > toTime)
    message += "To time has passed. ";

Sýnidæmið sýnir ekki hvernig notendaupplýsingar eru sóttar, en sýnir hvernig aðrar upplýsingar úr AttributeStatement taginu eru sóttar, t.d. IP tala.

XmlNodeList attrList = doc.GetElementsByTagName("Attribute");
if (attrList.Count > 0)
{
    foreach (XmlNode attrNode in attrList)
    {
        XmlAttributeCollection attrCol = attrNode.Attributes;
        if (attrCol["Name"].Value.Equals("IPAddress"))
        {
            ipOk = attrNode.FirstChild.InnerText.Equals(ip);
            message += "Correct client IP. ";
        }

        // Ekki í sýnidæminu, en liggur beint við
        if (attrCol["Name"].Value.Equals("UserSSN"))
        {
            // Kennitala
            attrNode.FirstChild.InnerText;
        }
    }
}

Það liggur því beinast við að sækja nafn, kennitölu og aðrar upplýsingar á sama máta, og sú var raunin í mörgum tilfellum. Slík útfærsla er þá veik fyrir SW, þar sem GetElementByTagName er notað til að sækja Attribute tögin.

Að lokum staðfestir sýnidæmið ekki móttakanda skeytisins, svo það er einnig veikt fyrir ANV.

Hin sýnidæmin

Java sýnidæmið er ágætlega útfært og aðeins veikt fyrir ANV.

PHP sýnidæmið, aftur á móti, nær á einhvern undraverðan hátt að tvinna saman alla veikleikana nema SNV, en við eftirlátum lesendum þann heiður að koma auga á þá.

Hvað var gert?

Á einhverjum tímapunkti virðist hafa verið bent á gallana í sýnidæmunum því 6. júní 2019 er búið að fjarlægja sýnidæmin úr leiðbeiningunum og þeim skipt út fyrir „Sýnidæmi er í vinnslu“. Leiðbeiningarnar voru ekki uppfærðar með nýjum sýnidæmum eftir það og alls óvíst hvort þau séu ennþá í vinnslu.

Hvað getum við lært?

Nú þegar slökkt hefur verið á innskráningarþjónustunni, hvað getum við lært af þessari vegferð?

Nýja Innskráningarþjónusta island.is er aðeins ætluð opinberum aðilum, en einkaaðilar og félagasamtök geta valið að nota einkareknar innskráningarþjónustur. A.m.k. átta slíkar þjónustur eru í rekstri, og eflaust munu fleiri bætast við þegar fram í sækir.

Heilræði fyrir innskráningarþjónustur

Innskráningarþjónustur eru gott dæmi um muninn á því að tryggja öryggi hugbúnaðar í rekstri og því að tryggja öryggi útfærslu annarra á þínum forritasöfnum eða vefþjónustum. Það er því ekki nóg fyrir innskráningarþjónustur að ganga úr skugga um að allt sé í lagi og öryggi sé tryggt í þeirra eigin kerfum, það verður að lágmarka líkur á því að þeir sem útfæra þeirra lausnir séu að gera það á óöruggan hátt.

Það er því mikilvægt fyrir rekstraraðila innskráningarþjónusta að hafa í huga lögmál Murphy

Ef hægt er að framkvæma eitthvað á fleiri en einn máta, og einn þeirra mun hafa alvarlegar afleiðingar, þá mun einhver velja þá leið.

Með þetta í huga höfum við tekið saman heilræði sem nýtist þessum rekstraraðilum og öðrum sem smíða hugbúnað eða vefþjónustur sem notuð er af öðrum.

• Hafið skjölun einfalda og skýra.
  • Gerið sérstaklega grein fyrir mikilvægum skrefum eða stillingum og takið sérstaklega fram hvaða áhrif breytingar á þeim hafa.
  • Ekki gefa sýnidæmi í skjölun með harðkóðuðum lykilorðum, eða öðrum gögnum sem þarf að halda leyndum.
• Hafið tilbúna pakka, forritasöfn, forritseiningar eða fullvirk sýnidæmi.
  • Mikilvægt er að sá hugbúnaður hámarki sjálfgefnar öryggisstillingar (e. secure by default).
• Útfærið (sjálfvirkar) öryggisprófanir á uppsetningum þjónustuveitenda ef hægt er.
  • Kannið hvort verið sé að virða undirritanir og staðfesta móttakendur og gildistíma.
• Takið öllum ábendingum fagnandi.
  • Komi upp veikleikar í sýnidæmum eða öðrum hugbúnaði sem dreift er, látið vita og gangið úr skugga um að allir uppfæri.
  • Verið opin um ykkar öryggismál og sýnið þannig gott fordæmi.

Að lokum

Veikleikar eru eðlilegur og jafnframt dýr hluti af hugbúnaðarþróun. Kostnaður við veikleika sem finnst í raunkerfum felst ekki einuningis í sektum, heldur líka vinnutapi og orðsporshnekki. Ambaga leggur ríka áherslu á fræðslu og þjálfun forritara, því ódýrustu veikleikarnir eru þeir sem aldrei verða til.

Í þjálfuninni leggjum við ríka áherslu á að forritarar setji sig í spor hakkarans og þjálfi þannig það viðhorf sem þarf til að koma auga á veikleika. Ambaga hefur þróað kennsluvettvang þar sem forritarar fá að leita uppi ýmsa veikleika í raunverulegum hugbúnaði og læra að misnota þá. Slík þjálfun brýnir fyrir þátttakendum hversu alvarleg áhrif öryggisveikleikar geta haft og gerir þá í stakk búna til að finna þá í sinum eigin hugbúnaði.

Við minnum svo á að viljir þú spreyta þig á þeim veikleikum sem við höfum farið yfir hér, þá höfum sett upp fjórar þrautir í kennsluvettvangnum okkar þar sem markmiðið er að misnota innskráningarþjónustuna hjá fjórum ímynduðum þjónustuveitendum.