mboost-dp1
PBS A/S
Det var da utroligt som eksperter ikke ved noget om Node.js.
Med Node.js er server-sided javascripting en mulighed.
Så er det ikke længere browserens problem. Browseren skal bare lige fortolke fronten og sende de korrekte oplysninger, og så tager node.js sig af bagdelen.
Eksperter der ikke engang følger med udviklingen -.-
Med Node.js er server-sided javascripting en mulighed.
Så er det ikke længere browserens problem. Browseren skal bare lige fortolke fronten og sende de korrekte oplysninger, og så tager node.js sig af bagdelen.
Eksperter der ikke engang følger med udviklingen -.-
Der bør også overvejes i forhold til hvor nemt det er for hr. og fru Jensen at holde enkelte dele opdateret. Java er yderst besværligt at opdatere og holde ved lige. Browsere er en del nemmere og det øger sandsynligheden for at det bliver gjort og dermed at folk har nyeste og sikreste version.
#1 At bruge Javascript er jo ikke målet i sig selv.
Hvis koden alligevel skal køre på serveren (Hvilket den burde IMHO) så kan man jo lige så godt vælge et fornuftigt sprog i stedet for bastarden javascript.
Hvis koden alligevel skal køre på serveren (Hvilket den burde IMHO) så kan man jo lige så godt vælge et fornuftigt sprog i stedet for bastarden javascript.
#3
Når man bruger Node.js så skal man selv lave sin egen webserver. Der skal ikke Apache, lighttpd eller IIS indover.
Det betyder også at man selv står 100% for sikkerheden og derved ikke skal vente på en update udefra.
Node.js kan være mere lightweight og mere sikker hvis man ellers ligger tid og penge i det. Hvilket den danske stat elsker!
Når man bruger Node.js så skal man selv lave sin egen webserver. Der skal ikke Apache, lighttpd eller IIS indover.
Det betyder også at man selv står 100% for sikkerheden og derved ikke skal vente på en update udefra.
Node.js kan være mere lightweight og mere sikker hvis man ellers ligger tid og penge i det. Hvilket den danske stat elsker!
#3 Koden kommer til at køre på serveren uden tvivl... det andet vil jo være direkte dumt. Du snakker om et fornuftigt sprog uden at komme med nogle eksempler? HTML5 + Javascript er vejen frem. Java, Flash og alt hvad der ligner må for min skyld gerne skæres i flere stykker og smides i en giftig sump.
#1 #5 Det har intet med sagen at gøre. Grunden til at man kan argumentere for at Java er mere sikkert er at det kører med flere rettigheder end JavaScript gør på clientsiden. Du har derfor muligheder for at tilgå resources du ellers ikke kan, gemme filer på clientens computer (der ikke bar er en cookie eller et hack) og derved fx lave et robust fingeraftryk af computeren.
Det har intet at gøre med hvordan det fungerer på deres backend.
Det har intet at gøre med hvordan det fungerer på deres backend.
Usikkerheden med Java ligger jo ikke på de sider som bruger NemID, men andre sider som indsætter Java og udnytter huller.
Javascript har "alle" aktiveret i forvejen, så hvis NemID skifter til Javascript vil det ikke åbne op for flere sårbarheder end vi allerede er åbne overfor i dag.
Javascript har "alle" aktiveret i forvejen, så hvis NemID skifter til Javascript vil det ikke åbne op for flere sårbarheder end vi allerede er åbne overfor i dag.
#1
jeg savner virkelig ratingen: 'idiot'
... Newz-Johnny hvor er du ?
Grofle: NemID fungere på den måde at Java plugin'et opretter en sikker kanal (SSL) mellem din browser og DanID som hoster dit certificat - ved at logge på hentes certificatet som din browser så bruger til at identificere dig op imod din bank eller det offentlige.
Pointen er derfor at der skal foregå 'noget' clientside som snakker med en server et andet sted. Derfor kan JS erstatte Java.
Node.JS er en joke btw.
jeg savner virkelig ratingen: 'idiot'
... Newz-Johnny hvor er du ?
Grofle: NemID fungere på den måde at Java plugin'et opretter en sikker kanal (SSL) mellem din browser og DanID som hoster dit certificat - ved at logge på hentes certificatet som din browser så bruger til at identificere dig op imod din bank eller det offentlige.
Pointen er derfor at der skal foregå 'noget' clientside som snakker med en server et andet sted. Derfor kan JS erstatte Java.
Node.JS er en joke btw.
Jeg må indrømme jeg slet ikke forstå hvad de snakker om?
Det hele skal køre serverside. Alt info sendes via en SSL forbindelse så ingen kan opsnappe hvad der sendes? Javascript? og professorer? WTF? ;)
Det hele skal køre serverside. Alt info sendes via en SSL forbindelse så ingen kan opsnappe hvad der sendes? Javascript? og professorer? WTF? ;)
Bare lige for at forsvare mine udtalelser.
Ved at bruge server-sided javascripting kan man undgå exploits i browsere for derved at øge sikkerheden.
Med server-sided scripting behøver man jo kun et login i HTML hvor ingen javascript køre frontend. Dermed er sikkerheden forøget en del. Hvad angår SSL så hjælper det jo kun mod packet-tracere.
0 skrev:Hos Computerworld har de talt med Ivan Bjerre Damgård, der er professor i it-sikkerhed ved Aarhus Universitet, og han påpeger, at der også findes mange huller i de forskellige browsere. Dermed er det ikke sikkert, at sikkerheden bliver bedre med javascript end med Java.
Ved at bruge server-sided javascripting kan man undgå exploits i browsere for derved at øge sikkerheden.
Med server-sided scripting behøver man jo kun et login i HTML hvor ingen javascript køre frontend. Dermed er sikkerheden forøget en del. Hvad angår SSL så hjælper det jo kun mod packet-tracere.
#12
du er da tabt bag en vogn... eller tabt som baby ?
for du har endnu ikke fattet hvordan NemID fungere
https://www.nemid.nu/om_nemid/sikkerhed/teknikken_...
du er da tabt bag en vogn... eller tabt som baby ?
for du har endnu ikke fattet hvordan NemID fungere
https://www.nemid.nu/om_nemid/sikkerhed/teknikken_...
Hvorfor snakker folk om Java og JS på server backends?
Det her handler jo udelukkende om det der sker client side.
Og til det tror jeg begge ting er lige sikre. Det eneste der er vigtigt her, er at transporten mellem klient og server sikres - som udgangspunkt via SSL. Hvis der er en MITM der laver SSL stripping, så er vi jo lige fortabt om det er Java eller ej da MITM kan injecte alt.
Det man burde gøre mht. ovenover, er at få de 3 populære browsere til at bruge HSTS eller Pinned SSL (se bort fra at den blog er målrettet apps) overfor NemID (som i øvrigt burde blive en login portal så der kun er ét sted at logge ind - lidt alá OpenID).
Hvis ovenstående gennemføres, så ville en klient aldrig kunne komme ind på f.eks. Nordea, medmindre at:
* Nordea kan se at klienten er godkendt af NemID
* NemID kan godkende klienten via 2-factor
* Klienten kan se på NemID.nu, at det faktisk er Nordea Netbank de er på vej til (og ikke norde.a.dk) - f.eks. via en stor fed warning for alle hidtil ubrugte sider / førstegangs logins
* Klient ville aldrig taste en to-factor kode ind andre steder end på NemID.nu - fordi det har vi jo trænet dem i.
-----
Mht. MITM, det bliver umuligt på de store browsere (pga. Pinned SSL eller overholdelse af HSTS eller lign.) at lave MITM på nordea.dk, nemid.nu og tilsvarende - da browseren jo nægter det. Typosquatters må løses på en anden måde (aggressiv domain køb eller intelligent did-you-mean i browserne).
-----
Mht. trojaner og rootkits på klienten der inject browseren
Netbankernes sider er alligevel i HTML, så når først at klienten har godkendt sig via Java pluginnet, så står det rootkittet frit for at bruge det opsnappede kodeord (keyloggers anyone?), og så overføre penge uden brugeren har noget at skulle sige (Nordea kræver f.eks. ikke 2-factor ved overførsel af penge).
Det her handler jo udelukkende om det der sker client side.
Og til det tror jeg begge ting er lige sikre. Det eneste der er vigtigt her, er at transporten mellem klient og server sikres - som udgangspunkt via SSL. Hvis der er en MITM der laver SSL stripping, så er vi jo lige fortabt om det er Java eller ej da MITM kan injecte alt.
Det man burde gøre mht. ovenover, er at få de 3 populære browsere til at bruge HSTS eller Pinned SSL (se bort fra at den blog er målrettet apps) overfor NemID (som i øvrigt burde blive en login portal så der kun er ét sted at logge ind - lidt alá OpenID).
Hvis ovenstående gennemføres, så ville en klient aldrig kunne komme ind på f.eks. Nordea, medmindre at:
* Nordea kan se at klienten er godkendt af NemID
* NemID kan godkende klienten via 2-factor
* Klienten kan se på NemID.nu, at det faktisk er Nordea Netbank de er på vej til (og ikke norde.a.dk) - f.eks. via en stor fed warning for alle hidtil ubrugte sider / førstegangs logins
* Klient ville aldrig taste en to-factor kode ind andre steder end på NemID.nu - fordi det har vi jo trænet dem i.
-----
Mht. MITM, det bliver umuligt på de store browsere (pga. Pinned SSL eller overholdelse af HSTS eller lign.) at lave MITM på nordea.dk, nemid.nu og tilsvarende - da browseren jo nægter det. Typosquatters må løses på en anden måde (aggressiv domain køb eller intelligent did-you-mean i browserne).
-----
Mht. trojaner og rootkits på klienten der inject browseren
Netbankernes sider er alligevel i HTML, så når først at klienten har godkendt sig via Java pluginnet, så står det rootkittet frit for at bruge det opsnappede kodeord (keyloggers anyone?), og så overføre penge uden brugeren har noget at skulle sige (Nordea kræver f.eks. ikke 2-factor ved overførsel af penge).
#13: men er det skrevet i sten, at det absolut skal foregå sådan. Og hvis Det skal foregå sådan, er det så en nødvendighed at have et program kørende på klienten?
Det er blevet påstået før, at man kun krævede Java, fordi man havde et ønske om at kunne hente flere oplysninger om den computer der logges på fra, end det man som standard har adgang til i browseren.
Alt det her med 2-faktor login (kode plus nøglekort) osv, kræver ikke pine død Java eller lign. men kan i teorien godt klares serverside over en https-forbindelse.
intet sted jeg kan få øje på i linket https://www.nemid.nu/om_nemid/sikkerhed/teknikken_... står der nævnt noget der strengt taget kræver Java, og Java er da heller ikke nævnt.
Det er blevet påstået før, at man kun krævede Java, fordi man havde et ønske om at kunne hente flere oplysninger om den computer der logges på fra, end det man som standard har adgang til i browseren.
Alt det her med 2-faktor login (kode plus nøglekort) osv, kræver ikke pine død Java eller lign. men kan i teorien godt klares serverside over en https-forbindelse.
intet sted jeg kan få øje på i linket https://www.nemid.nu/om_nemid/sikkerhed/teknikken_... står der nævnt noget der strengt taget kræver Java, og Java er da heller ikke nævnt.
#20
i gamle dage hvor TDC udstedte certificater (digital signatur) til folk, blev der hentet et certifikat som folk havde liggende på deres pc. Når man så skulle på netbank skulle man bruge en kode til at 'lukke certificatet op'.
I dag er certifikaterne hosted hos DanID og hentes via NemID Java applet'en...
Om man henter hele certifikatet eller blot et token, ved jeg ikke...
i gamle dage hvor TDC udstedte certificater (digital signatur) til folk, blev der hentet et certifikat som folk havde liggende på deres pc. Når man så skulle på netbank skulle man bruge en kode til at 'lukke certificatet op'.
I dag er certifikaterne hosted hos DanID og hentes via NemID Java applet'en...
Om man henter hele certifikatet eller blot et token, ved jeg ikke...
>LordMike
(Lidt offtopic..)
Ang. Nordea (og flere andre) så bruger de til gengæld et ekstra sikkerhedslag i form af sms-verifikation ved større og/eller ukarakteristiske transaktioner. Er det først lykkes for en nettyv at logge ind med en 2-faktor verifikation, så er der også en vis sandsynlighed for, at han kan gentage det..
(Lidt offtopic..)
Ang. Nordea (og flere andre) så bruger de til gengæld et ekstra sikkerhedslag i form af sms-verifikation ved større og/eller ukarakteristiske transaktioner. Er det først lykkes for en nettyv at logge ind med en 2-faktor verifikation, så er der også en vis sandsynlighed for, at han kan gentage det..
#23, iflg. dem jeg snakker med (IT Sikkerhedsfolk) så sker alt signering serverside.
Rettelse:
En officiel kilde:
https://www.nemid.nu/om_nemid/sikkerhed/teknikken_...
"Generering og anvendelse af den private nøgle kan kun foregå i specielle sikrede kryptografiske hardware-moduler under brugerens fulde kontrol. Brugerens private nøgle forefindes på intet tidspunkt ukrypteret og kan ikke anvendes uden for det særligt sikrede kryptografiske hardwaremodul."
Rettelse:
En officiel kilde:
https://www.nemid.nu/om_nemid/sikkerhed/teknikken_...
"Generering og anvendelse af den private nøgle kan kun foregå i specielle sikrede kryptografiske hardware-moduler under brugerens fulde kontrol. Brugerens private nøgle forefindes på intet tidspunkt ukrypteret og kan ikke anvendes uden for det særligt sikrede kryptografiske hardwaremodul."
ko (22) skrev:#20
Hvis de skulle gøre det, så skulle de jo have adgang til den private nøgle. Den adgang må de ikke få. Det kan kun ske på klienten. De ser kun den krypterede udgave af nøglen.
De sender, i en krypteret tunnel, dit password / nøgle-kort kode direkte til en hardware enhed, som låser dit certifikat op.
Det er også derfor de ikke bare kan bruge HTTPS e.l. da det kun sikrer til webserveren, og det her skal krypteres hele vejen til deres hardware enhed, netop så dit password ikke kan opsnappes på vejen.
T-Hawk (26) skrev:
De sender, i en krypteret tunnel, dit password / nøgle-kort kode direkte til en hardware enhed, som låser dit certifikat op.
Det er også derfor de ikke bare kan bruge HTTPS e.l. da det kun sikrer til webserveren, og det her skal krypteres hele vejen til deres hardware enhed, netop så dit password ikke kan opsnappes på vejen.
Forudsat at de ikke laver ssl offload allerede i en load balancer.
T-Hawk (26) skrev:De sender, i en krypteret tunnel, dit password / nøgle-kort kode direkte til en hardware enhed, som låser dit certifikat op.
http://www.version2.dk/artikel/danid-vi-kan-ikke-overtage-nogens-nemid-og-dog-15918 skrev:For eksempel kunne vi ændre protokollen mellem Java-appletten og vores backend, så vi fik adgangskoden tilsendt i klartekst, hvor vi i dag slet ikke får den tilsendt.
LordMike (25) skrev:"Generering og anvendelse af den private nøgle kan kun foregå i specielle sikrede kryptografiske hardware-moduler under brugerens fulde kontrol. Brugerens private nøgle forefindes på intet tidspunkt ukrypteret og kan ikke anvendes uden for det særligt sikrede kryptografiske hardwaremodul."
Det er vel blot et meget sikret rum, hvor nøgler opbevares og genereres - uden menneskelig indvirken.
Hvorfor har de fleste som har sagt Grofle imod, fået en "flamebait" rating? Pga deres sprogbrug?
- Fordi ALT hvad Grofle har sagt i denne tråd, er da fuldstændigt forkert!
Det ville være godt hvis vi kunne disable Java overalt, uden at der kommer problemer når man skal logge på NemID, men fordi man laver en ren HTML NemID login form, gør bestemt ikke meget for sikkerheden. Og det kan sagtens laves uden Node.js.
Samlet set virker det som om at du (Grofle) har en basal mangel på viden om hvordan NemID/nettet/"server-client side" virker, og hvor store risici der er ved forskellige designs.
- Fordi ALT hvad Grofle har sagt i denne tråd, er da fuldstændigt forkert!
Der snakkes ikke om Node.js. Det er dig som bringer det ind, ingen "eksperter" har endnu kommenteret på Node.js hvad angår NemID.Grofle (1) skrev:Det var da utroligt som eksperter ikke ved noget om Node.js. Med Node.js er server-sided javascripting en mulighed.
Browseren skal stadig afvikle JS kode, hvis man vil benytte sig af JS i HTML koden, og det vil man typisk godt.Grofle (1) skrev:Så er det ikke længere browserens problem. Browseren skal bare lige fortolke fronten og sende de korrekte oplysninger, og så tager node.js sig af bagdelen.
Nu kører (node) JavaScript koden jo stadig i V8 motoren, som sagtens kan have sikkerhedsfejl (ligesom Apache, lighttpd eller IIS). Men igen, snakken går omkring der der foregår klient-side, ikke server-side (tror du har misforstået totalt hvad dette handler om).Grofle (5) skrev:#3
Når man bruger Node.js så skal man selv lave sin egen webserver. Der skal ikke Apache, lighttpd eller IIS indover.
Det betyder også at man selv står 100% for sikkerheden og derved ikke skal vente på en update udefra.
Så du anbefaler altså at vi skal til at anbefale at disable både Java OG JavaScript? Det skal nok blive populært når ingen Web2.0 sider virker mere :o)Grofle (12) skrev:Ved at bruge server-sided javascripting kan man undgå exploits i browsere for derved at øge sikkerheden.
Det ville være godt hvis vi kunne disable Java overalt, uden at der kommer problemer når man skal logge på NemID, men fordi man laver en ren HTML NemID login form, gør bestemt ikke meget for sikkerheden. Og det kan sagtens laves uden Node.js.
En del? Hvorfor er den det? Man kan jo stadig ikke deaktivere JavaScript uden at løbe ind i millioner af andre problemer med andre hjemmesider. Og hvornår var JavaScript sidst en sikkerhedsrisiko? JavaScript motoren i de forskellige browsere er ENORMT godt gennemtestet. Yderligere er det begrænset hvad man kan gøre i JavaScript og der er altså meget begrænset attack-vinkler, i forhold til fx Java.Grofle (12) skrev:Med server-sided scripting behøver man jo kun et login i HTML hvor ingen javascript køre frontend. Dermed er sikkerheden forøget en del.
packet-tracere? Det lyder som noget fra en dårlig B-film. SSL har mange problemer, ja, men det beskytter dog stadig godt imod et simpelt Man-in-the-middle angreb (bemærk: de angreb mod SSL CA'er har været brugt til spionage, da kreditkort(penge) kan stjæles nemt uden at bryde SSL).Grofle (12) skrev:Hvad angår SSL så hjælper det jo kun mod packet-tracere.
Samlet set virker det som om at du (Grofle) har en basal mangel på viden om hvordan NemID/nettet/"server-client side" virker, og hvor store risici der er ved forskellige designs.
"... og han påpeger, at der også findes mange huller i de forskellige browsere."
Dén sætning kunne godt lige omskrives indtil de rent faktisk finder et sikkerhedshul i Chrome?
Dén sætning kunne godt lige omskrives indtil de rent faktisk finder et sikkerhedshul i Chrome?
#30
Det virker helt surrealistisk at man får rating-tæv når man pointere hvor forkerte andre folk er på den...
men efterhånden kommer det ikke som en overraskelse herinde på newz..
Det virker helt surrealistisk at man får rating-tæv når man pointere hvor forkerte andre folk er på den...
men efterhånden kommer det ikke som en overraskelse herinde på newz..
#14
Hvis Hr. og Fru Jensen bruger Chrome, så behøver de ikke tænke over det. Jeg kan ikke huske om Firefox også opdaterer automatisk.
Nej. Det er et specielt modul. Der er indbygget batteri, der driver nogle sensorer. Hvis de sensorer detekterer nogen form for uautoriseret adgang (f.eks. fysisk vold), så nulstilles den chip, hvorpå krypteringskoden lagres. Da ingenting i de kryptografiske moduler findes ukrypteret kan ingenting genskabes; dataene er simpelthen tabt.
Modulerne opbevares så i et rum som bl.a. er foret med kobbernet så evt. elektromagnetiske bølger ikke bæres ud, og aflytning vha. antenner er derfor udelukket.
Læs evt. https://da.wikipedia.org/wiki/NemID#NemID
Hvis Hr. og Fru Jensen bruger Chrome, så behøver de ikke tænke over det. Jeg kan ikke huske om Firefox også opdaterer automatisk.
ko (29) skrev:LordMike (25) skrev:"Generering og anvendelse af den private nøgle kan kun foregå i specielle sikrede kryptografiske hardware-moduler under brugerens fulde kontrol. Brugerens private nøgle forefindes på intet tidspunkt ukrypteret og kan ikke anvendes uden for det særligt sikrede kryptografiske hardwaremodul."
Det er vel blot et meget sikret rum, hvor nøgler opbevares og genereres - uden menneskelig indvirken.
Nej. Det er et specielt modul. Der er indbygget batteri, der driver nogle sensorer. Hvis de sensorer detekterer nogen form for uautoriseret adgang (f.eks. fysisk vold), så nulstilles den chip, hvorpå krypteringskoden lagres. Da ingenting i de kryptografiske moduler findes ukrypteret kan ingenting genskabes; dataene er simpelthen tabt.
Modulerne opbevares så i et rum som bl.a. er foret med kobbernet så evt. elektromagnetiske bølger ikke bæres ud, og aflytning vha. antenner er derfor udelukket.
Læs evt. https://da.wikipedia.org/wiki/NemID#NemID
Lares (14) skrev:#2 Du tror at hr. og fru Jensen fatter at opdatere deres browsere? Jeg tror du giver dem alt for meget credit. Folk er teletubbies, der ikke forstår noget som helst om computere.
Korrekt - jeg har i forbindelse med de nylige problemer med java været inde på flere computere der havde forskellige versioner af java liggende parallelt. Når man prøvede at opdatere java, fik man således at vide at man havde den nyeste version (hvilket jo i princippet også var rigtigt).
Nå, det var en masse kævl fra min side, men pointen var at min erfaring er at det er væsentlig nemmere at sikre at en browser er opdateret end det er at sikre at java klienten er.
Et sprog er lige så sikkert som man kan kode det. At afvikle på en VM øger kompleksiteten, og dét kan give bøvl, for kan man få adgang til OS'et der afvikler (eller i dette tilfælde VM'en) så er der nogenlunde frit slag. At introducere et kunstigt lag mere, er aldrig vejen frem når det gælder sikkerhed.
Montago (40) skrev:#39
fordi folk køre jo ikke med ældre versioner af browsere... DOH !
Jo, dem som stadig kører Windows 98 gør vel.
De fleste nyere browsere jeg har set, opdaterer sig selv helt automatisk - noget Java kræver at man gør manuelt (og den prøver at snige toolbars ind).
Grofle (1) skrev:Det var da utroligt som eksperter ikke ved noget om Node.js.
Med Node.js er server-sided javascripting en mulighed.
Så er det ikke længere browserens problem. Browseren skal bare lige fortolke fronten og sende de korrekte oplysninger, og så tager node.js sig af bagdelen.
Eksperter der ikke engang følger med udviklingen -.-
Jeg kender ikke node.js, men når du snakker server-sided Javascripting, så har jeg svært ved at se hvordan det er anderledes en en ASP.net server, eller PHP server..?
Når jeg sender et HTTP Request til en server, så er det serveren "engine" som findes ud af hvordan at HTML delen skal se ud som jeg modtager, og når jeg laver et HTTP Post, så er det serverens engine som skal behandle de data, og evt. smide de data i en database, eller en session.
om jeg bruger PHP, ASP.net eller Node.js har jeg svært ved at se ændre noget, for i sidste ende er hele klient delen stadigvæk samme HTML.
Der står vi igen tilbage med ex. http post, java, eller server/client javascript (uden behov for node.js, da dette fint kan behandles af IIS eller Apache)
Det du evt. har ret i (hvis jeg forstår dig ret) er at hvis der er en sikkerhedsfejl i javascript, så vil den fejl formentlig aldrig være et problem, hvis alt javascript foregår server-side.
Men igen, PHP og ASP.net kan formentligt det samme som node.js, hvis ikke mere, så hvorfor ikke bruge nogle eksisterende og supporterede teknologier, som ikke er i v0.8.18 - med andre ord, beta..!
Chrome er en enormt sikker browser, ja, men som alt næsten alt andet software er Chrome ikke perfekt, og der ER fundet massere af sikkerhedshuller i Chrome*.ShamblerDK (31) skrev:"... og han påpeger, at der også findes mange huller i de forskellige browsere."
Dén sætning kunne godt lige omskrives indtil de rent faktisk finder et sikkerhedshul i Chrome?
(* = de fleste fejl har været i forskellige dele af Chrome, og har ikke alene kunne bruges til at exploite Chrome, men kombinere man flere fejl kan det føre til kørsel af vilkårlig kode: http://blog.chromium.org/2012/05/tale-of-two-pwnie... ).
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