Hoofdcategorieën

[RSS] Index » Nieuws » Pro » Software » Beheer & Beveiliging » Browserlek veroorzaakt door combinatie IE en Firefox

Browserlek veroorzaakt door combinatie IE en Firefox

Door Dimitri Reijerman, woensdag 11 juli 2007 15:48
Bron: Betanews, submitter: Remco Kramer, views: 31.699

Door een recent ontdekt lek in Internet Explorer is het voor kwaadwillenden mogelijk om via Firefox kwaadaardige code op een pc te draaien. Beveiligingsbedrijf Secunia bestempelt de bug als 'zeer kritiek', maar ziet ook Firefox als schuldige.

Firefox-aanroep vanuit IEVoorwaarde voor het slagen van een mogelijke exploit is dat de gebruiker zowel Firefox 2.0 als Internet Explorer op zijn pc geïnstalleerd heeft. Het probleem zit onder andere in de manier waarop IE omgaat met het controleren van links. Indien een aangeklikte link begint met 'firefoxurl://', opent IE de concurrerende browser zonder enige verificatie van de uri. Met dergelijke uri's kan Mozilla's Chrome-framework misbruikt worden om zo via Firefox kwaadaardige code uit te voeren. Een gemanipuleerde link werkt niet wanneer deze in Firefox wordt aangeklikt, omdat de browser dan wel een controle op de meegeleverde parameters uitvoert. De fout is ontdekt door Thor Larholm. De beveiligingsanalist ontdekte vorige maand nog enkele kritieke fouten in Safari voor Windows. Volgens Larholm vertoont de door hem blootgelegde fout veel overeenkomsten met een inmiddels door Apple gedicht lek in Safari.

Ondertussen ruziën verschillende partijen over wie nu precies schuldig is aan de 'cross-browser-bug'. Microsoft ontkent dat Internet Explorer een fout bevat en ziet geen reden voor een patch, terwijl Larholm meent dat juist in IE de kiem voor een eventuele aanval reeds gezaaid is. Secunia ziet Firefox als de zwakke schakel, omdat de Mozilla-programmeurs niet goed nagedacht zouden hebben bij de ontwikkeling van de protocolregistratie. Daar lijkt een kern van waarheid in te zitten, want Mozilla heeft ondertussen laten weten dat het in de eerstvolgende update van Firefox de url protocol handler zal aanpassen. Een woordvoerder van het opensourcebedrijf benadrukte dat 'zonder patches voor IE' ook andere applicaties gevaar lopen. Daarnaast maakte Mozilla nog bekend dat de eerste bèta van Firefox 3 met zeker zes weken is uitgesteld tot 18 september.

Volgende 16:14
Vorige 15:08

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 128 reacties zichtbaar1280 Neutraal: 109 reacties zichtbaar109+1 Meerwaarde: 44 reacties zichtbaar44+2 Verplicht leesvoer: 6 reacties zichtbaar6
«  1  2  3  4  »

Door Webgnome, woensdag 11 juli 2007 15:52

Score: 1
Het is volgens mij overduidelijk. Internet explorer forward het verzoek van een pagina naar Firefox/Mozilla dat deze dan slordig omspringt is niet meer Internet Explorer zijn probleem anders kan deze browser wel overal rekening mee gaan houden (en daar is geen beginnen aan).

Met andere woorden. Firefox devs: Bouw de verificatie van firefoxurl links zo dat het ook in dit scenario zijn werk doet en alles is opgelost.

Door Freee!!, woensdag 11 juli 2007 15:57

Score: 0
Dat ben ik niet helemaal met je eens. Internet Explorer geeft de URL zonder verificatie door. Dit betekent dat ook andere applicaties (voornamelijk concurrerende browsers) met dit soort problemen te maken (kunnen) krijgen.

Door Webgnome, woensdag 11 juli 2007 16:01

Score: 1
Dan nog blijft het een zaak van de tweede browser om die aanvraag goed te behandelen (en dus eerst een security verificatie uit te voeren ). Waarom controlleerd een browser, firefox in dit geval, de link wel als deze in firefox zelf wordt ingetikt?

Door Ras, woensdag 11 juli 2007 16:11

Score: 0
Waarom controlleerd een browser, firefox in dit geval, de link wel als deze in firefox zelf wordt ingetikt?
Omdat het een protocol van firefox zelf is. Lijkt me vrij raar als ze er dan zelf geen rekening mee houden.

Ik kan het me overigens goed voorstellen dat microsoft ontkend dat IE een fout bevat op dit gebied, omdat ze niet elke keer als ze bij Mozilla iets nieuws hebben bedacht, zich daar op aan kunnen gaan passen.

[Reactie gewijzigd door Ras]

Door Webgnome, woensdag 11 juli 2007 18:32

Score: 0
Omdat het een protocol van firefox zelf is. Lijkt me vrij raar als ze er dan zelf geen rekening mee houden.
Waarom controleerd firefox de link dan niet als deze via een andere applicatie wordt door gegeven.

Door Hero Of Time, woensdag 11 juli 2007 19:18

Score: 0
@Webgnome:
Dat is nou juist het probleem, dat gebeurt dus niet.

Ik leg ook de fout bij FF. Als ik informatie zou hebben over een bepaald onderwerp en dat via een koerier naar mijn baas laat sturen, zou de koerier dan moeten kijken of de informatie wel klopt of moet mijn baas dat doen? IE is niets meer dan een messenger, en het spreekwoord zegt al, don't kill the messenger. Schuif dus niet alles af op MS, maar begin eerst eens bij jezelf te kijken. Want als je intern wel een check doet, waarom dan niet wat je extern krijgt.

[Reactie gewijzigd door Hero Of Time]

Door meneer r, donderdag 12 juli 2007 00:26

Score: 1
Wel als de messenger het bericht VERKEERD door geeft. MS dient de url te escapen zodat het als 1 argument meegegeven wordt.

Door Fiander, donderdag 12 juli 2007 21:51

Score: 2
dus jij verwacht dat microsoft van ELK programma wat eventueel opgestart word via IE, dat ze de mogelijke opstart parameters kennen ?

IE weet niet wat FF wel en of niet kan, en geeft gewoon het bericht door aan FF, aan FF om dan te kijken ofdat het geen onzin is.

Door MrE, donderdag 12 juli 2007 09:53

Score: 1
Wat zou je er van denken dat jij controleerd of het bericht goed is?
Jouw baas mag er toch van uit gaan dat jij je werk goed doet? Of moet jouw baas iemand inhuren die controleert of jij geen fouten maakt?

Het probleem zit 'm niet in FF, want FF behandelt de link wel correct (dat wil zeggen er gebeurt niets).
Het probleem zit 'm niet in IE, want IE geeft de boel keurig door zoals gevraagd wordt.

Het probleem zit 'm in een afspraak tussen browsermakers. Daar lijkt zo te zien een verschil van mening te zijn over wie de controle doet.
Microsoft denkt blijkbaar dat de einduitvoerende de verantwoordelijke is, en Firefox gaat er van uit dat Microsoft zijn werk goed doet, en dit niet nog eens hoeft te controleren.

Een afspraak over afhandleing van dit soort zaken is wellicht meer op zijn plaats dan het roepen van eins schuld dit is.

Door matiov, donderdag 12 juli 2007 13:25

Score: 0
FF moet gewoon niks vertrouwen wat niet van hem afkomt... IE moet behandeld worden als een 'untrusted application'. Daarom moet alles worden gecheckt. FF's schuld dus..

Door Freee!!, woensdag 11 juli 2007 16:17

Score: 0
Dan nog blijft het een zaak van de tweede browser om die aanvraag goed te behandelen (en dus eerst een security verificatie uit te voeren ).
Dat ben ik volkomen met je eens. Mijn punt was slechts dat het probleem niet uitsluitend bij Firefox ligt, maar dat Internet Explorer zich er wel heel gemakkelijk vanaf maakt.

Door i-chat, woensdag 11 juli 2007 16:32

Score: 1
en terecht, - in principe kan MS niet eens die check uitvoeren omdat ze 'in principe' helemaal niet eens 'kunnen' weten waarop ze moete checken,
elk programma dat links binne krijgt het zei via een klik of via een commandline of via <voeg zelf iets toe> dient gewoon te zorgen dat ze afdoende foutcorrectie uitvoeren,

Door Countess, woensdag 11 juli 2007 17:17

Score: 0
implementeer dan heel die firefoxurl functie niet als je er geen tijd in wilt stoppen om het degelijk te maken.

Door RM-rf, woensdag 11 juli 2007 19:27

Score: 2
msie heeft niks 'geimplementeerd' aan firefoxurl .....

het instellen van 'firefoxurl' als geregisteerd protocol gebeurt bij het installeren van firefox2.0 in het windows Registry... de explorershell is zo ingesteld dat het URI's die gebruik maken van een bepaalde geregistreerde URI doorgeven aan de betreffende applcatie volgens de rules die daarvoor in de Registry staan en welke door de registrerende applicatie ingevoegd zijn ...

in het geval van firefoxurl: is het Firefox welke die registry-entry schreef:
[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\command\@]
C:\\PROGRA~1\\MOZILL~2\\FIREFOX.EXE -url “%1″ -requestPending

hierin zit de bug dat je een url mee kan geven met dubbele aanhalingstekens, waarna je de -chrome-flag oproept om lokaal bv javasscripts uit te laten voeren

Door DJohn001, woensdag 11 juli 2007 22:49

Score: 1
Ik heb hier onder ook al ergens aangegeven dat er bij mijn niets gebeurde toen ik een paar tests had uitgevoerd. Nu las ik dit over die registery sleutel die door firefox toegevoeg word bij de installatie deze is ook bij mij toegevoegd. Maar voor de zekerheid heb ik het nog maar eens geprobeerd en ben naar de pagina gegaan waar het lek omschreven word http://www.xs-sniper.com/sniperscope/IE-Pwns-Firefox.html en heb de link geprobeerd te openen in IE 6 die zei dat hij de pagina niet kon openen en bij FF kreeg ik een venster zoals deze http://xs217.xs.to/xs217/07283/firefoxurl.jpg dus ik zie het probleem niet en zelfs als ik alles accepteer krijg word CMD.EXE nog niet uitgevoert.

Edit

ik gebruik FF2.0.0.4

[Reactie gewijzigd door DJohn001]

Door meneer r, donderdag 12 juli 2007 00:23

Score: 1
Hier hoort er dus een string ge-escaped te worden!

Door meneer r, donderdag 12 juli 2007 00:24

Score: 0
Ja, microsoft dient alleen netjes de url als een ge-escaped string door te geven. Helaas doen ze dat niet.

In principe is het bloedlink wat ze doen. Firefox zal niet de enige zijn die hier door compromized is.

Door bazkar, donderdag 12 juli 2007 08:32

Score: 0
Nogmaals, dit is NIET het probleem van IE. IE is slordig, granted, maar het is een probleem van FF die zijn input behoord te controleren. Als ik een stuk software schrijf die dezelfde functionaliteit bied als IE (het doorpasen van een URL met firefoxurl protocol) dan blijft het probleem bestaan.

Het is algemeen good practise in de programmeerwereld om in principe alle soorten input te accepteren en hier zelf de foutafhandeling en validatie voor te doen in een algoritme. Je kunt nu eenmaal niet vertrouwen op het feit dat andere algoritmes of user-input altijd voldoet aan je verwachtingen.

Door sse2, woensdag 11 juli 2007 16:22

Score: 1
Omdat firefox het niet kan controleren, omdat de URL wordt omgezet in een commandline aanvraag, waarmee firefox kan worden aangeroepen met een -chrome optie, waarmee javascript kan worden uitgevoerd.

Door .oisyn, woensdag 11 juli 2007 16:38

Score: 1
Firefox kan het wél controleren - ze kiezen namelijk zélf de manier hoe het wordt doorgegeven. Dat kan via de commandline, waardoor ze met bijv. afscheidingstekens kunnen zorgen dat er niet ineens andere parameters via de URI binnen kunnen komen. Maar ze kunnen er ook voor kiezen om het niet via de commandline, maar via een shell object te laten gaan, zodat je precies weet wat de doorgegeven URI is.

Door meneer r, donderdag 12 juli 2007 00:23

Score: 0
Ook via de commandline zou er gewoon ge-escaped moeten worden!

Door Webgnome, woensdag 11 juli 2007 18:33

Score: 1
Als firefox kan omgaan met commandline aanvragen kan het deze aanvragen ook checken.

Door BramT, woensdag 11 juli 2007 22:55

Score: 1
Checken waarop? De commandline die firefox binnen krijgt is volstrekt legaal (volgens hun parameters). Dit is een o-zo bekende bug die in meerdere talen (mysql injection anyone?) terugkomt. Je parameters afbakenen met (dubbele) quotes werkt niet als je je invoer niet controleert. En de controle kan hier NIET door firefox gedaan worden. Ze kunnen het slechts zo maken dat je via commandline bepaalde (veiligheidsgevoelige) commando's niet meer mag gebruiken, of geen quotes meer in de url-handler maar andere manieren om dit veilig door te geven te implementeren.

Hoewel het natuurlijk niet erg handig is dat je kwaadwillende code's kan uitvoeren met een simpele commandline (commandline attacks worden zooo vaak gebruik), leg ik de fout toch ook bij microsoft. En dan niet bij de IE-tak, maar bij de manier waarop deze shell-commando's doorgegeven worden. Het lijkt me een ernstig kleine moeite om: indien een %x (parameter) tussen (dubbele) quotes staat, moeten evt (dubbele) quotes IN die parameter ge-escaped worden. Da's (gvd) 1 regel code!

Door meneer r, donderdag 12 juli 2007 00:21

Score: 0
Eindelijk iemand die daarwerkelijk door heeft wat er aan de hand is.

Door meneer r, donderdag 12 juli 2007 00:22

Score: 0
Nee! Het is volstrekt legaal. Ik moet in staat zijn firefox via de command-line een willekeurige chome uit te voeren.

Wat niet zou moeten gebeuren is dat microsoft via een url protocol TOESTAAT dat je een chrome-parameter kan doorgeven. Microsoft dient de quotation tekens in de url te escapen.

Door meneer r, donderdag 12 juli 2007 00:28

Score: 0
Firefox controleert de link niet. Firefox geeft de link alleen CORRECT door, ge-escaped en al! Microsoft doet dat niet. En laat dus (tegen alle bedoelingen in) toe dat je alle programma's die via URL-handlers openen elk willekeurige command-line optie mee kunt geven. Dat was nooit de bedoeling.

MS vergeet te escaped. Firefox niet. Er wordt niks gecontroleerd. Er wordt ge-escaped. Zoals het hoort volgens de specificatie van MS zelf.

Door Kjoe_Ljan, woensdag 11 juli 2007 16:05

Score: 0
Zo begrijp ik het ook. Uiteraard zou FF net zo goed moeten controleren op URLs/sites die worden doorgestuurd door een andere applicatie, maar ik vind het ook erg slordig van IE dat ze niet eerst de URL verifieren.

Door MagicPatrick, woensdag 11 juli 2007 16:16

Score: 1
Volgens mij is dat inherent aan het systeem. Als Firefox een protocol handler installeert, en IE (Windows) reageert daarop, dan lijkt het me niet meer dan logisch dat IE er niets aan controleert, aangezien het ook niet zijn protocol is.

Hetzelfde zie je btw gebeuren met mms:// en skype://

Door meneer r, donderdag 12 juli 2007 00:20

Score: 1
Ook voor mss:// en skype:// geldt dat de strings ge-escaped dienen te worden en als 1 geheel argument dienen worden meegegeven.

De bug zit in IE.

Vergis je niet. Het is niets firefox specifiek. Het is IE, die tegen zijn eigen specificaties in, strings niet escaped, waardoor je willekeurige argumenten kunnen toevoegen.

Door .oisyn, woensdag 11 juli 2007 16:16

Score: 1
IE hoeft de URI ook niet te verifieren want hij kan nooit weten wat voor een applicatie schadelijk is en wat niet. Hij kan hoogstens controleren of een URI aan de regels voldoet, maar als dat gedrag nu ineens verandert wordt betekent dat dat er mogelijk allerlei andere applicaties die rekenen op wat meer vrijheid bij URIs niet meer fatsoenlijk werken.

En in principe is het ook helemaal geen probleem - als app moet je gewoon sowieso altijd je input controleren, en als je dat niet doet dan is het je eigen schuld als het fout gaat.

[Reactie gewijzigd door .oisyn]

Door meneer r, donderdag 12 juli 2007 00:18

Score: 1
Verdiep je er nou eens in. Miscrosoft dient dit te doen:

firefoxurl://ditiseen+"url

En dan moet er zoiets gebeuren:

firefox.exe -url "ditiseen \"url"

Zie je dat de strings escaped zijn?
Dit is wat MS doet:

firefox.exe -url "ditiseen" url

Tada. Microsoft staat toe dat je willekeurige argumenten aan firefox.exe meegeeft, terwijl de url protocol dat gedrag niet suggereert. Het is een security bug in IE.

Niet alleen firefox, maar ook andere applicaties die URL protocols registeren kunnen hier problemen mee krijgen!

Door bazkar, donderdag 12 juli 2007 08:39

Score: 2
Met je laatste statement ben ik het eens. Het is slordig van UIE dat ze dit niet doen. Maar het is de verantwoordelijkheid van de maker van een protocol om te controleren of de input valide is.

Ik kan je laatste argument nl. ook makkelijk omdraaien: Niet alleen Internet Explorer, maar ook andere applicaties die het firefoxurl protocol doorgeven aan Firefox kunnen hier problemen mee krijgen.

Ik ben het met .oisyn eens dat je als maker van een algoritme te allen tijde je input dient te valideren.

Door .oisyn, donderdag 12 juli 2007 12:20

Score: 0
Verdiep je er zelf eens in.

Stel Firefox registreert z'n url handler als "firefox.exe %1" (ik heb geen firefox dus ik kan het niet controleren). Mozilla wéét dat er mogelijk spaties inzitten, zo werkt die functionaliteit nou eenmaal. Dus kunnen ze zichzelf beschermen door "firefox.exe -url %1" te doen, zoals jij al zegt, en vervolgens de rest van de commandline te interpreteren als url, en niet als extra command line parameters als er toevallig een spatie in staat.

Door humbug, woensdag 11 juli 2007 16:49

Score: 2
IE hoeft (in mijn ogen) de URI niet te controleren. Deze URI is een firefox eigen URI waarbij het gebruikte protocol door Firefox wordt gedefinieerd. Dit protocol (en dat van de x aantal andere) custom URIs kan veranderen. Je kan niet verwachten dat MS voor elk van die URIs complete parsers gaat maken (en bijhouden) terwijl het ontvangende programma (wat er alsnog niet vanuit kan gaan dat de zender het al gecontroleerd heeft) het toch nog een keertje moet doen. Controle door het zendende programma is dus zinloos en vragen om problemen

Vergeet niet dat we het niet enkel over browsers hebben ook bv soap en sip zijn geldige URIs. Nee, programma's moeten hun invoer parameters gewoon correct parsen en dat heeft firefox hier niet gedaan

Door meneer r, donderdag 12 juli 2007 00:14

Score: 1
Nee, ze hoeven het niet te controleren. Ze dienen het CORRECT door te geven. Dat doen ze niet.

De bedoeling is dat de parameter in de url als string wordt meegegeven. IE escaped die string niet zodat je nog andere parameters aan firefox kan meegeven. Dat is voor lokaal gebruik de bedoeling. Het is MS die zich niet aan het URL protocol houdt.

Door Emielvenlo, donderdag 12 juli 2007 09:37

Score: 0
Wat een zinloze bullshit discussie. Ze doen het gewoon samen verkeerd en moeten er iets aan doen. Wie zijn schuld het is, is totaal irrelevant en een zinloze discussie.

Door Niemand_Anders, woensdag 11 juli 2007 16:19

Score: 1
Les 1 bij development. Controleer ALTIJD alle externe input! Dit is inderdaad geen IE probleem. Firefox dient bij het uitvoeren van elk request (remote of lokaal) te controleren of de uri wel is toegestaan.

Maar zoals gewoon wijzen programmeurs altijd eerst naar een ander. Pas als er onweerlegbaar bewijs is, geven ze heel erg zachtjes hun fout toe. In mijn ontwikkel team heb ik daar een goede oplossing voor gevonden. Iemand die direct de verantwoordelijkheid afschuift en later toch de verantwoordelijke blijkt te zijn, wordt aan de virtuele schandpaal genagelt op het intranet voor twee weken.

Niemand zal boos worden omdat er iets fout gaat. Echter je verantwoordelijkheid uit de weg gaan zal door niemand worden getolereerd.

Dat andere applicaties dezelfde fout kunnen hebben, is nog geen excuus om het zelf niet op te lossen..

Door witte1985, donderdag 12 juli 2007 09:27

Score: 0
dat deze dan slordig omspringt is niet meer Internet Explorer zijn probleem anders kan deze browser wel overal rekening mee gaan houden (en daar is geen beginnen aan).
Dus microsoft devs moeten er geen rekening mee houden, maar mozilla dev's wel. Dat slaagt toch op niets...

Door jp, donderdag 12 juli 2007 13:52

Score: 0
Als het andersom zou zijn, zouden de mozila dev's er geen rekening mee moeten houden, maar de ms devver's wel.

Zoals al aangegeven: All external/user input is evil (tot je bewezen / gecontroleerd hebt dat t veilig is).

Door hugoy, woensdag 11 juli 2007 15:53

Score: 0
Daar zit ik dan, met IE en Firefox, die ik allebei gebruik, en voorlopig nog geen oplossing :| Firefox toch maar deïnstalleren omdat IE breder ondersteund wordt? Wel een goeie zet van Microsoft :|

EDIT: ik heb het zojuist zelf geprobeerd, maar ik krijg alleen maar errors dat het misschien een zwakte in het systeem kan benutten :) (heb overigens dus gewoon niet de mogelijkheid om iets in firefox te openen in IE) zou dit misschien te maken hebben met het feit dat ik IE 7 heb?

[Reactie gewijzigd door hugoy]

Door .oisyn, woensdag 11 juli 2007 15:59

Score: 0
Voorlopig?
Mozilla heeft ondertussen laten weten dat het in de eerstvolgende update van Firefox de url protocol handler zal aanpassen
Ik ben geen firefox gebruiker, maar zo lang zul je hier toch niet op hoeven wachten, of wel?

Door Terw_Dan, woensdag 11 juli 2007 16:48

Score: 0
FF krijgt regelmatig updates, dus wat dat betreft zul je idd niet lang hoeven te wachten.

Door erkje, woensdag 11 juli 2007 16:01

Score: 0
Ik heb eigenlijk nog nooit een link gezien die begint met firefoxurl://
Dus je moet expliciet zoiets aanklikken in internet explorer en dan moet het ook nog eens kwaadaardig zijn. Hoe groot is de kans dan? Voor dat kansje hoef je je hele systeem niet over de kop te gooien vind ik. laat FF lekker staan en zorg dat je'm binnenkort bijpatcht :)

Door barbedwire, woensdag 11 juli 2007 16:23

Score: 1
En als je de URI auotmatisch in een onzichtbare iframe wordt geladen?

Door Fiander, donderdag 12 juli 2007 21:57

Score: 0
Dan krijg ik keurig netjes een melding dat de pagina een virus probeert op te starten.

Door FlowDesign, woensdag 11 juli 2007 16:02

Score: 1
Firefox komt inderdaad met een vraagschermpje voordat het iets raars uitvoert. :Y

http://xs217.xs.to/xs217/07283/firefoxurl.jpg

Door lennartkocken, woensdag 11 juli 2007 16:37

Score: 0
En als je hebt ingesteld dat elke link naar een nieuw tabblad moet, krijg je oneindig veel meldingen ;)

Door MyUsername, woensdag 11 juli 2007 21:01

Score: 1
Zo te zien geeft Firefox niet die melding, maar IE. Dat zou betekenen dat IE er wél rekening mee heeft gehouden dat dit kon gebeuren. Meer dan zo'n foutmelding kunnen ze volgens mij redelijkerwijs niet doen. Alleen een beetje jammer dat firefox vast opgestard wordt voordat de gebruiker bevestigd heeft...

[Reactie gewijzigd door MyUsername]

Door vteuniss, woensdag 11 juli 2007 16:02

Score: 1
Ik heb het net ook geprobeerd, er wordt mij om toestemming gevraagd en dan opent IE een Firefox sessie die weer om toestemming vraagt voor een volgende firefox sessie enzovoorts, enzovoorts. Er wordt uiteindelijk geen enkele site geopend.
Ik heb inderdaad ook IE7 en FF2.

Door brobro, woensdag 11 juli 2007 18:20

Score: 0
't is toch alleen zo als je een link in IE opent die wordt doorgestuurd naar Firefox? Waarom zou je IE gebruiken als FF hebt geinstalleerd?

Door timonb, woensdag 11 juli 2007 19:36

Score: 0
waarom zou je FF2 gebruiken als je IE7.0 hebt geinstalleerd. Uberhaubt waarom zou je FF2 installeren?

Door EIo, donderdag 12 juli 2007 11:50

Score: 0
Omdat FF2 überveilig is }>

Door R-J_W, woensdag 11 juli 2007 19:51

Score: 1
Moet ik dit serieus nemen?
Nou ja, Dus ...
Omdat je nog altijd sites tegenkomt die alleen goed worden weergegeven in IE.
Dit is meestal geen probleem, maar wanneer je het wel nodig hebt, zoals bij mijn studie om de roosters te kunnen bekijken. Omdat FF de pagina gewoon weg niet kan openen of verwerken.

Zolang er sites worden gemaakt die gebaseerd zijn op IE specifieke technieken zul je deze erbij moeten hebben en moeten gebruiken.

Daarbij moet je niet vergeten dat er ook mensen zijn die liever hun vertrouwde IE gebruiken. Terwijl iemand anders FF op die computer heeft gezet.

[Reactie gewijzigd door R-J_W]

Door jj71, donderdag 12 juli 2007 08:44

Score: 0
zou dit misschien te maken hebben met het feit dat ik IE 7 heb?
Nee hoor, ik heb hier een PC met IE 6 en FF 2.0.0.4 en ik krijg ook een schermpje met de
melding dat er een externe toepassing moet worden gestart om "firefoxurl:" koppelingen te openen, en dat dit misschien gevaarlijk kan zijn.

De bewering dat IE het zomaar zonder controle opent lijkt dus niet helemaal waar te zijn.

Door Red-Front, woensdag 11 juli 2007 15:54

Score: 0
Maar geld dit ook voor hun beta (van FF dan) Gran Paradiso? Want die heb ik... |:(

[Reactie gewijzigd door Red-Front]

Door R-O-Y, woensdag 11 juli 2007 15:58

Score: 0
Geldt dat voor alle versies van internet explorer? Ik heb namelijk niks geinstalleerd maar ik krijg 'm er wel standaard bij ;)

Door Red-Front, woensdag 11 juli 2007 16:01

Score: 0
Staat niet in het verhaaltje.. maar het is een screenshot van IE 7.

Door dutchvamp, woensdag 11 juli 2007 16:50

Score: 1
Dit werkt ook onder IE6 net getest.

Firefox geeft inderdaad oneindig veel nieuwe tabs/vensters

dit is een bug in FF en niet in IE

Door Smithers.83, woensdag 11 juli 2007 16:01

Score: 0
Reactie van Mozilla: http://blog.mozilla.com/s...ocol-handling-on-windows/

Een patch zal dus hoogstwaarschijnlijk in Fx 2.0.0.5 zitten, waarvan de release rond 31 juli wordt verwacht.

Nou nog maar wachten op IE...

[Reactie gewijzigd door Smithers.83]

Door Firefox, woensdag 11 juli 2007 16:20

Score: 2
Eig'k nie. Als IE checks gaat loslaten op dergelijke URI's wordt de functionaliteit van sommige tools waarschijnlijk gesloopt. Den aan bijvoorbeeld links om games automatisch te launchen met een auto connect naar de juiste server met de juiste game MOD (Halflife Counterstrike om maar iets te noemen)

Het is en blijft zaak van de applicatie die hiervoor gestart wordt om de boel goed af te handelen. Vanuit IE is het eigenlijk niets meer dan een documented feature waar andere apps gebruik van kunnen maken. Het alternatief is volgens mij gewoon te voorkomen op dergelijke protocollen te reageren, en dat komt de integratie weer niet ten goede..

(pff, is het een keer geregeld qua samenwerking, krijg je weer commentaar op het feit dat je er misschien meer mee kan ;))

Door R-J_W, woensdag 11 juli 2007 20:06

Score: 0
Ik vraag me af waarom Internet Explorer hierbij genoemd wordt.
Want er zijn ook andere browsers die naast FF gebruikt kunnen worden.
En het lijkt me dat andere browsers dit soort links ook kunnen verwerken.
Is het nu zo dat FF dan de inkomende verzoeken wel controleerd, of controleren die browsers de uri's wel.

Wanneer dat zo is is IE wel degelijk medeschuldig, doordat ze een beveiliging die andere software wel levert niet toepassen.
Omdat IE zo specifiek genoemd wordt en de ontdekker gelinkt wordt met de ontdekking van beveiligingslekken in andere browsers, krijg ik de indruk dat dit probleem alleen met IE op treed.

Dus de mogelijke oorzaken:
1 IE is de enige browsers die dit soort URI's niet controleerd en Firefox controleerd geen op deze manier binnenkomende uri's
2 De Firefox developers hebben erg veel vertrouwen in IE en controleren hiervan binnenkomende verzoeken niet, maar andere wel.

Feit blijft dat FF een grove fout heeft gemaakt door deze input niet te controleren.

Door XIU, woensdag 11 juli 2007 17:56

Score: 0
En IE moet ook alle ftp:// urls checken of ze niet naar verkeerde servers linken voor deze doorgegeven worden aan een externe applicatie, en natuurlijk ook skype:// links etc

Door roy-t, woensdag 11 juli 2007 23:33

Score: 1
Hier geeft mozilla aan dat het hun eigen fout is, dus waarom wachten op IE? :)\

Mijns inziens doet IE precies wat het moet doen, namelijk het door Mozilla in IE geinstalleerde stukje software uitvoeren op het moment dat het een firefoxurl krijgt. :)

Door Phyxion, woensdag 11 juli 2007 16:12

Score: 0
Wat ik net zelf uitvond en nog veel leuker is:
Start->Run
iexplore firefoxurl://tweakers.net

Dan krijg je iedere seconde een paar nieuwe firefoxvensters open :)

Let wel: firefoxurl://www.tweakers.net werkt niet, het moet echt firefoxurl://tweakers.net zijn.

Op twee PC's getest, beide hebben dit probleem :)


@DJohn001,

Misschien dat het IE7 is, beide PC's zijn hier met IE7.

[Reactie gewijzigd door Phyxion]

Door DJohn001, woensdag 11 juli 2007 19:26

Score: 0
Ik heb het net ook even geprobeerd, maar bij mij werkt niets. Als ik een url via IE 6 uitvoer bijv. firefoxurl://tweakers.net of via de prompt: iexlpore firefoxurl://tweakers.net bijde doen het niet en er word geen melding gegeven, alleen zeg IE dat hij de pagina niet kan vinden maar voor de rest gebeurt er niets er word geen FF tabbald geopend of zo, ik zie geen ekele actie. Als ik de link in FF uitvoer krijg ik wel een melding dat er een extern protocol gebruik gaat worden net zo als dat het geval bij bijv. het mms protocol om een windows media player bestand af te spelen. Ik zie hier het probleem niet van en gebruik bovendien bij hoge uitzondering IE.

Door pinockio, woensdag 11 juli 2007 22:17

Score: 0
Ik krijg gewoon van FF de vraag of ik deze link verwacht met de melding dat als dat niet zo is, een extern programma misbruikt wordt (kortweg). Dit op Windows XP met IE 6. Blijkbaar is IE6 icm FF2 niet vatbaar. Toch goed dat ik nog IE6 draai!

[Reactie gewijzigd door pinockio]

Door Proxy, woensdag 11 juli 2007 23:51

Score: 0
Mijn firewall geeft als mededeling dat Firefox wil worden gestart via Internet Explorer en of ik dat wil toestaan. :/

Door psyBSD, woensdag 11 juli 2007 16:26

Score: 0
Open Source, dit is geen MS lek.

(Ongelofelijk dat ik mijzelf dit zie zeggen hier...)

Door i-chat, woensdag 11 juli 2007 16:37

Score: 0
dit is helemaal geen dubbel lek, dit is gewoon een designe fout van firefox, en zoals je hierboven kunt lezen, rond 31 julie zal er een patch komen...

Door vierkant228, woensdag 11 juli 2007 16:15

Score: 0
Persoonlijk (gelukkig noob met mening :P) vindt ik dat dit idd probleem van Firefox is, daarintegen vindt ik dit een goede reden om te zeggen IE moet volledig verwijderd kunnen worden.
tot die tijd toch ook microsoft zijn probleem, een ieder die een alternatief van IE gebruikt is de pisang......

Helaas door tijdgebrek en daardoor niet snappen van Linux vast aan de monopolie (zoals zovelen)... mooiste was als er Linux avonden in de burt gehouden werden (tegen zeer lage kosten) om alleen maar de basics te kunnen (programma installeren, deinstaleren etc... en kom niet je bent tweaker want het probleem is gemak en tijdgebrek zoals bijna iedereendie geen tweaker is)

Door psyBSD, woensdag 11 juli 2007 16:30

Score: 0
http://www.nllgg.nl/install_parties

Er staat er helaas momenteel nog geen geplanned, maar misschien is dat iets voor jou?

Door XIU, woensdag 11 juli 2007 17:59

Score: 1
Het probleem is dat FIREFOX een uri handler installeert, IE geeft gewoon alle onbekende door aan het juiste programma...

Vul maar eens gewoon "firefoxurl://blabla" in het Uitvoeren prompt...

Door SuperDre, woensdag 11 juli 2007 18:58

Score: 0
Uhm.. probleem is als je IE volledig verwijderd dat ineens een boel programma's niet meer zullen werken omdat die er van uit gaan dat IE op de PC geinstalleerd is, want dat is toch waarom men met DLL's wil werken, zodat je niet telkens het wiel opnieuw hoeft uit te vinden...

Door Extortioner, woensdag 11 juli 2007 16:17

Score: 0
Als ik dit doe via IE dan vraagt FF mij verschillende keren of ik dit wel wil toelaten. Dus niet zo zeer een lek zou ik dan zeggen?

Misschien is er meer aan de hand dan gewoon een slechte URL, maar toch zie ik er geen schuld van aan bij FF, al ben ik blij dat ze de beveiliging toch gaan bijschroeven.

Door sse2, woensdag 11 juli 2007 16:19

Score: 0
Ik weet niet wat voor bijwerkingen het heeft, maar voorlopig kun je beter de protocol handler deregistreren door de key weg te halen.
Zie: http://msdn2.microsoft.com/en-us/library/aa767914.aspx

*Zucht* : Voor de mensen die beweren dat firefox maar alle input moet controleren: dit kan niet, omdat de URI wordt omgezet naar een commandline aanvraag, waarmee firefox wordt opgestart. Firefox denkt dus dat het opgestart is door een gebruiker via de command line. Zie link hierboven voor hoe Windows protocol handlers afhandelt.

[Reactie gewijzigd door sse2]

Door mashell, woensdag 11 juli 2007 16:40

Score: 0
Firefox denkt dus dat het opgestart is door een gebruiker via de command line.
En sinds wanneer is dat een goede reden of geen controles uit te voren?

Door .oisyn, woensdag 11 juli 2007 16:47

Score: 2
*Zucht*: voor jou nog een keer dan: commandline optie is niet de enige manier om je protocol handler te installeren, en bovendien is het dan nog steeds te controleren. Waar het om gaat is dat je andere commandline opties voor Firefox via de URI op kunt geven. Dat is toch echt een fout van firefox omdat ze niet goed controleren of dat gedeelte bij de URI hoort of niet. Door bijvoorbeeld scheidingstekens te gebruiken of een firefox URI alleen als laatste argument op de commandline toe te laten, kun je dit voorkomen.

Maar wat ook kan, is gewoon een shell object registreren wat de URI afhandelt, zodat er gewoon een functie wordt aangeroepen met de betreffende URI als parameter.

[Reactie gewijzigd door .oisyn]

Door sse2, woensdag 11 juli 2007 18:26

Score: 0
Het eerste gedeelte van je verhaal kan ik niet echt volgen(volgens mij ken ik maar een soort commandline opties, ik snap niet precies wat je bedoelt), maar volgens mij kun je best gelijk hebben dat het de fout van firefox is. Want de firefoxurl: gedeelte wordt als argument meeverstuurd. Dus firefox zou alle 'gevaarlijke' commandline opties kunnen negeren als het firefoxurl: ziet als protocol in zijn argument.

Door Webgnome, woensdag 11 juli 2007 18:37

Score: 0
Zoals ik al eerder heb gereageerd :

Als firefox een commandline optie kan interpreteren kan firefox deze ook zeer zeker verifiëren..

Door sse2, woensdag 11 juli 2007 18:58

Score: 0
Verifiëren tegen wat? In dit geval heb je toch gelijk aangezien firefoxurl:huppeldepup wordt meeverstuurd(wat ik eerst niet had gedacht), maar zonder de firefoxurl: erbij zou firefox geen onderscheid kunnen maken tussen gebruiker die via cmd.exe typt of IE die firefox via een protocol handler aanroept. Dus ja je kan idd cmd argumenten interpreteren, maar dat je ze ook meteen kan verifiëren is een beetje onzin tenzij je bepaalde criteria meegeleverd krijgt om de verificatie te doorstaan(en die kun je niet altijd uit de commandline argumenten halen).

Door roy-t, woensdag 11 juli 2007 23:39

Score: 1
:) maar firefox ziet wel wat het volgens de commandline moet doen, bijvooorbeeld

ga naar www.eenleukewebsite.nl

maar het kan ook zien dat er staat, Format C:

Ik denk dat het niet uit maakt of een programma weet of het zo door een gebruiker wordt uitgevoerd of niet, Firefox moet gewoon alleen internetsites e.d. afhandelen via de commandline en geen programmas kunnen runnen, (en al helemaal geen Format C: )


Door BastiaanN, donderdag 12 juli 2007 13:06

Score: 0
Niet dat Format C: werkt op een standaard windows installatie, waarbij windows op die C: schijf staat, dan krijg je altijd nog een foutmelding dat het station ingebruik is en dat het niet geformateerd kan worden :+

C:\Users\Bastiaan>format c:
Het type bestandssysteem is NTFS.
Voer de huidige volumenaam in voor station C: Vista

WAARSCHUWING:
ALLE GEGEVENS OP HET NIET-VERWISSELBARE
STATION C: ZULLEN WORDEN VERWIJDERD!

De systeempartitie mag niet worden geformatteerd.
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:14
Vorige 15:08
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: