enhance: other URL schemes

[Johann150]

resolves #72

• CHANGELOG.mdに変更点を追記してください。リファクタリングなど、利用者に影響を与えない変更についてはこの限りではありません。
• Please add the summary of the changes to CHANGELOG.md. However, this is not necessary for changes that do not affect the users, such as refactoring.

👀 CHANGELOG.md ?

• npm run test ✅
• npm run lint ✅
• npm run api ✅

[codecov]

Codecov Report

Merging #73 (7385378) into develop (78daf8b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop      #73   +/-   ##
========================================
  Coverage    92.27%   92.27%           
========================================
  Files            4        4           
  Lines          531      531           
  Branches        67       67           
========================================
  Hits           490      490           
  Misses          41       41           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78daf8b...7385378. Read the comment docs.

[syuilo]

🙏

[rinsuki]

wait, I think, after this pull-request merged, it can XSS by like [LETS GET ONE BILLION DALLERS HERE](javascript:alert(1)). we should add validate that it is known safe URL schemes.

[Johann150]

😨 You are right.
Are there any other URL schemes apart from javascript that you think are dangerous? Because I think it would be easier to only forbey specific URL schemes (like javascript) than to only allow specific URL schemes. Otherwise that would mean that there could be many "please add protocol xyz" issues in the future.

[rinsuki]

I don't know, but any URL schemes has a possibility dangerous in the future or specific environment. I prefer allow-list because deny-list may be bypassed if implementation is vulnerable for hacky escape or other something. I think "got many 'please add XXXX protocol' issue" is better than possibility vulnerable.

[Johann150]

Hmm, or maybe a content security policy could avoid such things.

<meta http-equiv="Content-Security-Policy" content="script-src 'self';">

This would allow JavaScript from javascript: and even data: etc. URLs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

[Johann150]

[...] may be bypassed if implementation is vulnerable for hacky escape or other something.

😕 If the browser is vulnerable, I don't think it would be MFM's or Misskey's responsibility to fix it?

[rinsuki]

yeah, If library users are using CSP correctly, XSS are never executed. but we shouldn't expect that 100% library users are using CSP. actually I think 99% of users are misskey-dev/misskey, but some clients can using this library too. and imagine what occured if this library used in Electron apps without CSP and user clicked javascript link...

[rinsuki]

[...] may be bypassed if implementation is vulnerable for hacky escape or other something.

😕 If the browser is vulnerable, I don't think it would be MFM's or Misskey's responsibility to fix it?

"implementation" of implementation is vulnerable means mfm.js deny-list implemention, not browser one.

[marihachi]

セキュリティの側面から見てなかったので、助かった。
使用可能なスキーマをホワイトリストにする方が良いかもしれない。

また、ユーザーアプリ側からホワイトリストをカスタマイズ可能にすることもできそう。(許可するかどうかは要検討)

このPRの内容からは若干反れるので、別のissueとした方が良さそう。

[syuilo]

うん、私もセキュリティの観点はすっぽり抜けてた
ありがとうございます🙏

[syuilo]

In the future, we may allow schemas other than http/https in a whitelist or blacklist format, but for now, we need to revert for safety. 🙏🏻