質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

Q&A

解決済

4回答

747閲覧

コンソールからDOMから新たに手が加えられたら無効化する

valvalx

総合スコア22

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

0グッド

1クリップ

投稿2022/07/01 03:47

編集2022/07/02 10:38

コンソールからDOMから新たに手が加えられたら無効化したいです

ページをロード後、新たにappendやらJSの記述がされて、既存の記述に手を加えらえるのを防ぎたいです

どうすれば防げるのでしょうか

また、なぜいつまでもたってもホームページのソース(データ)を保護するという観点が生まれていないのか、その理由を聞きたいです
第三者が手を加えられる状況は1番まずいと考えるのが普通ではないのでしょうか
開発者側でなんとかする問題ではなく、デベロッパーツールなるものを搭載したブラウザ側の問題だと思うのですが?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

なぜいつまでもたってもホームページのソース(データ)を保護するという観点が生まれていないのか

逆にそれがなぜ必要なのでしょうか。サーバサイドはデータを発信するまでが役割であって、得たデータを受け手がどうしようが、何らの問題もないはずです(もしそれで不正な操作が行えるのであれば、サーバサイドで防げばいいだけです)。

投稿2022/07/01 03:53

編集2022/07/01 03:53
maisumakun

総合スコア145121

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

maisumakun

2022/07/01 03:55 編集

> 開発者側でなんとかする問題ではなく、デベロッパーツールなるものを搭載したブラウザ側の問題だと思うのですが? 別にHTTPアクセスするクライアントはブラウザに限られません。wgetなどで組織的にダウンロードを行って、データを利用することも可能ですし、検索エンジン用のクローラも日夜Webを駆け回っています。
valvalx

2022/07/01 03:57

それはわかりますがクライアントが外部からいじれないようにするかどうかの観点はないんでしょうか? いじれるってことは、まずいことにつながりかねない、 ならばいじれないようにする とならないということは ならないんでしょうか サーバー側のデータはいじれないからクライアントは好き勝手いじれていいでしょ、とは違うと思いますが?
maisumakun

2022/07/01 04:05 編集

そこまで気にされるのであれば、ブラウザというプラットフォームを使うのをやめたほうがいいのではないでしょうか? > サーバー側のデータはいじれないからクライアントは好き勝手いじれていいでしょ、とは違うと思いますが? 違いません。ユーザースクリプトやプラグインなど、「ユーザー自身の意志で」Webページに手を入れられる機能が存在する(そして、技術的には何でも可能)、というのがブラウザの現実です。
valvalx

2022/07/01 04:06

あなたはサーバー側で制御すれば問題ない話 私はクライアントで第三者が既存のデータをいじれるほうがおかしい 話がかみ合わないですね
maisumakun

2022/07/01 04:14 編集

> 私はクライアントで第三者が既存のデータをいじれるほうがおかしい おかしいという考えがおかしい(現実を見ていない)、という回答です。仮にブラウザでガードするような機能があったとしても、攻撃者は任意のクライアントを利用可能です。
maisumakun

2022/07/01 04:13

> いじれるってことは、まずいことにつながりかねない 「まずいこと」というのは、どのようなことを考えていますか?(自分がざっと考えた限りでは、「まっとうな実装を行った状況で、ブラウザサイドさえ守れば、(手間が増える程度では回避できず)有意に何かを防げる」ようなものは思いつきませんでした)
valvalx

2022/07/01 04:15

結局なにかしらの脆弱性につながると思うんですけど?(XSSやらCSRFやらなにやら) その諸悪の根源が便利だとして生み出された機能だから目をつむるんですか?
maisumakun

2022/07/01 04:24 編集

> 結局なにかしらの脆弱性につながると思うんですけど?(XSSやらCSRFやらなにやら) CSRFは第三者が作成したページからも実行可能なもので、仮にブラウザサイドでのページ加工が許されなかったとしてもサーバサイドで対策を行わなければどうしようもないものです。 そして、自分の意志でページを加工して、自分の意志でデータを送る分にはXSSとは言いません。
valvalx

2022/07/01 04:28

言葉尻ばかり捕らえることはやめていただきたい
maisumakun

2022/07/01 04:33 編集

では、ブラウザサイドを改変できることで存在する「脆弱性」を具体的に示してください(ブラウザ以外のクライアントを使う、あるいはページをコピーするなど、ブラウザ上での改変を加えずとも攻撃者サイドのパソコン内で容易に実現可能なものは除いてです)。
valvalx

2022/07/01 04:38

XSS、CSRFを例として挙げましたが、 あなたはこれを除いて100%脆弱性を生まないと思ってるいるのでしょうか?
valvalx

2022/07/01 04:39 編集

そうであればすごい自信ですね、あなたが公開してる不動産サイトはさぞかし対策されて完璧なんですかね
maisumakun

2022/07/01 04:44 編集

> あなたはこれを除いて100%脆弱性を生まないと思ってるいるのでしょうか? サーバサイドの脆弱性は、「ブラウザに加工をしなくても」利用することができます(むしろ、特殊なヘッダを追加しないといけないものはブラウザから利用することが困難なぐらいです)。 ブラウザサイドの編集「がなければ発生しない」脆弱性、として思い当たるのは、ユーザーを誘導してコンソールに変な値を打ち込ませるSelf XSS程度です。
valvalx

2022/07/01 04:46 編集

今現在の過去までが全て 自分の知らない未知の世界があるか あなたにはどう映ってるか知りませんが 100%はないんですよ
maisumakun

2022/07/01 04:47

> 100%はないんですよ そのとおりです。そして、Webへのアクセスも100%がブラウザではありません。 他の方法でアクセスすれば可能なことを、ブラウザ「だけで」規制しても、ほぼ無意味です。
valvalx

2022/07/01 04:50

ではなぜあなたは言い切った? >ユーザーを誘導してコンソールに変な値を打ち込ませるSelf XSS程度です。
maisumakun

2022/07/01 04:55 編集

ブラウザ内でユーザーが改変して実行できることは、(Self XSSや不正なプラグインなどで本人が意図しないところにアクセスしてしまうような例を除けば)、もともとそのユーザーに可能なことをユーザー自身の自由意志で行っているだけで、それは他のツールを使っても可能です。
maisumakun

2022/07/01 05:07

武器を10個も20個も持っている攻撃者に対して、ブラウザというたった1つを塞いだところでどれほどの意味があるのか、という話です。
guest

0

ベストアンサー

要素に関しては、元からある要素と勝手に足された要素を区別する手段があれば、MutationObserver で監視して足されたものを消すことは可能かもしれません。しかし、既存の要素の属性を書き換えられると元に戻せませんし、既存の要素を消されると元に戻せません。変更を検知したらリロードしてしまう、などの対処になってしまうかもしれません。

どんなクライアントでもアクセスできる以上、クライアント側に渡ったデータを守ろうとしても無駄なので、そのようなことに手間をかけることは通常はしないでしょう。

投稿2022/07/01 04:07

int32_t

総合スコア20670

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ウェブブラウザ+HTTP+ウェブサーバーの仕組みに限らず、電子メールやftpやssh等も「サーバーとクライアントの間でのプロトコルだけ決めておくので、サーバーもクライアントもそれぞれ好きにして」という仕組みです。
オープンな仕組みという物はそういう物なので、オープンな仕組みが考えに合わないと言うことであれば、HTTPのようなオープンなアプリケーションプロトコルを使わず、独自に秘密の通信プロトコルと、サーバープログラム、クライアントプログラムの設計をすることになるかと思います。

デベロッパーツールなるものを搭載したブラウザ側の問題だと思うのですが?

ブラウザの開発者ツールがあってもなくても、HTMLはクライアント側で好きに加工できるということは理解されていますか?

投稿2022/07/01 17:02

編集2022/07/01 17:04
otn

総合スコア84423

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

valvalx

2022/07/02 01:16

>ブラウザの開発者ツールがあってもなくても、HTMLはクライアント側で好きに加工できるということは理解されていますか? アドレスバーからjavascriptを実行する方法しか知りません
otn

2022/07/02 01:38 編集

> アドレスバーからjavascriptを実行する方法しか知りません ブラウザ相当のプログラムを作るのはそう大変なことでは無いです。オープンソースのブラウザの修正という方法もあるし。 自分でゼロから画面描画まで作るのは困難ですが、HTMLをハンドリングするだけなら簡単。ウェブサイトの脆弱性を突く攻撃はそういう方法でされていることでしょう。
guest

0

なぜいつまでもたってもホームページのソース(データ)を保護するという観点が生まれていないのか、その理由を聞きたいです

 類型的な XSS で混入される不正なコードは、ブラウザから見るとサーバから送信された正当なスクリプトの実行結果に見えるので、DOMの変更をブロックしても防げないです。

 類型的な CSRF は、そもそもスクリプトの実行ではなくて不正なリクエストの発行ですので、なんでしたらそもそもDOMを通す必要さえないため、DOMの変更とは関係ないです。

 現状のブラウザのセキュリティは、第三者が「クライアントユーザーを偽装してリクエストをする」または「サーバから送信された正当なコードを偽装してスクリプトを実行する」ことなど、「偽装」を防ぐことに注力しています。

 ブラウザの攻撃は「偽装」によってやってくるので、「サーバ発行ではないDOMの変更をブロックする」という対策をしても、そもそも「サーバ発行」であると「偽装」しているので効果が薄い、ということです。


 もちろん、「サーバ発行のDOM変更もブロック」すれば全ての「偽装」をブロックできますから、セキュリティを多少は強化できるとは思います。

 実際のところ、20世紀のインターネットはそのようなものでした。お若い方には信じられないかと思いますが、「JavaScriptはオフが常識」という時代がしばらくあったのです。DHTML などはパソコンオタクの趣味のセカイであって、大抵のユーザーには JavaScript など不要のものであったのです。

 しかし、21世紀の現在にそれでは、Googleマップ もなにも動かなくなってしまいます。いまさらそこへは戻れないでしょう。


 最近メジャーブラウザで実装されたコンテンツセキュリティポリシーは、<script>要素などで書かれたインラインスクリプトの実行をブロックするなど強力なスクリプト制御ができますが、こちらでもコンソールでのスクリプト実行はブロックしません。また、対応していないブラウザでは素通しです。

投稿2022/07/01 08:35

Lhankor_Mhy

総合スコア35869

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問