Geen flauw idee waarom Microsoft code toestaat in bestandsnamen.

Dat doen ze ook niet. Een bestandsnaam is niet meer dan dat, een naam. Maar het is hoe Windows er mee omgaat. Door de RTLO-truc kun je dus een 'onschuldige' bestandsnaam laten zien, maar Windows zal het bestand behandelen volgens de echte extensie. Bij een JPG is klikken 'tonen'...maar bij een EXE is dat 'uitvoeren'. En dat is precies wat er onder water gebeurt.

@17:01 door Anoniem

Dat is geen programmacode, dat is unicode, een universele karakterset. Het beveiligingsprobleem is toepassing op talen die niet van rechts naar links worden gelezen. Het is overigens heel makkelijk te detecteren.

Het genoemde onderwerp is typisch voor Chinese aanvallers. Waarom ze dat zo duidelijk maken in de onderwerpen? Misschien om juist anderen de schuld te kunnen geven (overduidelijke zelf-implicatie is niet plausibel). Soortgelijke aanvallen gebeuren sinds 2004 (eerder waren de aanvallen primitiever).

Met "ik heb" ervoor en alsje was gestopt voor "waarom" was het een zinniger reactie geweest.

Het betreft namelijk geen code maar een Unicode character tbv Right To Left talen (als Arabisch of Hebreeuws).

Zelfde character wordt ondersteund op vrijwel ieder platform en betreft de visuele representatie van de tekst.

Het is echter een nauwelijks nieuwe aanval of methode te noemen. De nieuwswaarde schuilt erin dat het blijkbaar vaker is gebruikt en zorgelijker: het hergebruiken van gestolen certificaten.

Dit is niet de eerste demonstratie dat unicode eigenlijk gewoon [x] ongeschikt is als encoding voor data uit den vreemde --het gaat goed zolang je de data kan vertrouwen geen rare truuks uit te halen, en dat kan je met data uit den vreemde qq. niet--, en daarmee [x] ongeschikt als gegevensuitwisselingsbasis.

Unicode is de basis voor het web, geheel open van karakters bedoeld voor uitwisseling zonder beperking van een cultuur.(engels VS). XML en meer van die uitwisselingsstandaards gaan uit van utf8. Aangezien er meerdere talen de volgorde van links naar rechts hebben bestaat de aansturing.

Misleiding onstaat door de onwetenheid van de ontvanger.
De meeste programmeurs kunnen niet met Unicode overweg. Het denken moet namelijk ook om. Geleerd is dat 1 byte 8bit is 1 karakter. Dat moet je verlaten naar 1-4 bytes is 1 karakter.

Dat laatste is onzin. Je hebt kennelijk weinig inlevingsvermogen als je dat echt denkt.

Unicode is niet de "basis van het web". Het is een karakter set zoals er vele andere zijn. Met dien verschil dat - zoals uni suggereert - het een universele karakter set is en dus heel veel karakters, geschikt voor een groot aantal talen, herbergt. Dit in plaats van de afzonderlijke karakter sets en alle varianten die voornamelijk decennia geleden zijn bedacht zonder ver vooruit te kijken.

Cultuur is geen factor in unicode. Taal wel.

Om on topic te blijven: zoals ik al schreef om 17:45 is unicode niet erg veilig. Je kunt veel truuks uithalen om mensen te misleiden. Ik zal ze niet op een publiek forum noemen. Er is overigens geen 1 unicode, het zo universeel dat er verschillende incarnaties zijn, ook met verschillende doelen.

Dus het is unicode... Maar vooral niet toegeven dat het code is hoor. hahaha

Punt is, als de bestandsnaam SexyPictureGirlAl[RTLO]gpj.exe is dan moet je SexyPictureGirlAl[RTLO]gpj.exe laten zien en niets anders!

Nee hoor, free speech heeft een grens.

Nee hoor. Het is een zoveelste codepage, deze keer een die als doel heeft alle anderen te vervangen. Maar het blijkt een brak vehikel -- dit is niet het eerste beveiligingsprobleem dat mogelijk gemaakt wordt door unicode.

Slachtoffers de schuld geven is wel makkelijk, maar niet constructief.

Dat eerste is in meerdere andere karaktersets ook al niet waar. Dat tweede is in utf-8 ook niet waar: Zoiets is een enkel "codepoint" maar dat is niet het hele verhaal. Er zijn ook accenten, zowel in de smaak codepunt(karaktervariant-met-accent) als in de smaak codepunt(karakter)+codepunt(accent). En dan heb je nog geintjes als codepunt(breedteloze spatie), het bovenstaande codepunt(rechts-naar-links-nu), en meer van dat moois. De aloude ascii-controletekens zitten er ook nog in, en zijn dat karakters? Oh, en dat allemaal aangenomen dat er geen illegale utf-8 reeksen in de bytestream voorkomen. Dus nee, zo simpel ligt het niet.


Leg eens uit wat "free speech", met of zonder grenzen, met unicode te maken heeft?

Een stoomtrein is ook geen trein zeker, LOL!

Sommige mensen snappen het niet. Het gaat hier om een bestandsnaam, niet om opgemaakte tekst in een Word-document. En als je die bestandsnaam anders gaat weergeven omdat er [RTLO] in voor komt, dan geef je mensen dus de kans om rottigheid uit te halen, en dat mag je Microsoft wel kwalijk nemen. Gewoon [ ] niet toestaan in bestandsnamen zou deze ellende al oplossen maar ja, wie ben ik.

Nee hoor. Het is een zoveelste codepage, deze keer een die als doel heeft alle anderen te vervangen. ...
https://en.wikipedia.org/wiki/Unicode_and_HTML https://en.wikipedia.org/wiki/Code_page het veraad mijn achtergrond. Een verschil met de enumeration en encoding is in het englisch wat genuanceerder.
Je ziet dat een code-page altjid volledig is maar de enumeration niet. Je noemde dat verschil zelf al.
Waar het om gaat is de encoding met i18n. Met JSON heb je het laatste uitwisselingsgebeuren dat eenvoudiger met xml zou moeten zijn. https://en.wikipedia.org/wiki/JSON aanname utf8.

Blijft het issue: met ANSI code_pages. De single-byte versie zijn algemeen bekend. je kunt het makkelijk in de 256 (0-255) mogelijkheden aanwijzen. Daarmee is het volledig ongeschikt als communicatie middel gebleken. Ergerlijker: Je zult de code-page definities bij leveranciers moeten nalopen. Reden is dat ze soms andere invullingen met de zelfde naam/conventie hebben. Dat kan per release ook nog eens veranderen.

Eens met je, niet de eindgebruiker maar degeen die hem de software geeft zou wat alerter moeten zijn.
Ah kijk dat is de goede reactie als het kwaad kan, dus alles wat niet 7-bit ascii (hoger dan '7f'x is en niet lager dan '20'x beter laten zien door een programmeur. RTLO is bekend, zou bekend moeten zijn. Ooit gespeeld met de backspace '08'x, dat is al heel oud en kan ook zo in een naam . Niet opnemen in bestandsname gaat niet meer werken. De gebruikers wilden perse lange leesbare namen (+256) en alle tekena (8-bit extended ascii), Dat punt is al passeerd.

- Je kan het denk eens zijn met dat variabel zijn in lengte (alternatieven utf16 2 of 4 bytes , utf32) staat in de link beschrijving utf8
- Control karakters letterlijk vertaal controle tekens, ja dat zijn dus karakters. Soms geven die nog leuke tekens op het scherm. Bel en kaartspel-tekens.
- Eens, zo simpel ligt het allemaal niet. Als we nu zouden proberen het simpel te maken zonder te liegen en bedriegen?
Dus vertellen dat het meerdere bytes kunnen zijn en dat het niet is wat het lijkt te zijn.

Nog wat van die niet simpele dingen:
- Big-endian little-endian (bom teken) en
- extended ascii zoals een Mu-teken (single byte) in en single byte processing utf8 aanleveren met fixed kolommen in bytes (CDISC) levert leuke verrassingen.

Kortom, jezelf aanleren om i.p.pv dubbelklikken altijd rechtsklik te doen en dan een van de opties te kiezen.
"open" en "run as administrator" duidt op een applicatie
"preview" en "set as desktop background" op een plaatje
"open with adobe reader" op een pdf waarvoor een standard applicatie is ingesteld
etc

Dit is natuurlijk niet hard te maken zonder onze Arabische en Hebreeuwse "vrienden" voor de kop te stoten.
Een bestandnaam is alleen maar een rij bytes. Als deze in hex 41 42 43 is dan verwacht jij dat er op je scherm ABC
komt te staan. Maar dat is alleen maar omdat we afgesproken hebben dat 41 hex een A is, etc, en omdat we de
tekens van links naar rechts op het scherm zetten.

In Arabische talen ligt dat anders. Daar worden de tekens van rechts naar links op het scherm gezet, maar er zijn
uitzonderingen. Met name als er dit soort "leenwoorden" als file extensies zijn dan schrijft men van links naar rechts.

Als een Arabier de bestandnaam met een [RTLO] code heeft dan verwacht hij dat vanaf die plek de richting omgekeerd is.
Dat is de manier waarop die mensen lezen en schrijven. Wij vinden het heel onlogisch maar zij schrijven sommige
dingen van rechts naar links en andere dingen van links naar rechts en daar heb je mee te dealen als je die talen
ondersteunt in je characterset. Het is niet anders.

Het enige wat je eventueel zou kunnen doen om dit op te lossen is een landinstelling optie maken voor het ondersteunen
van [RTLO] die dan default uit staat in landen met latijns schrift en aan in landen met arabisch schrift. Die kan de
gebruiker dan zelf instellen afhankelijk van zijn/haar behoeften. De gebruikers in de landen die deze code niet nodig
hebben zouden er dan ook geen gevaar door lopen.

Het gaat er maar om hoe ver je wilt gaan in het toestaan van rommel in bestandsnamen.
Wat mij betreft hoeven we hier in de westerse wereld geen ondersteuning te bieden voor alle talen in de wereld als het gaat om de naamgeving (en ook de weergave daarvan) van bestandsnamen.

Eigenlijk heb je hier al genoeg aan:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz0123456789
& ( ) - _ ' , .

Dus 1 byte is 1 charakter is zelfs makkelijk haalbaar! Maar daar moet je dan dus afspraken over maken.
Ik zie er in ieder geval geen enkel bezwaar in om bestandsnamen simpel (en dus veiliger) te houden.

De tekst van bijvoorbeeld Arabische websites (en Word documenten en dergelijke) in de eigen moedertaal en leesrichting lezen kan nog steeds, dat staat hier los van. Je hoeft voor bestandsnamen immers niet dezelfde codepage te gebruiken als voor html, doc, rtf, enzovoort.