Hacker News new | ask | show | jobs
by Flimm 910 days ago
It's disappointing that Meta chose not to fix this and chose not to reward this researcher with a bug bounty.
4 comments

I reported a similar issue to Google early this year and they declined the submission because it "can only result from social engineering" and "we think that addressing it would not make our users significantly less vulnerable".

I won't mention the details here but Google Search sometimes rewrite URLs in such way that an attacker can spoof the actual URL.

My advice is to never trust URLs displayed by websites and apps.

> I won't mention the details here but Google Search sometimes rewrite URLs in such way that an attacker can spoof the actual URL.

I think I saw something like this a while ago, with some fake KeePass website maybe.

This is an actual feature for AdWords (which show up in search results). But at least there's some moderation of the rendered domain in that case.
I know you are referring to those fake KeePass malware ads, but just to clarify: the issue I reported was not related to AdWords - it was for normal search results
They're to busy sending legal threats to OSS projects
I expect they probably didn't make clear exactly what they wanted fixed (blacklisting the RTL character) and Meta thought they wanted all misleading URLs fixed which is not really possible.
There's nothing to fix, this is intended, just often "re-discovered" behavior.
TFA mentions that Twitter, TikTok, and Pinterest all sanitize U+202E. Sanitizing it in WhatsApp would be a nice fix.
That’s still a Meta problem. Simply confirming the PoC should have made it clear that they need to fix something.
POC?
Proof of concept.
Proof of Concept
How can they blacklist this character while still supporting URLs in right-to-left languages?
You don't need RIGHT-TO-LEFT OVERRIDE to support URLs in right-to-left languages. It's an extremely rare codepoint that's used to force left-to-right characters to be displayed as if they were right-to-left characters. The only use case I can think of off the top of my head is some kind of interlinear phonetic transcription where you want Latin characters to flow the same direction as the corresponding Arabic for ease of cross-referencing.

For ordinary bidirectional texts, RIGHT-TO-LEFT ISOLATE, its sibling LEFT-TO-RIGHT ISOLATE and POP DIRECTIONAL FORMATTING are plenty:

⁧عنوان URL لهذا التعليق هو: https://news.ycombinator.com/item?id=38734329‬

Where I used RIGHT-TO-LEFT ISOLATE in the beginning to make sure the Arabic text in front of the colon is to the right of it, and then POP DIRECTIONAL FORMATTING in the end to restore the original directionality. (Amusingly, HN's URL parser treats the POP DIRECTIONAL FORMATTING as part of the URL, which breaks the link.)

Otherwise it would show up like below, where "in front of the colon" means "left of it" (as is customary in English text):

عنوان URL لهذا التعليق هو: https://news.ycombinator.com/item?id=38734329

You can only apply the fix to the URL field in the payload described, not to normal message text.
The client should probably be aware of whether the user might be expecting RTL text and maybe display a warning if not? Arabic users receiving a URL containing the character shouldn't raise any eyebrows, but if a random Anglo user clicks on one it might be worth displaying a warning that it's backwards text? At least the first time.
It wouldn't really solve the problem, sadly. The percentage of people who'd bother to read that warning is likely quite low.
I don't think that's a good reason for not including such a warning.

"quite low" for a service with billions of users, can still allow for million of users who would benefit from seeing the warning.

This does not solve the issue for arabic users. Sounds not good for me declaring the problem solved just because it was solved for people speaking certain languages. Or attacking the problem excluding certain languages.
They’ll fix it. They just won’t reward the bounty hunter.
And therefore, future bounty hunters will make sure to offer their next 0day to the highest bidder instead.