mboost-dp1
unknown
pffff! Så længe alle kan udvikle ActiveX komponenter, er det da klart at der vil findes ActiveX komponenter derude med fejl i.
Det er da på ingen måde overraskende?
Det er da på ingen måde overraskende?
#1 .. Det er jo ikke fejl i eksisterende komponenter, der skal undersøges, som jeg ser det, men derimod mulighed for at kreere komponenter, der kompromitterer sikkerheden gennem ActiveX.
#7
Hvis du skulle lave den sammenligning, så skulle de teste efter huller i alternative activex implementeringer..
Lidt trist at de inkluderede fejl i 3rd party ting i Month of Apple Bugs saa ;)
Hvis du skulle lave den sammenligning, så skulle de teste efter huller i alternative activex implementeringer..
#7
Det kan jo også benyttes i windows applications. Men jo, det er en IE ting.
Men med så mange dumme IE brugere, så er det vel også rimeligt at Microsoft retter sikkerhedsfejlene i ActiveX.
Men nu burde de også have et par på hovedet.. en webside skal altså IKKE kunne åbne mit CDROM drev, vel hr. gates.
Virker ActiveX overhovedet i andet end IE og Outlook? :D
Det kan jo også benyttes i windows applications. Men jo, det er en IE ting.
Men med så mange dumme IE brugere, så er det vel også rimeligt at Microsoft retter sikkerhedsfejlene i ActiveX.
Men nu burde de også have et par på hovedet.. en webside skal altså IKKE kunne åbne mit CDROM drev, vel hr. gates.
#10
Det kommer bare rigtig meget an på hvad man laver. Et intranet-system kunne foreksempel godt tænkes at ville løfte den indloggede Windows-bruger. Til sådan nogle systemer er ActiveX sådanset smart nok, men vil nu også stoppe med rosen der.
#0
Uanset hvilket programmel der bliver fundet fejl i, er det da kun positivt når de bliver rettet, altså fejlene - Det må vi gå ud fra at de gør.
Det kommer bare rigtig meget an på hvad man laver. Et intranet-system kunne foreksempel godt tænkes at ville løfte den indloggede Windows-bruger. Til sådan nogle systemer er ActiveX sådanset smart nok, men vil nu også stoppe med rosen der.
#0
Uanset hvilket programmel der bliver fundet fejl i, er det da kun positivt når de bliver rettet, altså fejlene - Det må vi gå ud fra at de gør.
Kan ikke se det vilde ved denne "Month of ActiveX bugs".
Manden bruger kun obskure tredjepartsplugins, altså kun nogle plugins der bruges på intranets i meget få firmaer.
Det er end ikke selve ActiveX-teknologien, han exploiter, men bare nogle plugins, ingen bruger.
Manden bruger kun obskure tredjepartsplugins, altså kun nogle plugins der bruges på intranets i meget få firmaer.
Det er end ikke selve ActiveX-teknologien, han exploiter, men bare nogle plugins, ingen bruger.
Hvad bliver det mon næste gang, month of the plugin bugs ?
Så længe det er muligt at skrive udvidelser til populært software, vil det være en risiko for at nogen af de udvidelser indeholder fejl. Så gør det ikke nogen forskel hvilken plugin standard der bliver brugt til at skrive softwaren.
Så længe det er muligt at skrive udvidelser til populært software, vil det være en risiko for at nogen af de udvidelser indeholder fejl. Så gør det ikke nogen forskel hvilken plugin standard der bliver brugt til at skrive softwaren.
#14 Du skulle evt. læse de andre kommentarer først.
Hvis pluginnet kompromitterer sikkerheden, så skal det forbedres. Hvis det kan lade sig gøre at skrive et buffer overflow i pluginnet, som giver root access så er det pluginnet, der er fejl i.
Hvis pluginnet kompromitterer sikkerheden, så skal det forbedres. Hvis det kan lade sig gøre at skrive et buffer overflow i pluginnet, som giver root access så er det pluginnet, der er fejl i.
#11
Du skulle kigge nærmere på XUL :-) Det er sådan set Mozillas pendant til ActiveX eller hvad man nu kan kalde det.
XUL og dets javascript API har adgang til super meget, og Firefox er selv skrevet i det. Derfor du f.eks. kan få en IRC client til Firefox , som er skrevet i javascript.
JScript bruger så ActiveX istedet, og er IEs pendant. Men modsat Mozilla har IE ikke et såkaldt "sandbox" / "safe" area. XUL er meget begrænset medmindre du kører det fra en chrome:// url, og hvis det *skal* køres via. web så skal det være signet (og dermed også godkendes af brugeren eller systemet).
ActiveX burde have været lavet sådan at det kun virkede på intranet domain og/eller hta. Det skulle aldrig have været tilladt at kører på world wide web.
Offtopic:
- XUL er ret smart :-)
http://www.dragons-lair.org/upload/blog.admin.png
Og meget nemt at udvikle i. Så hvis nogen står og skal kode en intranet løsning, er det da en teknologi som kan anbefales.
Du skulle kigge nærmere på XUL :-) Det er sådan set Mozillas pendant til ActiveX eller hvad man nu kan kalde det.
XUL og dets javascript API har adgang til super meget, og Firefox er selv skrevet i det. Derfor du f.eks. kan få en IRC client til Firefox , som er skrevet i javascript.
JScript bruger så ActiveX istedet, og er IEs pendant. Men modsat Mozilla har IE ikke et såkaldt "sandbox" / "safe" area. XUL er meget begrænset medmindre du kører det fra en chrome:// url, og hvis det *skal* køres via. web så skal det være signet (og dermed også godkendes af brugeren eller systemet).
ActiveX burde have været lavet sådan at det kun virkede på intranet domain og/eller hta. Det skulle aldrig have været tilladt at kører på world wide web.
Offtopic:
- XUL er ret smart :-)
http://www.dragons-lair.org/upload/blog.admin.png
Og meget nemt at udvikle i. Så hvis nogen står og skal kode en intranet løsning, er det da en teknologi som kan anbefales.
#15 Jeg har læst alle andres kommentarer først.
Hvis et plugin er skrevet i eksekverbar kode så er der ingenting plugin modellen kan gøre for at sikre plugin'et. Skulle modellen beskytte mod farlig kode så ville det være nødvendigt at sandboxe plugin'et og emulere alle de funktioner som operativ systemet normalt tilbyder dig.
Den eneste anden måde at gøre en plugin model fuldkommen sikker er ved ikke at tillade eksekverbar kode, men gør du det så vil du samtidig sætte kæmpe begrænsninger på hvad plugin'et kan gøre.
Hvis et plugin er skrevet i eksekverbar kode så er der ingenting plugin modellen kan gøre for at sikre plugin'et. Skulle modellen beskytte mod farlig kode så ville det være nødvendigt at sandboxe plugin'et og emulere alle de funktioner som operativ systemet normalt tilbyder dig.
Den eneste anden måde at gøre en plugin model fuldkommen sikker er ved ikke at tillade eksekverbar kode, men gør du det så vil du samtidig sætte kæmpe begrænsninger på hvad plugin'et kan gøre.
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