Meer applicaties gevoelig voor uri-lek

maar als de applicaties het op deze manier aanroepen is er niets aan het handje en kunnen ze de input perfect controleren door alles wat achter uri komt als uri te parsen:

"app.exe -uri %1"

Kortom, dat IE dat systeem van handlers registreren überhaupt aanbied is onveilig.

Ik geloof dat niemand beweert dat het veilig is. Maar het bestaat nu eenmaal and we just have to make do. IE nu aanpassen is, zoals ik al zei, geen optie. En het is by design - dat design kun je in twijfel trekken, maar daar ben je dan a) te laat mee, en b) is het irrelevant voor deze discussie. Het is iig geen bug, punt.

Het IE-systeem werkt alleen als de applicatie een specifiek .exe-bestand maakt dat alléén URLs als input accepteerd, en verder niks.

Onzin, verdiep je eens in de materie. Ik heb in mijn vorige post 2 alternatieven voorgesteld, het zou je sieren als je gewoon goed leest de volgende keer.

1) parse na de URI geen verdere command line opties. Alles wat na de URI op de command-line staat, hoort bij die URI. Als je app rekent op oude aanroepen, waarbij er na een (valide) URI nog parameters komen, dan kun je dat fixen door een extra command-line optie toe te voegen dat de doorgegeven URI mogelijk onveilig is: "app.exe -unsafe_uri %1". Bij een aanroept als "app.exe -unsafe_uri myprotocol://aap -noot -mies" wordt de URI geinterpreteerd als "myprotocol://aap -noot -mies". Problem solved.

2) maak geen gebruik van de relatief domme command line interface, maar doe het via een regegistreerd shell object. In plaats dat er een app wordt opgestart met command line parameters, wordt er een door jouw geimplementeerd COM object geinstantieerd, waaraan de URI middels een string parameter wordt doorgegeven. Uiteraard ga je in deze string verder geen command line arguments zitten parsen, want dat slaat nergens op - het is immers een URI. Problem solved.

Als IE zijn input echter zou URL-encoden, dan was er geen vuiltje aan de lucht geweest, aangezien URLs geen spaties en aanhalingtekens kunnen bevatten, deze worden ge-escaped.

URIs mogen sowieso geen spaties of quotes bevatten. IE wijkt daar by design vanaf. Dus pas het design aan, of laat het zoals het is, maar kom niet met halfgare oplossingen door maar eens opnieuw te gaan URL-encoden. Want dan worden tekens die al geurl-encode zijn, nogmaals geurl-encode

Maar dat doet IE dus niet, en blijkbaar hebben Firefox en Trillian dus incorrect aangenomen dat dat wel zo is.

Exact, dus daar ligt op dit moment de fout

Desalniettemin is het IE hier die op deze manier onveilig gedrag ten toon stelt.

Niemand beweert anders.

[Reactie gewijzigd door .oisyn op woensdag 18 juli 2007 16:16]

Volgens die RFC mag je tekens in een reeds bestaande URI helemaal niet encoden. Ofwel URI's horen altijd al goed ge-encode zijn. De meeste web url's zijn dat echter niet. daarom laten alle browsers ook nog correcte URI's toe. Het is dus echter volgens de RFC correct om deze onveranderd te laten. Het escapen van tekens in een bestaande URI kan namelijk de semantisch waarde van een URI aantasten.
(Of je unescaped web URI's zou moeten doorgeven is een andere vraag maar daar werken talloze web protocollen nu al mee)

en waarop zou jij dat wille controleren dan, denk je nu echt dat een IE DEV inzicht in wat de trilian gasten als wenselijke data beschouwen, - ja dat kun je krijgen ja, misschien moete alle IE dev lid worden van minstend 100 mailing lists per persoon om te weten welke URI er allemaal op de wereld bestaan en welke data die wel en niet wille hebben...

Dat is simpel, gewoon op standaard regels van een URI, want dan kan er niet veel mee misgaan. Jiriki bedoelt er waarschijnlijk dan ook mee dat je controleert of het om 'valide' data gaat en niet om nuttig te gebruiken data.

Je hebt helemaal gelijk. Ik ging te kort door de bocht en ik ben blij dat je het even hebt uitgelegd.

Wellicht hebben developers van firefox en trillian hier geen rekening mee gehouden, en dat was nou net het punt wat jij noemde.