mboost-dp1
Microsoft Corporation
Utroligt de ikke bare lægger mere arbejde i at lave en skudsikker JS sandkasse til deres browser der vil fange 100% hvis det laves rigtigt.
Deres nye system lyder meget mere som en lappeløsning. Det varer ikke længe før der bliver lavet scripts der specifiks omgår deres analyse som så tvinger MS til at lave den endnu mere dybdegående. Igen bliver de scripts mere komplekse og vi har en skrue uden ende + en browser der tager flere sekunder om at analysere scripts for malware.
Skulle heller ikke undre mig at Zoozle kunne være målgruppen for andre angreb: Lav et komplekst nok script der får den til at crashe og udnyt den crash til at eksekvere kode uden for browseren.
Deres nye system lyder meget mere som en lappeløsning. Det varer ikke længe før der bliver lavet scripts der specifiks omgår deres analyse som så tvinger MS til at lave den endnu mere dybdegående. Igen bliver de scripts mere komplekse og vi har en skrue uden ende + en browser der tager flere sekunder om at analysere scripts for malware.
Skulle heller ikke undre mig at Zoozle kunne være målgruppen for andre angreb: Lav et komplekst nok script der får den til at crashe og udnyt den crash til at eksekvere kode uden for browseren.
#2
fordi skudsikker JS = ingen JS
JS kan snildt stjæle dine passwords, lave DDoS attack, XSS hacking osv...
men kan også lave så mange cool og gode ting...
en masse onde scripts kan sagtens laves med "god kode" - men vil ikke kunne ses uden at gennemskue kodens natur...
jeg vil tro at MS kigger på intentionen i JS koden - fremfor at "lappe huller" som jo ikke nødvendigvis findes...
fordi skudsikker JS = ingen JS
JS kan snildt stjæle dine passwords, lave DDoS attack, XSS hacking osv...
men kan også lave så mange cool og gode ting...
en masse onde scripts kan sagtens laves med "god kode" - men vil ikke kunne ses uden at gennemskue kodens natur...
jeg vil tro at MS kigger på intentionen i JS koden - fremfor at "lappe huller" som jo ikke nødvendigvis findes...
Jeg har altid undret mig over at JS får lov af browseren til at læse det data som browseren selv auto-filler ind i form-elementer. Er moderator i et andet forum som tillod andre moderatorer at indsætte JS og HTML i forum posts. Lavede et forsøgs forum post hvor den poppede op og viste dig dit kodeord i en MessageBox. Kunne lige så godt have sendt kodeordene til en anden server.
Min pointe er bare at der er visse ting som bare ikke burde være tilladt at gøre for JS i browseren. Eller i det mindste laves options for det.
XSS: Alt javascript der kaldes fra siden skal være fra .JS filer der findes på samme domain som siden der vises. (ingen tilladte <script> tags indeholdende JS.) (Option) - Det ville fjerne en del javascript injection sikkerhedsfejl men ikke alle.
DDos: Sæt et limit på antal XmlHttpRequest's der må ske pr sekund efter et par sekunder efter siden er loaded.
Passwords: (som beskrevet før) JS kan ikke læse data som browseren har indsat i input felter (evt. kun deres længde måske)
Langt de fleste huller kan løses med en bedre sikkerhedspolitik over hvad JS egentligt har lov til. F.eks. viser <canvas> elementet en stor del sikkerhed inden for cross-domain billeder. Du kan sagtens loade et billede fra et andet domain end der hvor billedet er hostet, men du kan bare ikke læse billedets indhold.
Det vil selvfølgelig ikke fange alle sikkerhedsproblemer, men jeg ville mene at det er en bedre løsning end et system der gætter sig frem til om noget er skadeligt eller ej. Jeg ville bare føle det som en falsk tryghed ellers.
Min pointe er bare at der er visse ting som bare ikke burde være tilladt at gøre for JS i browseren. Eller i det mindste laves options for det.
XSS: Alt javascript der kaldes fra siden skal være fra .JS filer der findes på samme domain som siden der vises. (ingen tilladte <script> tags indeholdende JS.) (Option) - Det ville fjerne en del javascript injection sikkerhedsfejl men ikke alle.
DDos: Sæt et limit på antal XmlHttpRequest's der må ske pr sekund efter et par sekunder efter siden er loaded.
Passwords: (som beskrevet før) JS kan ikke læse data som browseren har indsat i input felter (evt. kun deres længde måske)
Langt de fleste huller kan løses med en bedre sikkerhedspolitik over hvad JS egentligt har lov til. F.eks. viser <canvas> elementet en stor del sikkerhed inden for cross-domain billeder. Du kan sagtens loade et billede fra et andet domain end der hvor billedet er hostet, men du kan bare ikke læse billedets indhold.
Det vil selvfølgelig ikke fange alle sikkerhedsproblemer, men jeg ville mene at det er en bedre løsning end et system der gætter sig frem til om noget er skadeligt eller ej. Jeg ville bare føle det som en falsk tryghed ellers.
#4
Det er godt noget af en firkantet verden du lever i..
Som allerede er nævnt så er problemet, at man kan bruge nogle funktioner til både gode og onde ting.. Det du foreslår er at fjerne disse funktioner, så de i hvert fald ikke kan blive brugt "ondt" - Men så kan de bare heller ikke blive brug på den "gode" måde..
- Og så vil der være meget af JS' funktionalitet der vil forsvinde..
@Topic
Synes umiddelbart det lyder som en god ide.. men man kan sige det vil give nogle "komplikationer" mht. at måle hastighed,,
Det er godt noget af en firkantet verden du lever i..
Som allerede er nævnt så er problemet, at man kan bruge nogle funktioner til både gode og onde ting.. Det du foreslår er at fjerne disse funktioner, så de i hvert fald ikke kan blive brugt "ondt" - Men så kan de bare heller ikke blive brug på den "gode" måde..
- Og så vil der være meget af JS' funktionalitet der vil forsvinde..
@Topic
Synes umiddelbart det lyder som en god ide.. men man kan sige det vil give nogle "komplikationer" mht. at måle hastighed,,
#4
Af hvad jeg har læst mig til angående Zozzle, så er den ikke begrænset til IE (endnu).
Så måske handler det slet ikke om nogen "lappe løsninger" til IE, men mere som i form af en hjælp til brugere i alt almindelighed, f.eks. i form af MSE.
Dog er der mange der snakker, men der findes ikke vildt mange fakta endnu, så ikke andet for at se og vente.
Men vil nu som #5 heller ikke mene, at begrænse JS for meget er en god løsning.
Af hvad jeg har læst mig til angående Zozzle, så er den ikke begrænset til IE (endnu).
Så måske handler det slet ikke om nogen "lappe løsninger" til IE, men mere som i form af en hjælp til brugere i alt almindelighed, f.eks. i form af MSE.
Dog er der mange der snakker, men der findes ikke vildt mange fakta endnu, så ikke andet for at se og vente.
Men vil nu som #5 heller ikke mene, at begrænse JS for meget er en god løsning.
#5
Jeg vil langt hellere miste den "gode" funktionalitet på websiderne, end at risikere at "onde" websider har mulighed for at misbruge funktionaliteten.
Jeg vil give Andos fuldstændig ret i at det er tåbeligt så meget Javascript har adgang til - Det skriger efter at blive misbrugt og gør det i høj grad også, uden at folk er klar over det.
Jeg vil langt hellere miste den "gode" funktionalitet på websiderne, end at risikere at "onde" websider har mulighed for at misbruge funktionaliteten.
Jeg vil give Andos fuldstændig ret i at det er tåbeligt så meget Javascript har adgang til - Det skriger efter at blive misbrugt og gør det i høj grad også, uden at folk er klar over det.
#1
Den analyserer 1 kB javascript kode på 3-4 ms, det er pænt hurtigt.
20 gange så stor mængde javascript kode vil stadig ikke genere nogen, skal jo kun gøres en gang per side.
Den analyserer 1 kB javascript kode på 3-4 ms, det er pænt hurtigt.
20 gange så stor mængde javascript kode vil stadig ikke genere nogen, skal jo kun gøres en gang per side.
Jeg siger heller ikke at det skal være uomgåelige begrænsninger. Hvis der dannes alt alt for mange XmlHttpRequests kan browseren eventuelt bare lige vise en notification der påpeger at der sker meget bagved og at det kan reducere browserens performance (og/eller være en sikkerhedsrisiko) og så spørge om man vil afbryde det.
Kan ærligt talt ikke se hvorfor det skulle være at begrænse JS meget hvis man bare implementerer det ordentligt. At JS kan læse de data som en password manager indsætter synes jeg ikke jeg kan finde én eneste årsag til er en god idé.
Jeg kender selvfølgelig ikke til alle metoderne som JS kan misbruges på (ingen kan kende alle metoder) men igennem eksempler kan man da komme med ideer til at minimere sikkerhedsbrister samt sørge for at det ikke går ud over JS' funktionalitet.
Kan ærligt talt ikke se hvorfor det skulle være at begrænse JS meget hvis man bare implementerer det ordentligt. At JS kan læse de data som en password manager indsætter synes jeg ikke jeg kan finde én eneste årsag til er en god idé.
Jeg kender selvfølgelig ikke til alle metoderne som JS kan misbruges på (ingen kan kende alle metoder) men igennem eksempler kan man da komme med ideer til at minimere sikkerhedsbrister samt sørge for at det ikke går ud over JS' funktionalitet.
Alle ændringer i JS-motorer er irrelevante så længe alverdens browsere ikke bliver opdateret og der stadig er folk som bruger IE6.
Desuden vil det være bedre at ændre autofuldførelse til kun at indsætte stjerner/prikker i password felter, og så først ved form submit sende passwordet med.
Ingen grund til at begrænse et programmeringssprog. Så er det bedre at begrænse den sandbox den kører i.
Desuden vil det være bedre at ændre autofuldførelse til kun at indsætte stjerner/prikker i password felter, og så først ved form submit sende passwordet med.
Ingen grund til at begrænse et programmeringssprog. Så er det bedre at begrænse den sandbox den kører i.
Andos (11) skrev:Hvis der dannes alt alt for mange XmlHttpRequests kan browseren eventuelt bare lige vise en notification der påpeger at der sker meget bagved
Lige for at pointere:
XmlHttpRequest er kun ondt mod serveren som hoster dit JS (eller i tilfælde af XSS - stadigvæk kun serveren som hoster)
Cross-Site er ikke tilladt
1000 iFrames er derimod i stand til at DDoS en fjern-server...
Moog (10) skrev:#7 Så slå JS fra i din browser...
Hvis jeg slog alt funktionalitet fra, ville ingen websider virke. Hvis jeg kunne slå den funktionalitet fra som tillod Javascript at læse min history, indholdet i kodeords felter, mine tabs, min cache og alle mulige andre ting som den ikke har noget at bruge til, så ville jeg have et funktionelt, men sikkert system.
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