Säkerhetshål på inloggning

[mindsleep]

Hejsan!

 

Nu har jag stött på ett problem som jag funderar på hur jag ska lösa det. Kanske kan någon av er hjälpa mig.

 

Jag har en inloggnings-sida (ASP). På denna sida finns det fält för lösen och anv. När man klickat på knappen "Logga in" så skickas lösen och anv. via POST till sig själv. Om lösen och anv. stämmer överens med lösen och anv. som finns i en vanlig textfil så loggas man in. Inte bra. Nej, så jag har MD5 haschat uppgifterna i text filen så skulle man öppna den skulle det se ut så här (typ):

2141234135wefsdfsdf32

214sdf43rwwrertwerewd

 

Det översta är anv. i MD5 och det nedersta lösen i MD5.

 

Problemet är ju att om någon "lyssnar" på sidan så kommer man att kunna snappa upp när sidan skickas till sig själv (när man fyllt i fälten och klickat på login). Då skulle man kunna se lösen och anv. i "plain text"

 

Skulle jag kryptera allt före jag skickar sidan så kan man ju avlyssna sidan och få MD5 lösenet och anv. Har man sedan läst text-filen med MD5 lösenet och anv. så skulle man via externa webbsidor eller program enkelt kunna manipulera så att det är rätt MD5 kryptering som skickas.

 

Hur ska jag lösa detta?

 

Jag förmodar att lösningen ligger i att man inte kan skicka POST från någon annan sida eller program. Men hur säkerhetställer jag att de verkligen är på själva sidan "login.asp" och inte från något program eller extern sida? Har sett andra sidor som använder bilder...typ att man ska skriva in i ett fält bokstäver som syns i bilden. Vet dock inte exakt hur bra detta är eller hur man gör. Kanske finns det ett enklare sätt.

 

Hoppas någon kan hjälpa mig. Det hade ju varit enkelt om jag kunde ha skyddat text-filen så att den inte gick att läsa. Men de möjligheterna har jag inte på mitt hotell.

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[NoiseKiller]

Intressanta tankar..

*bump bump*

 

Tror att Tydal har nåt intressant å säga..?

 

\\eForum\NoiseKiller

 

[Anders N]

Med hjälp av javascript kan du beräkna MD5 på klientsidan innan du skickar det till din sida, så att lösenordet aldrig skickas i klartext.

 

Utan ssl så skulle jag skulle nog göra något liknande detta (för att "dölja" lösenordet), det kräver dock att klienten bibehåller en session, och att javascript är aktiverat. (notera: MD5(text) innebär hash-värdet för strängen "text")

 

1. Administratören sparar användarnamn, samt MD5(användarnamn+lösenord) i en databas/fil.

2. Klienten går in på login-sidan, och servern genererar en slumpad sträng (123abc) som sparas i sessionen, och skickas till klienten.

3. Klienten matar in användarnamn och lösenord, och klickar på "Logga in".

4. Javascript på klientsidan byter ut lösenordet i formuläret mot: MD5(123abc + MD5(användarnamn+lösenord))

5. Formuläret skickas till login-sidan.

6. Servern beräknar om MD5(123abc+MD5(sparat i databasen) ) stämmer med det som klienten skickade.

 

På detta sätt så borde de flesta problemen lösas. Servern borde även ha stöd för "plain text"-inloggning om klienten inte har javascript aktiverat.

 

Varför ha med 123abc?

För att man inte skall kunna "återanvända" en inloggning, och direkt skicka MD5-info till servern.

 

Varför MD5 på både användarnamn och lösenord?

Detta används som salt för att man inte skall kunna använda förgenererade MD5-listor, eller se vilka användare som har samma lösenord om man får tag i lösenordsfilen.

 

Ciao,

Anders

- som är trött och inte riktigt har tänkt igenom detta innan han skrev det.

 

[Anders N]

Det hade ju varit enkelt om jag kunde ha skyddat text-filen så att den inte gick att läsa. Men de möjligheterna har jag inte på mitt hotell.

 

Börja textfilen med raden "<%" och döp den till .asp så borde man inte komma åt den från klienten även om man vet filnamnet.

 

Det bästa är naturligtvis om den inte alls går att nå, och man ska ändå bara använda "hashade" lösenord, men många bäckar små.

 

Ciao,

Anders

 

 

[mindsleep]

Hej Anders!

 

Tack för tipset, men om jag har förstått detta rätt...så funkar detta inte. Jag kan personligen skriva program som exakt kan imitera en webbsida. Så om exempelvis "123abc" sparas i en Session("randomStr")...så kan jag komma åt den via programmet, alltså inte se vad som sparats men när jag skickar formuläret kan jag skicka det som om jag vore på en webbsida. Saken är ju det att allt jag kan se i javascript går ju konvertera till applikations-språk för att exakt låtsas vara loggin-sidan.

 

Jag vet inte om jag fattat rätt. Men om jag har det så funkar det inte.

 

Däremot är ditt andra inlägg med en asp extension en bra lösning. Men jag måste komma åt den som om jag skulle komma åt en text-fil. Och om jag måste nå den som en text-fil så måste det ju finnas sätt att även ett program kan nå den.

 

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[foo]

Hej!

 

Kul problem!

 

Varför använder du inte SSL som Anders påpekar? Då slipper du mycket huvudbry!

 

Anders lösning funkar helt ok, dock bör du tänka på detta också:

 

För det första, vilka attacker vill du skydda dig mot?

Att en hacker ligger och sniffar just din server är väl ändå ganska långsökt? Dessutom är risken att en användare har en trojan installerad högre och då spelar det ingen roll hur du skyddar din kommunikation.

 

Ett problem med Anders lösning är att saltet skickas från servern till klienten, vilket innebär att en hacker ser det i klartext. Dessutom ser hackern hela processen för att hasha fram login informationen som sedan skickas till servern. Bara något att tänka på!

 

Tänk även på om du md5 hashar användarnamn + lösenord blir det alltid detsamma. Det är bättre om man lägger in lite variabler i den totala strängen, för att undvika strängkonstanter. ex. salt1 + användarnamn + salt2 + lösen + salt3 osv.

 

"Varför MD5 på både användarnamn och lösenord?"

Om du md5 hashar både användarnamn och lösenord utan någon mer variabler, har du exponerat ett komplett användarnamn + lösenord (se ovan).

 

Sedan en sista synpunkt: MD5 är inte så säkert som man kanske kan tro. Det finns naturligtvis verktyg för att cracka sådant här: http://membres.lycos.fr/mdcrack/index2.html

 

Ett alternativ till säker inloggning är att du implementerar en riktig kryptering av användarnamn och lösenord, direkt på klienten. Detta gör man via antingen en Java applet alternativt en ActiveX kontroll. Det är mycket bättre än en implementation i Javascript.

 

Problemet med att bara tillåta postning från din sida går inte att komma runt.

 

/foo

 

[Thomas Tydal]

> Sedan en sista synpunkt: MD5 är inte så säkert som

> man kanske kan tro. Det finns naturligtvis verktyg

> för att cracka sådant här:

 

Det är inte MD5 som är osäkert. Det är svaga lösenord, som alltid, som är osäkra. Länken du presenterade är ju bara bruteforce.

 

 

[foo]

Hej!

 

Jag hävdar inte att MD5 i sig är osäkert. Uttryckte mig ottydligt där. Självklart är det implementation som är den svaga punkten vilket jag vill påvisa genom länken. En brute force attack på ovanstående lösning när man har både salt värde och en konstant användarnamn + lösenord kombination är fullt genomförbar. Speciellt om användarnamn och lösenord inte ändrar sig över tiden.

 

Ofta slår man knut på sig själv med krångliga processer för att säkra upp ett system, för att sedan fall på målsnöret pga feltänk.

 

/foo

 

[mindsleep]

Hejsan!

 

Jag tror jag har kommit på en bra lösning på problemet. Men innan jag publicerar exakt hur jag tänkt det så måste jag fråga 2 saker. Hela idéen står och faller på dessa saker, nämligen dessa:

 

1. Kan man från en extern sida eller program ändra en Session variabel?

Exempelvis: På en asp sida finns följande fråga - IF Session("inloggad")<>"jorå" THEN

Går det från någon extern sida eller program ändra så att Session variabeln innehåller just "jorå"?

 

2. Kan man genom att jämföra flera MD5 strängar komma fram till den sträng som saknas för uppbyggandet av MD5 strängen?

Exempelvis: dessa 2 strängar tillsammans bygger upp en MD5 sträng "kalle"+"orvar".

låt oss säga att de tillsammans bildar denna MD5 sträng (obs:exempel) "ju28aidkwiks".

Endast "kalle" i MD5 blir följande: "234jf39a". Min fråga är om man tittar på den totala strängen och jämför med den som bara innehåller "kalle" kan man då på något sätt få fram att det är "orvar" som saknas för att få den totala MD5 strängen?

 

Om svaret är Nej på båda frågorna ovan. Så tror jag att jag har hittat en hyfsat "bulletproof" lösning. Jag ska givetvis publicera den här om det är någon som är intresserad av att se den.

 

Den bygger eller är helt i riktning på de svar jag fått från denna tråd. Anledningen jag säger bygger "helt" är att jag kan ha missuppfattat något inlägg. Men om jag har fattat det rätt så har jag något nytt i alla fall.

 

Föressten tack för alla svar bra svar.

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[Thomas Tydal]

> Kan man från en extern sida eller program ändra en

> Session variabel?

 

Nej, sessionsvariablerna lagras på webbservern.

 

 

> Kan man genom att jämföra flera MD5 strängar komma

> fram till den sträng som saknas för uppbyggandet av

> MD5 strängen?

 

Nej, i ditt fall är ju "orvar" en hemlig nyckel. Lyckas man skapa en korrekt md5-sträng så bevisar det att man känner till den hemliga nyckeln. Detta utan nyckeln behöver överföras.

 

 

[Kristianstad]

Thomas Tydal skrev:

Nej, sessionsvariablerna lagras på webbservern.

Jag har inte följt tråden, men lagras verkligen innehållet i sessionsvariablerna på servern?

Jag har alltid trott att servern endast lagrar ett sessionsidnummer och att klienten lagrar allt innehåll + sessionsnumret.

Eller har jag fel?

 

 

/ Kristoffer

Windows kunde inte hitta något tangentbord. Tryck F1 för att försöka igen eller F2 för att avbryta.

 

[fhe]

Eller har jag fel?

 

Ja :-)

 

 

[Thomas Tydal]

> men lagras verkligen innehållet i

> sessionsvariablerna på servern?

 

Ja, det är det som är finessen med att använda sessionsvariabler. På så vis behöver man inte kontrollera att man får samma sak tillbaka som man lagrade som man måste med cookies och GET- och POST-variabler.

 

 

> Jag har alltid trott att servern endast lagrar ett

> sessionsidnummer och att klienten lagrar allt

> innehåll + sessionsnumret.

 

Tvärtom, det är klienten som endast lagrar ett sessionsidnummer.

 

 

[mindsleep]

Alright, eftersom varken Session variabler går att "fuska" med eller återskapandet av en MD5 sträng bör detta vara mer än hyfsat säkert. Om man nu inte bestämmer sig för att hacka servern och få tillgång till käll-koden, men det ansvaret lämnar jag till mitt webbhotell.

 

Hoppas ni kan hjälpa mig påpeka svagheter i denna psydo-kod.

 

--------------------------------------------------

Man har 2 asp-sidor: login.asp och confirm.asp

 

På sidan finns en Session variabel som får ett random värde:

Session("rndValue")=in med en 12 strängs random värde skapat i vbScript (a..Z,0-9)

 

Sedan finns på sidan ett konstant värde....typ:ids29Ks2saSq. Detta värde tillsammans med Session(rndValue") körs via asp igenom en MD5 alghoritm och sparas sedan i Session("md5String")

 

på sidan finns också ett formulär, typ:

<form action="confirm.asp" method="post">

Användarnamn:<br>

<input type="text" name="user"><br><br>

Lösenord:<br>

<input type="text" name="pass"><br><br>

<input type="submit" name="send" value="Skicka" onklick="javascript:byt ut pass och user mot md5 strängar()";>

</form>

 

Innan vi skickar formuläret så, genom javascript md5ás user och pass till var sin MD5 sträng. och sparas i Session("md5Pass") och Session("md5User")sedan byter vi ut pass och user i formuläret med "dummy" strängar.

 

Sedan skickar vi formuläret till confirm.asp (kanske inte behövs, för vi skickar ju egentligen inget med fomuläret förutom dummys. kanske bättre med en redirect eller javascripts: location)

 

på confirm.asp sidan sker följande:

På denna sidan finns samma konstanta värde som login.asp sidan.

 

Vi tar detta värde och slår ihop det med värdet som hämtas från Session("rndValue") och kör den igenom en MD5. Sedan jämför vi MD5 strängen med det som klienten har, typ:

IF Session("md5String")=confirm.asp sidans md5

 

Om detta stämmer kan vi vara säkra på att personen kommer från login.asp och kan därför fortsätta.

 

Sedan hämtas losen och pass från en databas eller som i mitt fall en txt-fil. Dessa är MD5-strängar.

 

Dessa jämförs med de som finns i Session("md5Pass") och Session("md5User"). Om allt stämmer så är allt ok.

----------------------------------------------------

Det var den lösningen jag funderat på Vad jag kan se så kan inte sniffaren se något av värde. Han kommer att kunna se 2 dummy strängar. Han måste gå igenom login.asp för att få Session("rndValue") och Session("md5String"). Från sidan kan han ju inte bestämma vad som ska sparas i Session variablerna så där är han låst. Det han skulle kunna göra är att bygga upp det via en egen asp-sida men då måste han ju blandannat veta det konstanta värdet och Session("rndValue") vilket är en omöjlighet om han inte sett källkoden.

 

Vad jag kan se så funkar detta och är relativt säker.

 

Kan ni se några svagheter i detta? Är det något jag inte tänkt på?

 

Var det kanske något sådant här ni föreslog? Jag ber i sånna fall om ursäkt för att jag inte fattade det

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[Thomas Tydal]

> Kan ni se några svagheter i detta?

 

Ja, det är ett par detaljer...

 

 

> Innan vi skickar formuläret så, genom javascript

> md5ás user och pass till var sin MD5 sträng. och

> sparas i Session("md5Pass") och Session("md5User")

> sedan byter vi ut pass och user i formuläret

> med "dummy" strängar.

 

Inget sparas i sessionsvariablerna förrän du har skickat formuläret. Sessionsvariabler ligger ju på servern, så värdena måste föras över dit först.

 

 

> Om detta stämmer kan vi vara säkra på att personen

> kommer från login.asp och kan därför fortsätta.

 

Dessvärre inte. Du kan bara vara säker på att personen någon gång har besökt login.asp. Om han gör det först, så sessionsvariablerna får rätt värden, kan han ju sedan skicka informationen varifrån som helst.

 

 

> Sedan hämtas losen och pass från en databas eller

> som i mitt fall en txt-fil. Dessa är MD5-strängar.

 

Du har md5-strängar i textfilen för att det inte ska göra nåt om någon ser textfilen, eller hur? Så att ingen ska få reda på användarnamn och lösenord den vägen och kunna logga in som nån annan?

 

Men hur skickar inloggningssidan det inmatade användarnamnet och lösenordet? Jo, som md5 för att en eventuell sniffare inte ska kunna få reda på vad det är för lösenord och kunna logga in som nån annan...

 

Bara ett krux då. Eftersom confirm.asp förväntar sig att få användarnamn och lösenord i md5-format så behöver man ju inte känna till det riktiga lösenordet. Bara att plocka ut md5-strängarna från text-filen och skicka direkt så blir man inloggad...

 

* * *

 

Men på det stora hela intressant tänkt. Det är dock, som du säkert märkt, väldigt svårt att lyckas hitta en egen lösning som är säker. Hade du sjösatt det här - och textfilen varit åtkomlig - hade vem som helst kunnat logga in som vem som helst.

 

[inlägget ändrat 2003-05-17 22:38:34 av Thomas Tydal]

[mindsleep]

> Kan ni se några svagheter i detta?

 

Ja, det är ett par detaljer...

 

 

> Innan vi skickar formuläret så, genom javascript

> md5ás user och pass till var sin MD5 sträng. och

> sparas i Session("md5Pass") och Session("md5User")

> sedan byter vi ut pass och user i formuläret

> med "dummy" strängar.

 

>Inget sparas i sessionsvariablerna förrän du har >skickat formuläret. Sessionsvariabler´ligger ju på >servern, så värdena måste föras över dit först.

Tänkte inte på det. Men funkar det verkligen så? Och spelar det egentligen någon roll? Det som skickas till servern för att sparas i Sessionvariablerna är ju MD5 strängar (förutom Session("rndValue")).

 

 

> Om detta stämmer kan vi vara säkra på att personen

> kommer från login.asp och kan därför fortsätta.

 

>Dessvärre inte. Du kan bara vara säker på att >personen någon gång har besökt login.asp. Om han gör >det först, så sessionsvariablerna får rätt värden, >kan han ju sedan skicka informationen varifrån som >helst.

Jag är inte helt överens med dig på denna punkt. Om han skickar informationen från någon annanstans så måste ju det bli en ny session varav Sessionvariablerna då är tomma, eller?

Jag har för mig att jag testat liknande saker. Man har ett öppet webb-fönster och jag har då en Session-Id sedan öppnar jag ett nytt fönster (med det gammla fortfarande öppet) och en ny session id skapas.

 

 

> Sedan hämtas losen och pass från en databas eller

> som i mitt fall en txt-fil. Dessa är MD5-strängar.

 

>Du har md5-strängar i textfilen för att det inte ska >göra nåt om någon ser textfilen, eller hur? Så att >ingen ska få reda på användarnamn och lösenord den >vägen och kunna logga in som nån annan?

Japp!

 

>Men hur skickar inloggningssidan det inmatade >användarnamnet och lösenordet? Jo, som md5 för att >en eventuell sniffare inte ska kunna få reda på vad >det är för lösenord och kunna logga in som nån >annan...

 

>Bara ett krux då. Eftersom confirm.asp förväntar sig >att få användarnamn och lösenord i md5-format så >behöver man ju inte känna till det riktiga >lösenordet. Bara att plocka ut md5-strängarna från >text-filen och skicka direkt så blir man inloggad...

Exakt, det är ett stoooort problem, därför försöker jag "tvinga" personen att måsta gå igenom login.asp före han kan komma till confirm.asp. Därigenom kan han inte bestämma vad som ska skickas. Därför Session("md5String") och Session("rndValue") och konstanten.

 

* * *

 

>Men på det stora hela intressant tänkt. Det är dock, >som du säkert märkt, väldigt svårt att lyckas hitta >en egen lösning som är säker. Hade du sjösatt det >här - och textfilen varit åtkomlig - hade vem som >helst kunnat logga in som vem som helst.

 

Det är det som är det roliga i detta:) Att försöka få fram en bra lösning.

Nej, detta är bara teori, än så länge.

Tackar för ditt svar. Hoppas på att du svarar på detta inlägg.

 

[mindsleep]

Ajdå!

 

Nu vart det lite fel. Försökte svara på ditt inlägg som du svarade på mitt igenom:

 

>din mening

min mening.

 

Men jag vet inte hur man besvara ett inlägg så jag förskte göra det manuellt, men det blev inte bra.

 

Men du ser kanske vart jag har svarat.

 

 

 

[Thomas Tydal]

>> Inget sparas i sessionsvariablerna förrän du har

>> skickat formuläret. Sessionsvariabler ligger ju på

>> servern, så värdena måste föras över dit först.

> Tänkte inte på det. Men funkar det verkligen så?

 

Sessionsvariabler kan du bara tilldela genom asp. Och asp körs ju innan sidan skickas till användaren. Så för att något användaren matat in ska kunna sparas i en sessionsvariabel måste ju en ny sida begäras (så asp körs) exempelvis genom att du skickar ett formulär eller följer en länk.

 

 

> Och spelar det egentligen någon roll?

 

Nej, men du kommer inte ifrån att visa upp det för en eventuell sniffare.

 

 

> Om han skickar informationen från någon annanstans

> så måste ju det bli en ny session varav

> Sessionvariablerna då är tomma, eller?

 

Nej, detta annanstans kan ju vara samma ställe som först laddar login.asp som en skenmanöver. Man behöver inte öppna en ny webbläsare. Det är bara att gå till en annan adress.

 

Sessionen behålls så lång tid som du har satt timeouten på servern eller tills cookien på användarens dator tas bort.

 

 

>> Eftersom confirm.asp förväntar sig att få

>> användarnamn och lösenord i md5-format så behöver

>> man ju inte känna till det riktiga lösenordet.

>> Bara att plocka ut md5-strängarna från text-filen

>> och skicka direkt så blir man inloggad...

> Exakt, det är ett stoooort problem,

 

Vilket hot är störst? Att någon sniffar överföringen eller att någon tittar på lösenordsfilen? Med nuvarande lösning är du oskyddad mot båda varianterna. Om du istället skickar lösenordet och användarnamnet i klartext är det inte lika farligt om någon kommer över lösenordsfilen. Fortfarande sårbart för sniffning, men det var det ju innan också.

 

 

> därför försöker jag "tvinga" personen att måsta gå

> igenom login.asp före han kan komma till

> confirm.asp.

 

Men du vet inte vad han gör däremellan!

 

 

> Därigenom kan han inte bestämma vad som ska skickas.

 

Jo, det kan han. Användaren kan styra över javaskript och allt som skickas från hans dator, och han ser allt du skickar.

 

 

[mindsleep]

Du har alldeles rätt.

 

Asp bearbetas av servern...måste vara trött. Därför sparas Sessions variabler inte förren sidan bearbetas av servern.

 

Att visa upp MD5-strängar för sniffers tycker jag inte är en säkerhetsrisk.

 

Jag gjorde en snabb test för att kolla hur det funkade med session variabler som skickats från en sida och det visade sig att så länge som jag har webbläsar-fönstret öppet så existerar variablen....Däreigenom faller hela idéen. Om jag inte kan styra från vart han kommer så kan jag inte heller styra vad som skickas.

 

Får väll återgå till att döpa min txt-fil till ett 50 meters namn som ingen kan lista ut. Sedan förvara MD5 lösenordet och användarnamnet där samt skicka detta över formulär (MD5). Det gör ju inget så länge ingen sett text-filen

 

Tack för hjälpen.

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[Thomas Tydal]

> Att visa upp MD5-strängar för sniffers tycker jag

> inte är en säkerhetsrisk.

 

Inte i sig, men i och med att man kan logga in genom att ange md5-strängen så blir det ju en säkerhetsrisk.

 

Visst kan inte sniffaren få tag i lösenordet, men om han kan logga in ändå så gör ju inte det så mycket.

 

 

> Får väll återgå till att döpa min txt-fil till ett

> 50 meters namn som ingen kan lista ut.

 

Det kallas för att göra en Inkompetentia. Ingen bra idé. Visserligen räckte det väl med en IQ på 50 för att kunna lista ut deras, men ändå.

 

Då tycker jag det är vettigare att du gör som Anders tipsade om, att du kallar den för .asp.

 

 

 

 

[mindsleep]

Kom just på att det är en enorm säkerhetsrisk att skicka en MD5-sträng för det är ju exakt som att skicka ett plain-text. Skiter väll också i MD5...fasen är den vettig till något annat än CRC32 arbeten?

 

Och då även eventuellt spara i filer som använder sig av SSL?

 

Det får helt enkelt bli en "välkommen" sida

 

Jaja, det är ju bara en typ sitemanager. Börjar mystiska saker att hända så är det bara att köra SSL. Det är ju inte någon speciellt viktig sida. Inget känsligt förutom att besökarna kan få se roliga sidor.

 

"Inkompetentia" vilka är det som har gjort så tidigare?

 

Men om jag döper den till asp...hur kommer jag då åt de 2 textsträngarna?

 

Förut använda jag FileScriptingObject. Och är inte det också en liten risk med det...jag menar kommer jag in på asp sidan och kan hämta information från den då kan jag ju lika gärna göra likadant om jag är en hacker.

 

Skitsamma, hur gör jag för att läsa strängarna från en asp-sida?

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[mindsleep]

Hej!

 

Hur funkar det med cookies då?

 

Sänds de också i plain-text?

 

Går det att sniffa cookies som sänds?

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***

 

[Thomas Tydal]

> "Inkompetentia" vilka är det som har gjort så

> tidigare?

 

Intentia. De la ut sin kvartalsrapport för tidigt på webbservern. Men eftersom de inte länkade till den trodde de att den var skyddad. I media uppgav någon ansvarig att den var "skyddad med en 46 tecken lång kod" (minns inte det exakta antalet). Det var bara det att den hade samma filnamn som kvartalsrapporten innan (som var länkad) med skillnaden att den nya hade en 3:a i sig för tredje kvartalet och den innan en 2:a.

 

Läs mer:

http://www.tydal.nu/se/news/index.phtml?q=intentia

 

 

> Men om jag döper den till asp...hur kommer jag då

> åt de 2 textsträngarna?

> Förut använda jag FileScriptingObject.

 

Du gör på samma sätt nu, men du ignorerar första raden (den som börjar med <%)

 

 

> jag menar kommer jag in på asp sidan och kan hämta

> information från den då kan jag ju lika gärna göra

> likadant om jag är en hacker.

 

Nej, öppnar man den genom webbservern så visas ju inte det mellan <% och %>. Ditt skript öppnar den ju genom filsystemet istället, med asp, så du får fram filens innehåll.

 

 

[Thomas Tydal]

> Hur funkar det med cookies då?

> Sänds de också i plain-text?

 

Ja.

 

 

> Går det att sniffa cookies som sänds?

 

Piece of cake.

 

Du kanske borde skaffa dig en sniffer själv och se efter :-)

 

http://www.ethereal.com/

 

 

[mindsleep]

Ännu En gång!

 

Stort tack för hjälpen, den har verkligen varit givande.

 

Var inne på din hemsida och läste om intentia.

 

Skoj!

 

Ger dig här en länk till något som fungerar, det vi pratade om tidigare. Dom har gjort i princip samma sak som vi snackade om. Till skillnad hämtar dom lösenordet via "Application" och det är i plain-text.

 

Sedan jämförs det med en rndValue + lösenord som tillsammans bildar en MD5-sträng. På detta vis så är inte MD5 konstant. En sniffer skulle inte kunna "fej-posta lösenordet".

 

Det verkar funka vad jag då kan se:

http://builder.cnet.com/webbuilding/pages/Programming/Scripter/013100/index.html

 

Varför inte då byta ut lösenordet som ligger i application och lägga det i en asp-fil, som du nämnde?

 

//MVH Mindsleep

 

*** The answer to knowledge is a question ***