どうせ古いサイトは放置なんだろけど、はよ全ブラウザーに導入されてほしい ( ˘ω˘ )
innerHTML は使われすぎだもんなぁ。多くのスクリプト系言語にある eval を乱用するようなもの。
innerHTMLにさよならバイバイか。長かったな...。これでセキュリティ事故が少しは減るんだろうか。ようやく標準化されて安心だわ
浸透待ち
メディアの記事なら「JavaScript」の単語を一つでも冒頭に入れようぜ。対象読者にはわかるだろうけどさ
色々古いAPIなくなってるんだろうなー、知識がだいぶ止まってるからそのうちAIにまとめて聞かないとな
むしろ対象読者以外はJavaScriptなんて言われても分からんから不要なんよ
innerHTML のような Web API は通常 JavaScript の中で使われるけれど、厳密には JavaScript の言語仕様ではないからね
「サニタイズ」という用語を使っていたら、その人は問題を正しく把握していない可能性が高い。入力を「無毒化」するのではなく、出力をエスケープするのが正しい。
そのうちCSPでinnerHTMLを禁止する事が出来るようになるんだろうな。デフォルト禁止はbroke the webなので勘弁してもろて
"「Firefox 148」で導入された「Sanitizer API」は、「innerHTML」に代わる仕組みとして「setHTML()」を提供する。「setHTML()」は書き込み専用のメソッドで、危険なスクリプトを含むHTMLコードを渡しても、自動で“無毒化”を行う。"
xssはもうとっくに絶滅したんでは
こういうのは当分置き換え無理なんだろうなあ…。フレームワークがよしなに置き換えてくれるのを待つだけかな？
今日日XSS起こすのはサーバーサイドにしろクライアントサイドにしろフレームワークを適切に使ってないが所以だろうから、XSSの発生率にはそんなに影響しなそうな気もするw
jQuery は対応するのかな。
sanitizeは無害化って書く方が多そうな気がする
最近はライブラリやフレームワークで吸収しているのかと。「「innerHTML」プロパティには無毒化処理を実施する機能がなく、プログラマーが自分で処理を書く必要があった。そのため、無毒化処理にどうしても漏れが生じ」
いずれ React コンポーネントに dangerouslySetInnerHTML の代わりの safelySetHTML プロパティが生えたりするかな？
ユーザー入力は受け付けてないけど、setHTMLできるならさせてほしい。Chromeさんはよβ取って
ほー。
新しいの作るよりいまのinnerHTML代入時にブラウザがチェックしてくれればいいのに
そもそもinnerHTMLなんて古い書き方じゃなくてinsertAdjacentHTMLで書いてるが
なんでいままでなかったのか不思議なくらいの機能だ
『「setHTML()」は書き込み専用のメソッド』（´－｀）読み込みに問題がないなら書く時だけコレのエイリアスとして動いてくれればいいよね
innerHTMLの挙動を変えると互換性が失われるので別APIにするしかないと思うよ。
outerHTMLってのもある
AIがinnerHTMLを書かなくなる日はいつになるのかしら
"入力を「無毒化」するのではなく、出力をエスケープするのが正しい。"／それは同意だけど、このsetHTMLはその出力をエスケープするものでは？
そもそもサニタイズって考え方自体がすでに危険な気がするんですけど、そうは言っても必要ってことなんですかね…
よくあるケースのわりに、物凄く対策に時間がかかったなあという感じはするが、今のWebはそこまで後方互換性気にしないでいいし、Chromeで実装されたらガンガン使われるまで時間はかからないかな
かくして人類は "無毒化" というダークサイドに落ちてしまった。「サニタイズ言うな」の抵抗も空しく、人の子は20年かけても出力に応じた適切なエスケープができるようにはならなかったのだ。
innerHTMLに文字列設定が一番高速なことが多くセキュアじゃないとかとは別に利用価値はある
MDNによるとエスケープではなく削除／この分野、正しい方法は確立済みでその中での多層防御に思えるが、「正しい方法」に無頓着な層を救うことも意義なのかも。さらに、エスケープ無しの新パラダイムの可能性？
なるほど、SQLみたいにパラメータで対応できないからか。あんまり入力を直接渡すような処理を書いたことがなかった。
「サニタイズって言うな」と主張する人間のほうが異常だった。Sanitizer API以前からも英語圏でずっと使われている。
クロスサイトスクリプティングと呼ばれるタイプの脆弱性を抑制する技術。
確かに挙動が変わるよりは別手段を提供してくれる方が厄介にならずありがたい。
サニタイズとういう用語ですが、IPA安全なウェブサイトの作り方にも出てくる「HTMLテキストから…スクリプトを含まない必要な要素のみを抽出する」をサニタイズと呼ぶことが多いのですよ
む、スクリプトが削除されるのか。すり抜けそうだけど大丈夫なのかな。
入力でなく出力エスケープとか仮のDOM作って危険な部分を排除？単純なエスケープとも言えなさそうだしサニタイズでもまあいいんじゃないかな
XSS攻撃の温床「innerHTML」はもう終わり、「Firefox 148」に「setHTML()」が導入／入力を自動でサニタイズしてくれる「Sanitizer API」が実装
どうせ古いサイトは放置なんだろけど、はよ全ブラウザーに導入されてほしい ( ˘ω˘ )
innerHTML は使われすぎだもんなぁ。多くのスクリプト系言語にある eval を乱用するようなもの。
innerHTMLにさよならバイバイか。長かったな...。これでセキュリティ事故が少しは減るんだろうか。ようやく標準化されて安心だわ
浸透待ち
メディアの記事なら「JavaScript」の単語を一つでも冒頭に入れようぜ。対象読者にはわかるだろうけどさ
色々古いAPIなくなってるんだろうなー、知識がだいぶ止まってるからそのうちAIにまとめて聞かないとな
むしろ対象読者以外はJavaScriptなんて言われても分からんから不要なんよ
innerHTML のような Web API は通常 JavaScript の中で使われるけれど、厳密には JavaScript の言語仕様ではないからね
「サニタイズ」という用語を使っていたら、その人は問題を正しく把握していない可能性が高い。入力を「無毒化」するのではなく、出力をエスケープするのが正しい。
そのうちCSPでinnerHTMLを禁止する事が出来るようになるんだろうな。デフォルト禁止はbroke the webなので勘弁してもろて
"「Firefox 148」で導入された「Sanitizer API」は、「innerHTML」に代わる仕組みとして「setHTML()」を提供する。「setHTML()」は書き込み専用のメソッドで、危険なスクリプトを含むHTMLコードを渡しても、自動で“無毒化”を行う。"
xssはもうとっくに絶滅したんでは
こういうのは当分置き換え無理なんだろうなあ…。フレームワークがよしなに置き換えてくれるのを待つだけかな？
今日日XSS起こすのはサーバーサイドにしろクライアントサイドにしろフレームワークを適切に使ってないが所以だろうから、XSSの発生率にはそんなに影響しなそうな気もするw
jQuery は対応するのかな。
sanitizeは無害化って書く方が多そうな気がする
最近はライブラリやフレームワークで吸収しているのかと。「「innerHTML」プロパティには無毒化処理を実施する機能がなく、プログラマーが自分で処理を書く必要があった。そのため、無毒化処理にどうしても漏れが生じ」
いずれ React コンポーネントに dangerouslySetInnerHTML の代わりの safelySetHTML プロパティが生えたりするかな？
ユーザー入力は受け付けてないけど、setHTMLできるならさせてほしい。Chromeさんはよβ取って
ほー。
新しいの作るよりいまのinnerHTML代入時にブラウザがチェックしてくれればいいのに
そもそもinnerHTMLなんて古い書き方じゃなくてinsertAdjacentHTMLで書いてるが
なんでいままでなかったのか不思議なくらいの機能だ
『「setHTML()」は書き込み専用のメソッド』（´－｀）読み込みに問題がないなら書く時だけコレのエイリアスとして動いてくれればいいよね
innerHTMLの挙動を変えると互換性が失われるので別APIにするしかないと思うよ。
outerHTMLってのもある
AIがinnerHTMLを書かなくなる日はいつになるのかしら
"入力を「無毒化」するのではなく、出力をエスケープするのが正しい。"／それは同意だけど、このsetHTMLはその出力をエスケープするものでは？
そもそもサニタイズって考え方自体がすでに危険な気がするんですけど、そうは言っても必要ってことなんですかね…
よくあるケースのわりに、物凄く対策に時間がかかったなあという感じはするが、今のWebはそこまで後方互換性気にしないでいいし、Chromeで実装されたらガンガン使われるまで時間はかからないかな
かくして人類は "無毒化" というダークサイドに落ちてしまった。「サニタイズ言うな」の抵抗も空しく、人の子は20年かけても出力に応じた適切なエスケープができるようにはならなかったのだ。
innerHTMLに文字列設定が一番高速なことが多くセキュアじゃないとかとは別に利用価値はある
MDNによるとエスケープではなく削除／この分野、正しい方法は確立済みでその中での多層防御に思えるが、「正しい方法」に無頓着な層を救うことも意義なのかも。さらに、エスケープ無しの新パラダイムの可能性？
なるほど、SQLみたいにパラメータで対応できないからか。あんまり入力を直接渡すような処理を書いたことがなかった。
「サニタイズって言うな」と主張する人間のほうが異常だった。Sanitizer API以前からも英語圏でずっと使われている。
クロスサイトスクリプティングと呼ばれるタイプの脆弱性を抑制する技術。
確かに挙動が変わるよりは別手段を提供してくれる方が厄介にならずありがたい。
サニタイズとういう用語ですが、IPA安全なウェブサイトの作り方にも出てくる「HTMLテキストから…スクリプトを含まない必要な要素のみを抽出する」をサニタイズと呼ぶことが多いのですよ
む、スクリプトが削除されるのか。すり抜けそうだけど大丈夫なのかな。
入力でなく出力エスケープとか仮のDOM作って危険な部分を排除？単純なエスケープとも言えなさそうだしサニタイズでもまあいいんじゃないかな