Källkoden för /anders.enges/html/ecomm2.asp

<!--#include file="../inc/navstuff.asp" -->

Det finns två typer av säkerhet att beakta när man talar om Internet. <p>
Dessa är:
<blockquote>
<dl>
<dt><strong>Transmisionssäkerhet</strong>
<dd>Berör själva överföringen av data mellan klienten och servern. Denna kan delas in i två delar:<br>
<dl>
<dt><strong>Kryptering</strong>
<dd>Säkersäller att ingen avlyssnar transissionen.
<dt><strong>"Message digest"</strong>
<dd>Säkerställer att ingen har modifierat datat innan det kommer fram.
</dl>
<p>
<dt><strong>Autenticering</strong>
<dd>Jag skall kunna bevisa att "jag är jag", dvs. att ingen annan använder mina kontaktuppgifter.
</dl>
</blockquote>
Dessa kan användas var och en för sig eller tillsammans.<p>
<h3>Vad är en säker internet "site"?</h3>
Säkerhet är ett brett fält. Man bör dock kunna:
<ol>
<li>Kontrollera vem som kan komma åt sidorna</li>
<li>Se till att ingen utomstående kan se transmissionsdata
</ol>
Kontrollen av vem som skall få komma åt sidorna hanteras oftast av en kombination
av operativsystemets säkerhetssystem och internetserver programmet.<p>
För att se till att datat överförs säkert används oftast <b>S</b>ecure <b>S</b>ockets <b>L</b>ayer
(SSL / Netscape) och/eller <b>P</b>rivate <b>C</b>ommunications <b>T</b>echnology (PCT / Microsoft).
Dessa är bägge baserade på X.509 certifiering.<p>
Användarna av systemet kan delas in i två kategorier:
<ol>
<li>Anonyma (Anonymous)</li>
<li>Användare med användarnamn på värddatorn</li>
</ol>
<h3>Anonym access</h3>
När man går till en sida som inte kräver ett lösenord så kommer man in som <b>Anonymous</b>.
Detta betyder inte att säkerhetsssytemet är satt ur spel.<p>
Internetservern har genererat ett speciellt användarnamn för dessa accesser. För IIS (Micrsoft)
betyder detta att om servern heter <b>MYSERVER</b> så kommer användarnamnet att bli <b>IUSR_MYSERVER</b>
Även för detta konto finns det ett lösenord<p>
Genom att i operativsystemet bestämma vilka rättigheter dett konto har så kan man bestämma vad användaren kan göra.<p>
Accesserna kommer alltid att ske genom internetservern och användaren får <b>aldrig</b> veta vilket lösenord som har använts.
Detta sker på följande sätt:
<ol>
<li>När operativsystemets säkerhetssystem märker att en katalog/fil skall läsas tillhandahåller internetservern användarnamn/lösenord för det anonyma kontot</li>
<li>Operativ systemet kommer att kontrollera vilka rättigheter detta kontio har</li>
<li>Eftersom detta konto (IUSR_ ) finns så kommer accessen att bli godkänd (förutsatt att IUSR_ kontot har accessrätt till den resurs som efterfrågades)</li>
<li>Filen ges åt internet servern som sänder denna till klienten</li>
</ol>
<h3>Är anonym access en säkerhetsrisk</h3>
Förutsatt att ingen "vild" nätansvarig har gett fulla rättigheter till hela systemet för
det anonyma kontot kommer denne endast att komma åt "godkända" kataloger.<p>
Det är lätt att lista ut användarnamnet för det anonyma kontot, men klienten kommer aldrig
att se vilket lösenord som använts.<p>
Därför anses anonym access inte försämra den generella säkerheten på servern.
<p>
<h3>Access med lösenord</h3>
I sin enklaste form fungerar ett lösenordssystem så att man ser till att inte ge användarrätt
åt det anonyma kontot.
Nedanstående beskrivingar gäller i första hand NT.
Övriga system har dock motsvarande system<p>
Normalt sett fungerar en access på följande sätt
<ol>
<li>Web browsern sänder en HTTP GET förfrågan till servern.
<li>Servern utvärderar denna GET och lokaliserar den efterfrågade filen.
<li>Servern skapar en HTTP RESPONSE som den sänder tillbaka till browsern.
Denna kan bland annat innehålla filstorlek och annan information.
<li>Servern meddelar hur många TCP/IP paket som kommer att sändas och sänder sedan filen.
</ol>
Om vi har en katalog/fil som inte det anonyma kontot ha rätt till så sker i stället följande:
<ol>
<li>Web browsern sänder en HTTP GET förfrågan till servern.
<li>Servern utvärderar denna GET och lokaliserar den efterfrågade filen.
<li>Servern försöker läsa filen och märker att den inte har rätt till detta med det anonyma kontot.
<li>Servern skapar en HTTP RESPONSE som innehåller koden <b>401 Access denied</b> och meddelar detta till browsern.
<li>Om vi använder MS Explorer och MS IIE kommer dessa att "tyst" utbyta information om vilket användarnamn användaren har loggat in med.
Om vi använder Netscape eller någon annan browser så kommer denna att sätta fram en logindialog där vi får ge in användarnamn och lösenord.
Om vi inte har SSL igång kommer användarnamn/lösenord att sändas i klartext över internet (=säkerhetsrisk)
<li>Internetservern kommer att använda detta användarnamn/lösenord för att försöka komma åt filen. Om rättigheterna är OK komer filen att sändas.
</ol>
<h3>Flödesschema</h3>
Nedan kommer ett flödesschema för hur kontakten mellan klienten och servern sker:
<p> <img src="../images/https.gif" border="0" width="415" alt="En Bild" /><br>
   Figur 2. IIS 3.0 Säkerhetsflödesschema
<p>
Förklaringar:
<dl>
<dt>Blockerad IP
<dd>Betyder att internetservern inte är på eller inte överhuvud taget godkänner en access
<dt>SSL
<dd>Secure Sockets Layer. En metod för att kryptera transmissionen
<dt>HTTPS
<dd>En "vanlig" websida har en URL som börjar med <b>http://</b>. Om man har SSL så kommer URL:n att ha <b>https://</b> som typ. Detta är en indikation på att man
använder SSL
<dt>Certifikat
<dd>Den ena delen i en "public/private key" kryptering. Innefattar i praktiken att ett certifikat installeras på klient datorn.
<dt>NTLM
<dd>NT:s Challenge/Response system för lösenord (fungerar inte med Netscape). Betyder att lösenord aldrig överförs i klartext och kan ske "bakom kulisserna"
<dt>NTLM token
<dd>Den krypterade användarnamn/lösenordskombinatinen
</dl>

<!--#include file="../inc/footer.asp" -->