mboost-dp1
newz.dk
heh.
Eller har db backups liggende i public directories *host* newz.dk *host*
Der er skræmmende hvor mange sider der kan defaces med simpel SQL injection, og det er endnu værrere når det kommer til XSS.
Men den gængse politik omkring sikkerhed, er jo ikke at sætte penge til det, før ens system bliver hacket ;)
Eller har db backups liggende i public directories *host* newz.dk *host*
Der er skræmmende hvor mange sider der kan defaces med simpel SQL injection, og det er endnu værrere når det kommer til XSS.
Men den gængse politik omkring sikkerhed, er jo ikke at sætte penge til det, før ens system bliver hacket ;)
Jeg forstår ikke hvorfor listen over disse usikre sider ikke er blevet offentliggjort så vi kan se hvilke sider man bør holde sig fra indtil de har fået styr på deres sikkerhed.
Ud over at fortælle omverdenen hvilke sider man bør holde sig fra vil sådan en liste også give de berørte sites en grund til at se på deres sikkerhed for at komme af listen igen. Så længe flok ikke ved hvilke sites det drejer sig om er der jo ingen grund til at de sites laver noget om
Ud over at fortælle omverdenen hvilke sider man bør holde sig fra vil sådan en liste også give de berørte sites en grund til at se på deres sikkerhed for at komme af listen igen. Så længe flok ikke ved hvilke sites det drejer sig om er der jo ingen grund til at de sites laver noget om
Givet, at ingen "fortjener" at blive hacked. Men omvendt kører en hvid mand heller ikke gennem Harlem med nedrullede vinduer.
Det skader ikke at være en lille smule proaktiv, når det kommer til sikkerhed, hvis man har en service med personfølsomme data.
Faktisk er det min personlige holdning, at der burde være opsyn og eftersyn på området - måske burde det endda indføres i straffeloven.
Men det er nok ligesom med farlige vej-/lyskryds; der reageres først EFTER ulykken er sket.
Det skader ikke at være en lille smule proaktiv, når det kommer til sikkerhed, hvis man har en service med personfølsomme data.
Faktisk er det min personlige holdning, at der burde være opsyn og eftersyn på området - måske burde det endda indføres i straffeloven.
Men det er nok ligesom med farlige vej-/lyskryds; der reageres først EFTER ulykken er sket.
Jeg vil tilslutte mig den holdning om at have et organg, der fører tilsyn med sikkerheden på en række virksomheder, som har med personfølsomme data at gøre. Specielt hvis de er offentlige services.
Og ja, når jeg læser en såden nyhedsoverskrift forventer jeg at få en opremsning af hvilke sites, der specielt er tale om. Ellers mener jeg ikke denne nyhed har en egentlig nyhedsværdi.
Hvis det er fordi de hellere vil give oplysningen til virksomhederne bag sitesne, i og med, at de ikke har testet dem, og derfor ikke vil risikere en falsk beskyldning, så forventer jeg at få en liste at se kort efter, at de har haft mulighed for at af-/bekræfte beskyldningen.
Det er jo forbrugernes data, der er tale om. Ikke virksomhedernes...
Og ja, når jeg læser en såden nyhedsoverskrift forventer jeg at få en opremsning af hvilke sites, der specielt er tale om. Ellers mener jeg ikke denne nyhed har en egentlig nyhedsværdi.
Hvis det er fordi de hellere vil give oplysningen til virksomhederne bag sitesne, i og med, at de ikke har testet dem, og derfor ikke vil risikere en falsk beskyldning, så forventer jeg at få en liste at se kort efter, at de har haft mulighed for at af-/bekræfte beskyldningen.
Det er jo forbrugernes data, der er tale om. Ikke virksomhedernes...
Syntes også at det ville være en god ide med en gruppe som kontrollere virksomheds sider. Man skal dog huske på at det er personer som arbejder med hjemmesider, og at sikre en hjemmeside på kryds og tværs kræver ofte en del erfaring med det, og inkludere ofte ligeledes IT-administratore(FireWall mm.). Det skulle jo nødig gå hen og blive sådan at nyuddannede IT-folk(programmøre, administratore mm.) ikke kan få job fordi de ikke har erfaringen inden for sikkerhed til det.
Man kunne måske lave noget ala smiley-ordningen inden for resturent branchen, med en warning først hvor man bliver oplyst om problemerne, og handles der ikke på det, så kan virksomheden eventuelt få en bøde.
Man kunne måske lave noget ala smiley-ordningen inden for resturent branchen, med en warning først hvor man bliver oplyst om problemerne, og handles der ikke på det, så kan virksomheden eventuelt få en bøde.
Jeg fatter ikke at XSS-problemer er så udbredte, eller SQL Injections for den sags skyld. Så svære er de altså heller ikke at undgå.
(Og ja, jeg arbejder bla. med den slags.)
Det går ret hårdt ud over min tiltro til... Tjah, er det mon udviklerne eller deres ledere man skal give skylden? Er det dovenskab eller inkompetence? Eller bliver det simpelt hen bevidst nedprioriteret? Det sidste ville være utroligt dumt, da det kun er under (teknisk) design-facen det tager tid, og selv der burde det være hurtigt overstået.
(Og ja, jeg arbejder bla. med den slags.)
Det går ret hårdt ud over min tiltro til... Tjah, er det mon udviklerne eller deres ledere man skal give skylden? Er det dovenskab eller inkompetence? Eller bliver det simpelt hen bevidst nedprioriteret? Det sidste ville være utroligt dumt, da det kun er under (teknisk) design-facen det tager tid, og selv der burde det være hurtigt overstået.
#6
Selvfølgelig bliver der ikke offentliggjort en liste over hvilke sites det drejer sig om.
Der er jo ikke tale om sites der pt. er inficerede. Men sites der har risiko for at blive inficerede.
I så fald ville hackere med ondsindede planer jo vide præcis hvilke sites de skal angribe.
Det er jo det samme som at offentliggøre, hvilke huse der står tomme, fordi familierne er på ferie.
Selvfølgelig bliver der ikke offentliggjort en liste over hvilke sites det drejer sig om.
Der er jo ikke tale om sites der pt. er inficerede. Men sites der har risiko for at blive inficerede.
I så fald ville hackere med ondsindede planer jo vide præcis hvilke sites de skal angribe.
Det er jo det samme som at offentliggøre, hvilke huse der står tomme, fordi familierne er på ferie.
Sidste år testede jeg en del større danske sites, og flere af dem var sårbare over for XSS-angreb. En del af dem er det stadig i dag. De fleste fejler når de viser søgetekst i et formularfelt, uden at konvertere tegn med HTML-betydning (som ", <, >, etc.). På nogle af disse sites vil en simpel søgetekst som
lukke input-tagget, og den efterfølgende tekst vil derefter blive behandlet som HTML. Og så behøver jeg vidst bare at nævne cookie/session hijacking.
" />
lukke input-tagget, og den efterfølgende tekst vil derefter blive behandlet som HTML. Og så behøver jeg vidst bare at nævne cookie/session hijacking.
#2 Helt enig.
#4 Korrekt, derved så artiklen dagens lys.
#6 Der er en grund til at listen ikke blev offentliggjort. Men kort sagt så er det store danske hjemmesider som rigtig mange mennesker bruger hver dag.
#9 Det er allerede svært nok for nyuddannede (herunder mig selv) at få arbejde i den danske IT-branche. For nogen ender det med at de må tage job som slet ikke har noget med det som de er uddannet til. F.eks. Supporter-job.
#12 Det koster ekstra penge og tid at skrive sikker kode, men det betaler sig i længden. (ja jeg arbejder også med den slags) Det kan være alle led, både udviklerne samt lederne som ikke gør deres arbejde godt nok med henblik på sikkerheden på danske hjemmesider.
#16 Så er du blevet stemplet ulovlig og uetisk hacker (hvis du da er det, det kræver mere end bare at kunne skrive " /> i en søgeformular.) og kan ifølge nogen individer (jeg er dog ligeglad) ikke arbejde i IT-sikkerhedsbranchen fordi du ikke har fået lov :-)
#0/Artiklen: Cross Site Scripting i sig selv behøver ikke være farligt, men så snart en smart nok (samt ondsindet) hacker finder sådan et sikkerhedshul på en hjemmeside med et login-system, ja så er der bingo.
Det er især her at det kan misbruges da cookies indeholder en "session" som kan "stjæles" vha. Cross Site Scripting aka XSS. Det kræver dog først at hackeren laver en "kage-tyv" og derefter laver et specielt XSS-link, som så en intetanende bruger skal klikke på.
Så snart brugeren klikker på dette link bliver brugeren sendt forbi hackerens "kage-tyv" som så stjæler "kagen" (;-D) og så bliver brugeren måske sendt tilbage til der hvor brugeren egentlig kom fra, eller til det link som der réelt blev linket til i første omgang eller hvad nu hackeren har skrevet i sin kage-tyv skrevet oftest i PHP.
Så skynder hackeren sig at bruge kagen selv, i stedet for at skulle skrive kodeord til at logge ind på en hjemmeside, det skal dog lige siges at "kagen" har altså en udløbsdato, som regel 1-24 timer, nogle steder holder den dog evigt.
Kort sagt: (non-persistent) Cross Site Scripting kræver at en intetanende bruger klikker på et link lavet af en ondsindet hacker. Det er især tyveri af kager som dette bruges til, men det er kun den mest almindelige form, alt hvad en hacker kan komme i tanke om som involverer javascript og html er gyldigt.
Persistent Cross Site Scripting betyder at scriptet bliver delvist eller helt gemt på siden, men så er vi altså henne i nærheden af HTML Injection.
PS: Der var en grund til at jeg ikke skrev den tekniske del hvis nogen begynder at brokke sig. I kan læse den originale artiklen på Version2 hvis I er interesseret.
#4 Korrekt, derved så artiklen dagens lys.
#6 Der er en grund til at listen ikke blev offentliggjort. Men kort sagt så er det store danske hjemmesider som rigtig mange mennesker bruger hver dag.
#9 Det er allerede svært nok for nyuddannede (herunder mig selv) at få arbejde i den danske IT-branche. For nogen ender det med at de må tage job som slet ikke har noget med det som de er uddannet til. F.eks. Supporter-job.
#12 Det koster ekstra penge og tid at skrive sikker kode, men det betaler sig i længden. (ja jeg arbejder også med den slags) Det kan være alle led, både udviklerne samt lederne som ikke gør deres arbejde godt nok med henblik på sikkerheden på danske hjemmesider.
#16 Så er du blevet stemplet ulovlig og uetisk hacker (hvis du da er det, det kræver mere end bare at kunne skrive " /> i en søgeformular.) og kan ifølge nogen individer (jeg er dog ligeglad) ikke arbejde i IT-sikkerhedsbranchen fordi du ikke har fået lov :-)
#0/Artiklen: Cross Site Scripting i sig selv behøver ikke være farligt, men så snart en smart nok (samt ondsindet) hacker finder sådan et sikkerhedshul på en hjemmeside med et login-system, ja så er der bingo.
Det er især her at det kan misbruges da cookies indeholder en "session" som kan "stjæles" vha. Cross Site Scripting aka XSS. Det kræver dog først at hackeren laver en "kage-tyv" og derefter laver et specielt XSS-link, som så en intetanende bruger skal klikke på.
Så snart brugeren klikker på dette link bliver brugeren sendt forbi hackerens "kage-tyv" som så stjæler "kagen" (;-D) og så bliver brugeren måske sendt tilbage til der hvor brugeren egentlig kom fra, eller til det link som der réelt blev linket til i første omgang eller hvad nu hackeren har skrevet i sin kage-tyv skrevet oftest i PHP.
Så skynder hackeren sig at bruge kagen selv, i stedet for at skulle skrive kodeord til at logge ind på en hjemmeside, det skal dog lige siges at "kagen" har altså en udløbsdato, som regel 1-24 timer, nogle steder holder den dog evigt.
Kort sagt: (non-persistent) Cross Site Scripting kræver at en intetanende bruger klikker på et link lavet af en ondsindet hacker. Det er især tyveri af kager som dette bruges til, men det er kun den mest almindelige form, alt hvad en hacker kan komme i tanke om som involverer javascript og html er gyldigt.
Persistent Cross Site Scripting betyder at scriptet bliver delvist eller helt gemt på siden, men så er vi altså henne i nærheden af HTML Injection.
PS: Der var en grund til at jeg ikke skrev den tekniske del hvis nogen begynder at brokke sig. I kan læse den originale artiklen på Version2 hvis I er interesseret.
MaXe (17) skrev:Det koster ekstra penge og tid at skrive sikker kode,
Meh, det meste af det blot et spørgsmål om at skrive pæn kode, så kommer sikkerheden af sig selv.
Min påstand: Hvis koden (og arkitekturen) er af god kvalitet, er sikkerhed noget man nemt/billigt kan få på plads, det er primært noget man bare har i baghovedet mens man designer.
Der kan være specielle situationer hvor man skal lave noget udelukkende for at højne sikkerheden (beskyttelse mod DOS osv), men det gælder ikke XSS og SQL injection. Der skal man blot designe og kode fornuftigt, så er der ingen problemer.
#17
Med 'testede' mener jeg såmænd bare, at jeg undersøgte om siderne var sårbare, hvis en hacker valgte dem som mål. Jeg burde måske have kontaktet dem vedrørende sårbarhederne, men for at være helt ærlig kan jeg ikke se, hvorfor jeg skal gøre dem den tjeneste. For som myplacedk skriver, kræver det ikke noget ekstra at sikre sig mod ting som XSS-angreb og SQL-injections; enhver programmør med respekt for sig selv ved og koder efter, at al input fra brugeren skal valideres/renses. Det må næsten være regel nummer ét.
Jeg kan til dels forstå hvis amatørhjemmestrikkede "Hello World!"-sites viser sig sårbare overfor disse angreb, men når det drejer sig om større sites med tusindvis af brugere er det direkte pinligt.
Med 'testede' mener jeg såmænd bare, at jeg undersøgte om siderne var sårbare, hvis en hacker valgte dem som mål. Jeg burde måske have kontaktet dem vedrørende sårbarhederne, men for at være helt ærlig kan jeg ikke se, hvorfor jeg skal gøre dem den tjeneste. For som myplacedk skriver, kræver det ikke noget ekstra at sikre sig mod ting som XSS-angreb og SQL-injections; enhver programmør med respekt for sig selv ved og koder efter, at al input fra brugeren skal valideres/renses. Det må næsten være regel nummer ét.
Jeg kan til dels forstå hvis amatørhjemmestrikkede "Hello World!"-sites viser sig sårbare overfor disse angreb, men når det drejer sig om større sites med tusindvis af brugere er det direkte pinligt.
#hvorfor
Selvom udviklerne er kompetente og der er afsat tid til at gøre det ordentligt, så kan det godt gå galt alligevel.
Det er et spørgsmål om matematik.
Hvis vi antager at
* i en web app er der 100 kritiske steder hvor der skal træffes et valg som påvirker sikkerheden
* en komptent web udvikler med kun normal stress har 99.9% sandsynlighed for at træffe det rigtige valg
så vil der være et sikkerhedshul i 9.5% af alle web sites selvom udviklerne er kompetente og der er afsat tid til at gøre det ordentligt.
Så man skal satse på en bred front:
- fornuftigt valg af arkitektur og teknologier som minimerer antallet af kritiske steder
- kompetente udviklere med rimeligt tid til opgaven
- manuel eller automatiseret code review
- sikkerheds test
Og selv da må man være forberedt på, at 100% sikkerhed ikke opnåes.
Selvom udviklerne er kompetente og der er afsat tid til at gøre det ordentligt, så kan det godt gå galt alligevel.
Det er et spørgsmål om matematik.
Hvis vi antager at
* i en web app er der 100 kritiske steder hvor der skal træffes et valg som påvirker sikkerheden
* en komptent web udvikler med kun normal stress har 99.9% sandsynlighed for at træffe det rigtige valg
så vil der være et sikkerhedshul i 9.5% af alle web sites selvom udviklerne er kompetente og der er afsat tid til at gøre det ordentligt.
Så man skal satse på en bred front:
- fornuftigt valg af arkitektur og teknologier som minimerer antallet af kritiske steder
- kompetente udviklere med rimeligt tid til opgaven
- manuel eller automatiseret code review
- sikkerheds test
Og selv da må man være forberedt på, at 100% sikkerhed ikke opnåes.
www.digitalsignatur.dk
www.folketinget.dk
www.eu-oplysningen.dk
http://cpr.dk
www.dininfo.dk
De har alle sammen XSS'es på deres side.
Jeg checkede det her for noget tid siden og skrev til Datatilsynet om problemet; de svarede mig aldrig overraskende nok.
Jeg føler virkelig ikke at det er okay for mange af disse hjemmesider som cpr.dk og digitalsignatur.dk at være åben for indtrængen. De har ansvaret for at beskytte vores privacy.
www.folketinget.dk
www.eu-oplysningen.dk
http://cpr.dk
www.dininfo.dk
De har alle sammen XSS'es på deres side.
Jeg checkede det her for noget tid siden og skrev til Datatilsynet om problemet; de svarede mig aldrig overraskende nok.
Jeg føler virkelig ikke at det er okay for mange af disse hjemmesider som cpr.dk og digitalsignatur.dk at være åben for indtrængen. De har ansvaret for at beskytte vores privacy.
#21
Lad mig citere fra en nylig tråd på eksperten.dk:
Lad mig citere fra en nylig tråd på eksperten.dk:
I sin simpleste form kan det være noget med at man efter et login sendes videre til index.php?bruger=1 hvor bruger=1 er id'et. Her kan man så eksempelvis lave således at der laves en kontrol på om bruger-variablen er et tal, at den er højere end 0 og mindre eller lig med det nuværende antal brugere i databasen. Derefter kan den så hente brugerinformation ud, f.eks. navn, alder, profiltekst osv - igen ud fra brugerid'et og fremvise på en personlig eller privat måde. Hvis det er en privat måde må man selvfølgelig vurdere hvor meget (hvis noget) skal være tilgængeligt for alle og lave en løsning der svarer til ens behov (umiddelbart lyder det til at du gerne vil have den helt privat). Der er ligeledes en del måder at kontrollere at privatheden overholdes, både i form af et logintjek og et tjek på om id'et på brugeren som er logget ind = id'et i databasen. Hvis ens - accepter og vis profil, ellers afvis.
Fritzo (22) skrev:De har alle sammen XSS'es på deres side.
Fritzo (22) skrev:Jeg checkede det her for noget tid siden og skrev til Datatilsynet om problemet; de svarede mig aldrig overraskende nok.
Hvis du har skrevet ordret som i første citat, så overrasker det mig ikke.
kronborg (19) skrev:enhver programmør med respekt for sig selv ved og koder efter, at al input fra brugeren skal valideres/renses. Det må næsten være regel nummer ét.
Sådan ville jeg nu kun håndtere kontrol-koder og den slags.
De typiske XSS og SQL-Injection problemer vil jeg påstå skyldes at folk roder datatyperne sammen.
Det man får ind er en binær blob. Det skal konveteres til plaintext, til SQL-streng, til HTML, og hvad ved jeg, på de rette steder og tidspunkter.
Jeg ser mange som tror at sikkerhed består i at man ikke må skrive specialtegn om <, >, % og " på hjemmesider, men det er da totalt misforstået. De er ikke forbudte, de skal bare håndteres korrekt. Og konverterer man korrekt mellem datatyperne kommer det helt af sig selv.
Det eneste jeg lige kan se man skal validere er nogle tossede kontrol-koder, især hvis input er i unicode. (Medmindre input er numerisk el. lign.)
arne_v (20) skrev:* en komptent web udvikler med kun normal stress har 99.9% sandsynlighed for at træffe det rigtige valg
Det er derfor den slags skal håndteres i frameworket. Jeg tror vi to er helt enige her, men jeg vil gerne uddybe det for andre alligevel.
Mest for mere eller mindre grønne udviklere:
Som noget som at escape HTML-tegn osv. bør håndteres af noget centralt kode.
Fx. ville jeg i PHP være varsom med at skrive ting som:
<p><?=$comment?><p>
Jeg aner ikke om $comment indeholder HTML som der er styr på, eller plaintext som kan indeholde hvad som helst. I det system jeg arbejder på til dagligt kan vi lave en søgning efter om nogen gør den slags.
Jeg arbejder ikke selv med PHP, men alternativet kunne måske være:
<p><?=toHTML($comment)?>
Dvs. man har en funktion som oversætter fra plaintext til HTML. Den SKAL man bruge hver gang. Hvis noget går galt her, så er det fordi man bevidst træder ved siden af sporet.
Ligesådan vil jeg ikke skrive "<input type=..." - det skal være noget centralt kode som ved alt om at lave form-elementer. Det tager sig af konvertere data fra plaintext til HTML (inkl. quotes), sørge for at alle parametre har gyldige værdier osv.
Sådan et system betyder at for almindelige situationer rammer udvikleren korrekt 100% af tiden, for der er intet man skal huske at tænke over.
Det ville have løst disse problemer:
http://www.digitalsignatur.dk/visSoeg.asp?artikelI...
http://www.eu-oplysningen.dk/textsearch/?op=search...
osv...
arne_v (23) skrev:I sin simpleste form kan det være noget med at man efter et login sendes videre til index.php?bruger=1 hvor bruger=1 er id'et.
Så ber man også selv om det. Men der er mange sider, der delvist er udviklet af praktikanter, der ikke tænker sig om. Jeg har ryddet op et par gange.
myplacedk (26) skrev:Sådan et system betyder at for almindelige situationer rammer udvikleren korrekt 100% af tiden, for der er intet man skal huske at tænke over.
Jeg tror ikke på 100%.
På en eller anden mystisk måde lykkes det altid for Murphys lov at slå til.
myplacedk (26) skrev:Dvs. man har en funktion som oversætter fra plaintext til HTML. Den SKAL man bruge hver gang. Hvis noget går galt her, så er det fordi man bevidst træder ved siden af sporet.
Det er mennesker vi snakker om.
Udvikleren taster det ind uden toHTML, skal lige til at sætte toHTML på, så ringer konen og fortæller at svigermor kommer på besøg i 4 uger, en halv time senere er den samtale slut og på ren autopilot klikkes der gem og check ind.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund