Probleem met invoegen afbeelding

[Rygir]

Ik heb een probleem hier op het forum... als ik deze afbeelding invoeg als afbeelding verschijnt er bij mij niets. Als je de link volgt werkt hij prima en mijn test pagina ook.

Dus zo :

[RobIII]

Vette kans dat het in de "gekke tekens" in de url zit zoals ssd's. Ik verwacht dat de camo proxy daar niet tegen kan / niet goed mee omgaat.

Edit:


Jep; ' vervangen door %27 (url-encoded dus) werkt wel.
Ik move dit topic dan ook even van Lieve Adjes naar Stoute Bugs (voor zover het een bug zou zijn).

offtopic:
Het is sowieso nooit echt een goed idee om spaties, quotes, haken en andere 'gekke tekens' in een bestandsnaam die over HTTP(S) geserveerd moet worden te gebruiken; beperk je tot a-z/A-Z, 0-9, - en _ (i.p.v. spaties) bijvoorbeeld en een enkele punt om een evt. bestandsextensie aan te geven. Of zorg dat je de bestandsnaam (of directory of...) juist encode.

Dus:
Samsung 850 PRO SSD problemen/Installeren SSD's_files/mht30F1(1).png
wordt:
Samsung%20850%20PRO%20SSD%20problemen%2FInstalleren%20SSD%27s_files%2Fmht30F1(1).png
of, nog liever, iets als:
Samsung-850-PRO-SSD-problemen/Installeren-SSDs_files/mht30F1.png

[ Voor 194% gewijzigd door RobIII op 30-06-2016 03:42 ]

[Rygir]

Bedankt!
(en ja ik weet het maar het moest snel snel, het is niet levensbelangrijk dat het op elk platform tot in de eeuwigheid ondersteund is)

[Hero of Time]

Rygir schreef op donderdag 30 juni 2016 @ 03:45:
Bedankt!
(en ja ik weet het maar het moest snel snel, het is niet levensbelangrijk dat het op elk platform tot in de eeuwigheid ondersteund is)

Je zet het online. Dan houd je je toch aan de internetstandaarden voor bestandsnamen? Dat is dan zo min mogelijk gebruik maken van vreemde tekens. En spaties vallen daar onder.

[Compizfox]

Hero of Time schreef op donderdag 30 juni 2016 @ 09:01:
[...]

Je zet het online. Dan houd je je toch aan de internetstandaarden voor bestandsnamen? Dat is dan zo min mogelijk gebruik maken van vreemde tekens. En spaties vallen daar onder.

Volgens de standaard voor URLs (RFC1738) mogen die 'gekke tekens' (zo gek vind ik ze niet, maar goed) gewoon hoor.

Een apostrof is niet eens een reserved character (zoals een ampersand of een slash, bijvoorbeeld) dus het is niet nodig om die te escapen.

Makkelijker leesbaar artikel: https://perishablepress.c...nsafe-characters-in-urls/

Lijkt me dus een bug in jullie proxy.

[Hero of Time]

Compizfox schreef op donderdag 30 juni 2016 @ 12:48:
[...]

Volgens de standaard voor URLs (RFC1738) mogen die 'gekke tekens' (zo gek vind ik ze niet, maar goed) gewoon hoor.

Een apostrof is niet eens een reserved character (zoals een ampersand of een slash, bijvoorbeeld) dus het is niet nodig om die te escapen.

Makkelijker leesbaar artikel: https://perishablepress.c...nsafe-characters-in-urls/

Lijkt me dus een bug in jullie proxy.

Ik zeg ook 'zo min mogelijk'. Tuurlijk kan je ze gebruiken.

Dat het mis gaat met een apostrof (single quote) is zeer waarschijnlijk een bug. Veel code gebruikt quotes (single en/of dubbel) om strings mee weer te geven. Dat niet fatsoenlijk afvangen levert dus spontane problemen op, omdat de variabele of wat dan ook niet volledig is.

[Compizfox]

Hero of Time schreef op donderdag 30 juni 2016 @ 12:58:
[...]

Ik zeg ook 'zo min mogelijk'. Tuurlijk kan je ze gebruiken.

Ja, maar de standaard zegt helemaal niet dat je ze "zo min mogelijk" moet gebruiken. Een apostrof is volgens de standaard gewoon toegestaan en zou je dus zo vaak mogen gebruiken als je wilt.

[...]
Dat het mis gaat met een apostrof (single quote) is zeer waarschijnlijk een bug. Veel code gebruikt quotes (single en/of dubbel) om strings mee weer te geven. Dat niet fatsoenlijk afvangen levert dus spontane problemen op, omdat de variabele of wat dan ook niet volledig is.

Als dat het daadwerkelijk is dan wordt het erg interessant, want dan heb je in principe een code injection vulnerability

[ Voor 38% gewijzigd door Compizfox op 30-06-2016 13:09 ]

[RobIII]

Compizfox schreef op donderdag 30 juni 2016 @ 13:00:
[...]

Ja, maar de standaard zegt helemaal niet dat je ze "zo min mogelijk" moet gebruiken. Een apostrof is volgens de standaard gewoon toegestaan en zou je dus zo vaak mogen gebruiken als je wilt.

Theorie en praktijk. Standaard en Praktijk.
Standaarden zeggen zoveel; wil niet zeggen dat ze (altijd) even strak/goed geïmplementeerd worden. Ja, de standaard zegt dat.... maar de praktijk wijst uit dat er altijd wel een-of-ander systeem is dat van bepaalde zaken over z'n nek gaat (dat blijkt nu (dus) ook wel weer). Niemand zegt dat je 't niet mag gebruiken, maar wil je problemen voorkomen (of: wil je 'zo compatible mogelijk' zijn) dan beperk je je tot bovenstaande.
Idem als je bestanden op CD/DVD gaat zetten enzo; daar zijn ook bepaalde tekens niet toegestaan (of, wederom, slecht of in verschillend mate (103, 110, ...) ondersteund). En zo mag je ook prima een bestand met een punt beginnen (zelfs gebruikelijk in Linux), maar het geeft (ook) problemen op andere systemen. Wat dat betreft was "8.3" (ofwel "DOS bestandsnamen") helemaal zo gek nog niet. Een compleet pad mag ook langer zijn dan 260 tekens volgens NTFS, maar dat betekent niet dat alle programmatuur daar vlekkeloos (of zelfs überhaupt) mee overweg kan. URLS ditto; "de standaard" zegt dat ze (in principe) "unbounded" zijn (onbeperkt lang); de praktijk is een ander verhaal.

Compizfox schreef op donderdag 30 juni 2016 @ 13:00:
Als dat het daadwerkelijk is dan wordt het erg interessant, want dan heb je in principe een code injection vulnerability

Dat (in dit geval) een single quote niet goed afgehandeld wordt wil niet meteen zeggen dat code injection mogelijk is; misschien is 't enige probleem dat de camo het juiste bestand niet remote ophaalt (of juist onder de verkeerde key cached of...), dat betekent niet meteen dat je (al dan niet arbitraire) code kunt injecteren.

[ Voor 17% gewijzigd door RobIII op 30-06-2016 13:25 ]

[Compizfox]

RobIII schreef op donderdag 30 juni 2016 @ 13:17:
[...]

Theorie en praktijk. Standaard en Praktijk.
Standaarden zeggen zoveel; wil niet zeggen dat ze (altijd) even strak/goed geïmplementeerd worden. Ja, de standaard zegt dat.... maar de praktijk wijst uit dat er altijd wel een-of-ander systeem is dat van bepaalde zaken over z'n nek gaat (dat blijkt nu (dus) ook wel weer). Niemand zegt dat je 't niet mag gebruiken, maar wil je problemen voorkomen (of: wil je 'zo compatible mogelijk' zijn) dan beperk je je tot bovenstaande.

Zal best, maar dat betekent nog wel dat dit een bug in jullie proxy is. Die houdt zich immers niet aan de standaard.

En zoals je eenvoudig kunt zien is dit niet een geval wat in veel software niet werkt, want browsers kunnen er gewoon mee omgaan.

[...]
Dat (in dit geval) een single quote niet goed afgehandeld wordt wil niet meteen zeggen dat code injection mogelijk is; misschien is 't enige probleem dat de camo het juiste bestand niet remote ophaalt (of juist onder de verkeerde key cached of...), dat betekent niet meteen dat je (al dan niet arbitraire) code kunt injecteren.

Ik ging even af op het geval dat Hero of Time schetste, waarbij de URL in een string gedumpt wordt op zo'n manier dat een apostrof in die string de string vroegtijdig kan afsluiten. Daarmee heb je wel een code injection, lijkt me.

[RobIII]

Compizfox schreef op donderdag 30 juni 2016 @ 13:31:
[...]

Zal best, maar dat betekent nog wel dat dit een bug in jullie proxy is. Die houdt zich immers niet aan de standaard.

Zal best, maar dat is dus die praktijk waar ik 't over heb. Of het gefixed wordt (door "ons" of "hunnie") is een tweede.

Compizfox schreef op donderdag 30 juni 2016 @ 13:31:
want browsers kunnen er gewoon mee omgaan.

Die conclusie trek je ook wat makkelijk; ja de huidige, gangbare, browsers (die jij (en ik en...) nu even hebben getest) misschien wel. Maar wie zegt dat, zeg, IE1.0 of Mosaic of weet-ik-veel daar (ook) goed mee overweg kan? Je scheert 't een beetje over één kam zeg maar

Maar goed de hele discussie is gewoon moot. Er is gedemonstreerd dat 't in de praktijk gewoon niet handig is om "gekke tekens" in URL's te zetten (en dan heb ik 't nog niet eens gehad over & en ? die sowieso een speciale betekenis hebben) en al wat er gesuggereerd werd is: dat kun je voor zijn door gewoon dergelijke tekens te vermijden. Als je ze wil gebruiken moet je dat vooral doen maar kijk dan niet raar als 't eens een keer ergens mis gaat. En ja, er zit dus een bug (ergens rond?) de camo proxy klaarblijkelijk, en ja, in een ideale wereld wordt die (snel) opgelost. Hence de move naar SB. Praktijk is echter een tweede; misschien wordt 't pas over een jaar opgelost of misschien wel helemaal niet (door wie dan ook). Dat is een kwestie van prioriteiten, kosten/baten enz. en daar heb jij (noch ik) kijk op. Iemand van de devvers zal daar zinniger(e) uitspraken over (kunnen) doen dan ik.

Compizfox schreef op donderdag 30 juni 2016 @ 13:31:
Ik ging even af op het geval dat Hero of Time schetste, waarbij de URL in een string gedumpt wordt op zo'n manier dat een apostrof in die string de string vroegtijdig kan afsluiten. Daarmee heb je wel een code injection, lijkt me.

Ook niet. Een "string wordt vroegtijdig afgebroken" (whatever that may be). Dus? Dat betekent niet meteen => DUS code injection. Het betekent misschien wel hooguit dat je alles na die quote mist. Of het te ge/misbruiken is daar niet uit te concluderen.

[ Voor 42% gewijzigd door RobIII op 30-06-2016 13:53 ]

[Hero of Time]

Compizfox schreef op donderdag 30 juni 2016 @ 13:00:
[...]

Ja, maar de standaard zegt helemaal niet dat je ze "zo min mogelijk" moet gebruiken. Een apostrof is volgens de standaard gewoon toegestaan en zou je dus zo vaak mogen gebruiken als je wilt.

Net zo goed dat een spatie aan het einde van een bestandsnaam mogelijk is. Linux en OSX doen daar niet moeilijk over. Krijg je zo'n bestand op een Windows systeem echter, dan krijg je doodleuk meldingen van 'permission denied' of 'file not found' oid. Want tja, de standaard verbied het niet. Betekend niet dat je het ook maar moet doen.

[...]

Als dat het daadwerkelijk is dan wordt het erg interessant, want dan heb je in principe een code injection vulnerability

Je bent een Linux gebruiker. Hoe kan het dan dat je zo simpel denkt, terwijl je perfect weet wat het gedrag kan zijn bij variabelen die onbedoeld korter zijn dan verwacht?

[Compizfox]

RobIII schreef op donderdag 30 juni 2016 @ 13:45:
[...]
Die conclusie trek je ook wat makkelijk; ja de huidige, gangbare, browsers (die jij (en ik en...) nu even hebben getest) misschien wel. Maar wie zegt dat, zeg, IE1.0 of Mosaic of weet-ik-veel daar (ook) goed mee overweg kan? Je scheert 't een beetje over één kam zeg maar

Ik ben uiteraard niet in staat om het te testen, maar het zou me verbazen als die browsers daar problemen mee hebben. Zoals ik al zei, is een apostrof helemaal geen raar teken, en mag het gewoon in een URL voorkomen. We hebben het hier over een doodnormaal ASCII-teken, niet specialer dan een - of een _ (waar je, hoop ik, toch ook geen problemen mee hebt?), niet over rare Unicode-karakters of Emoji of zo...

[...]
Ook niet. Een "string wordt vroegtijdig afgebroken" (whatever that may be). Dus? Dat betekent niet meteen => DUS code injection. Het betekent misschien wel hooguit dat je alles na die quote mist. Of het te ge/misbruiken is daar niet uit te concluderen.

Nogmaals, ik ging even puur af op het scenario dat Hero of Time schetste:

Veel code gebruikt quotes (single en/of dubbel) om strings mee weer te geven.

Dat scenario hoeft natuurlijk helemaal niet waar te zijn.

Met "een string wordt vroegtijdig afgebroken" bedoel ik dat een programmeertaal een apostrof of quote in een string interpreteert als het einde van een string. Hierdoor wordt de rest van de string (na de apostrof/quote) uitgevoerd, wat een code injection is.

Ik kan niet veel legitieme talen/situaties bedenken waarin dat kan gebeuren. Het kan wel gebeuren als je strings rechtstreeks in SQL-queries drukt (wat de beroemde SQL injectie oplevert) of wanneer je eval gebruikt in PHP of zo. Maar dat zijn zoals ik al zei geen legitieme situaties (variabelen in SQL-queries hoor je te binden en eval hoor je helemaal niet te gebruiken).

Met andere woorden, het scenario van Hero of Time lijkt me niet erg plausibel. Maar als het wél zo is, heb je waarschijnlijk een groter probleem.

---

Hero of Time schreef op donderdag 30 juni 2016 @ 21:40:
[...]
Net zo goed dat een spatie aan het einde van een bestandsnaam mogelijk is. Linux en OSX doen daar niet moeilijk over. Krijg je zo'n bestand op een Windows systeem echter, dan krijg je doodleuk meldingen van 'permission denied' of 'file not found' oid. Want tja, de standaard verbied het niet. Betekend niet dat je het ook maar moet doen.

We hebben het hier over URLs, die gestandaardiseerd en duidelijk gedefinieerd zijn.

Bestandsnamen zijn dat niet; elk bestandsysteem heeft daar andere definities (en daarbij horende limiteringen) van.

[...]

Je bent een Linux gebruiker. Hoe kan het dan dat je zo simpel denkt, terwijl je perfect weet wat het gedrag kan zijn bij variabelen die onbedoeld korter zijn dan verwacht?

Sorry, hier ben ik je kwijt...

[RobIII]

Compizfox schreef op vrijdag 01 juli 2016 @ 19:44:
Ik ben uiteraard niet in staat om het te testen, maar het zou me verbazen als die browsers daar problemen mee hebben. Zoals ik al zei, is een apostrof helemaal geen raar teken, en mag het gewoon in een URL voorkomen. We hebben het hier over een doodnormaal ASCII-teken, niet specialer dan een - of een _ (waar je, hoop ik, toch ook geen problemen mee hebt?), niet over rare Unicode-karakters of Emoji of zo...

Nogmaals: deze hele discussie is zinloos. Niemand zegt dat je die tekens niet mag gebruiken. Niemand zegt dat die tekens afwijken van de standaard(en). Niemand zegt dat er iets mis mee is. Ik zeg alleen dat het internet groooooooot is en dat 't er vergeven is van browsers, crawlers, allerlei tools en whatnots die allemaal op hun eigen maniertje proberen te 'interacten' met alle pleuriszooi op internet. En al kunnen al die browsers er mee overweg, en al kan elke crawler ermee overweg, en al kan 99.9999% van alle andere software ermee overweg. Het. Zal. Allemaal. Wel.
Het enige dat werd aangegeven is dat 't nog veiliger is om tekens als een apostrof te vermijden. En, ja, die zit, voor mij, in een andere categorie als - en _. Ik ga lang genoeg mee om te weten / hebben gezien dat "gekke tekens" (en dan heb ik 't niet eens over unicode tekens maar gewoon leestekens en andere sh*t) software op z'n bek helpt. En dat blijkt nu dus ook wel. Ik betwist niet eens of 't een bug is, want dat is het (ik kan alleen, van hieruit, niet zien of 't in de camo proxy zit of elders). Ik betwist ook niet of 't volgens de standaard toegestaan is; daarom begon ik ook over theorie en praktijk.
Het enige dat gezegd werd is: als je problemen wil voorkomen kun je je gewoon 't beste beperken tot... En anders moet je vooral lekker je apostrofjes en sneeuwmannetjes gebruiken in je bestandsnamen. Maar dan moet je niet raar opkijken als je dan eens een keer ergens tegenaan loopt zoals nu gebeurde en aanleiding was voor dit topic.

Compizfox schreef op vrijdag 01 juli 2016 @ 19:44:
We hebben het hier over URLs, die gestandaardiseerd en duidelijk gedefinieerd zijn.

Je kunt definiëren en standaardiseren tot je een ons weegt; dat wil niet zeggen dat iedereen je definitie/standaard/spec/whatever correct (of volledig) implementeert. Ik verwijs nogmaals naar mijn theorie en praktijk verhaaltje, en, for that matter, al mijn overige posts hier in dit topic. Misschien herinner je je nog de tijd waarin het een wedstrijdje was welke browser hier 't eerst 100/100 scoorde of dit goed weergaf; leuk die standaarden maar de praktijk was (toen) anders. Hell, dat is 't nu nog; alleen in veel miniemere details / edgecases dan toen. Ja, browsers kunnen anno 2016 wel tegen een apostrofje, maar dat is helemaal niet relevant. Ergens "in de pijplijn" tussen browser, loadbalancers, webservers, camoproxy, caching en weet-ik-veel-wat-er-nog-meer-tussen-zit-bij-t.net zit dus ergens een componentje dat die apostrofs niet goed afhandelt. En dat had je voorkomen (of: zo is 't ook opgelost) als je gewoon vanaf 't begin die "gekke tekens" had vermeden.

[ Voor 23% gewijzigd door RobIII op 01-07-2016 20:14 ]

[crisp]

Volgens mij gaat dit fout in de rml-parser; de ' wordt html-escaped naar '

edit: en daar meteen een fix voor gemaakt die met de volgende iteratie online zal komen (eta: 3 weken)

[ Voor 38% gewijzigd door crisp op 25-08-2016 12:26 ]