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

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

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

JSON(JavaScript Object Notation)は軽量なデータ記述言語の1つである。構文はJavaScriptをベースとしていますが、JavaScriptに限定されたものではなく、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しが行えるように設計されています。

Q&A

4回答

2070閲覧

JSON 危険性をご指摘ください

asdz

総合スコア0

JSON

JSON(JavaScript Object Notation)は軽量なデータ記述言語の1つである。構文はJavaScriptをベースとしていますが、JavaScriptに限定されたものではなく、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しが行えるように設計されています。

0グッド

2クリップ

投稿2021/04/15 02:34

編集2021/04/15 02:36

JSONの危険性を教えてください
DBが扱えないため、ユーザIDとパスワードをJSONファイルに保存しています

中身はuser.json
{"your_id":"aho","your_pw":"aaa"}
このように記述されているとします

これをPHPで中身を吐き出させてAjaxで取得するという処理をしています
PHPで中身を吐き出させるのでuser.jsonの場所はわからない状態です
PHPで中身を吐き出す際にunsetでpwは出力しないようにしてあります
Ajaxによる通信で開発ツールのネットワークにはyour_id:ahoというレスポンスのみが返ってくる状態です

ここで憶測でyour_pwがパスワードだろうと当てられた場合に、
JSまたは何かによってyour_pwを取得される可能性はありますでしょうか?
user.jsonの場所はわからない状態にしてあればとりあえず安心していいでしょうか?

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

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

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

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

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

miyabi_takatsuk

2021/04/15 03:16

> user.jsonの場所はわからない状態 場所によります。 もし、ドキュメントルート以下の階層にあるなら、どんなにBasic認証を効かせたりなどしても、危険過ぎます。
asdz

2021/04/15 03:23

えっと、user.jsonが割れたら危険だというのはわかりますが、 その他の危険性について教えていただけませんでしょうか?
miyabi_takatsuk

2021/04/15 03:29 編集

わかりずらくてすみません。 つまり、jsonファイルが読まれるか読まれないかが争点である、ですよね。 ようはどこにファイルを置いているのか、を質問本文に記載いただいた方が回答つきやすいです、って話です。 (それによって、場所がわからずとも、攻撃を受ける可能性の高低が分かれる、ということです) ドキュメントルート以下ですか? それとも、ドキュメントルート外の領域でしょうか? 質問本文は編集できますので、記載お願いします。
miyabi_takatsuk

2021/04/15 03:45

もう一点。 > DBが扱えないため これはサーバーがDBを使えないのでしょうか? それとも、質問者さんがその技術を持ち合わせていない、のでしょうか?
ockeghem

2021/04/15 08:35

いや、見てはおりますw 回答するかどうかは検討中で…
ockeghem

2021/04/15 08:37

正常系のユースケースがよく分からないので回答しづらいです
guest

回答4

0

実装方式の詳細が書かれていないので、危険性についても「よく分からない」というのが正直なところです。既に指摘のあるパスワードの保護がなされていない点については、以下の動画を見ていただくのがよいと思います。なぜパスワードを保護しなければならないのかが2つ目、どう保護すればよいかが3つ目の動画になります。

超入門:ウェブサイトのパスワード保護~ウェブサイトへのパスワード攻撃の現状~ - YouTube
超入門:ウェブサイトのパスワード保護~ウェブサイトのパスワード管理に対する誤解~ - YouTube
超入門:ウェブサイトのパスワード保護~ウェブサイトでパスワードを保護する方法~ - YouTube

投稿2021/04/15 11:59

ockeghem

総合スコア11701

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

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

0

パスワードを平文で保存しているという、初歩的なミスをしていないと仮定すると。

  • JSONをドキュメントルート下に置いていない
  • サーバーに置いてある全てのファイルにおいてユーザーの入力を一切信用しない

らへんを守れば提示の環境下においては危険度は高くないと思います。

が、私の回答を信じるかどうかは質問者さん次第なので、これを実装したことによる責任は私は一切取れませんのでご承知おきを。

投稿2021/04/15 03:55

編集2021/04/15 03:58
kyoya0819

総合スコア10429

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

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

0

質問への直接的な回答ではないですが
最も大きな問題は、ファイルの排他制御だと思います。
json いうよりファイルを使用したシステム全般に言える事ですが、ちゃんとしようとすればするほどメンドイです。

投稿2021/04/15 08:05

編集2021/04/15 08:07
退会済みユーザー

退会済みユーザー

総合スコア0

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

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

退会済みユーザー

退会済みユーザー

2021/04/15 08:07

ミスるとファイルが壊れます。
guest

0

いくつかパターンや、確認すべきことがありますので、
項目に分けて回答いたします。

ファイルの置き場所によって危険度が大きく違う

ドキュメントルート以下にファイルを設置している場合、
そのファイルの場所がわかる、わからない以前の問題で、
いずれにせよ危険となります。
なぜなら、ドキュメントルート以下であれば、
やろうと思えば、それ以下の全ファイルをダウンロードすることが、比較的容易だからです。
PHPファイルも含めてです。
そうなれば、セキュリティもクソもないのは、言うまでもありません。
ゆえに、WordPressなどのドキュメントルート以下にアプリケーションを設置するCMSは危険だと、一時期話題になったのです。
(現在はかなりセキュリティ措置が強化されている様子)
なので、httpアクセスからは、サーバーから403コード(閲覧許可を出していない)を返すことは最低限必須となります。
ただし、それでも破る方法はあるかと思いますので、故にいずれにせよと記載しました。
なので、どうしてもJSONファイルでの管理を余儀なくされている場合は、
ドキュメントルートより高階層にファイルを置くのが最低限のセキュリティ担保となるでしょう。

パスワードの記載に関して

さて、これは、DBで管理する上でも同じ措置をしますが、
パスワードは、記録する時はハッシュ&ソルト化をした方を記録することが必須となります。
ユーザーがログインなどする際は、
PHPの照合関数を使用し、照合をかける、という措置です。
これを行うのは、万が一、DBを覗かれた、本件でのJSONファイルを見られた、または、流出してしまった場合でも、
BcryptやArgon2系の脆弱性がない、また平文が盗聴されていない限り、またログイン処理や認証に脆弱性がない場合、総当たり攻撃以外に偽ログインする方法はないからです。
(もしかしたら、攻撃方法はあるかもしれないが、多くの場合は大丈夫になる)
ここら辺のセキュリティ措置に関しては、よくよく勉強されるとよいかと。

JSONファイルの方が扱いがめんどくさい

さて、これは、もし、質問者さんが、DBの技術がないから、JSONファイル管理を選んでいるとしたらの話です。
ぶっちゃけ、DBの方が楽です。
検索機能もありますし、
特定のレコードに対してのコントロールや、テーブル間の同時コントロールなどが容易になるような設計や、仕様が盛り沢山です。
JSONファイルで管理するなら、それらの仕様や機能を、自身で実装せねばなりません。(もしくはライブラリ)
なので、もし、**DBだとハードル高そう・・・**と思ってJSONでやっているなら、
DBの勉強をされた方が、遥かにハードル低いです。

また、下記記事が大変参考になるかと思いますので、
ご一読されるとよいかと。

安全なウェブサイトの作り方:IPA 独立行政法人 情報処理推進機構

以上になります。

@kyoya0819さん
たびたびありがとうございます。
また内容不備ありましたら、ご指摘いただければ幸いです。

投稿2021/04/15 04:08

編集2021/04/15 05:20
miyabi_takatsuk

総合スコア9528

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

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

kyoya0819

2021/04/15 04:51

ものすごく細かい話にはなりますが、、、 > パスワードは、記録する時は暗号化した方を記録する x 暗号化 o ハッシュ&ソルト だと思われます。。
miyabi_takatsuk

2021/04/15 04:55

ご指摘ありがとうございます。 どこかの記事で、暗号化では不十分とか、方式を変えるべきってみたことがあったのを思い出しました 苦笑
kyoya0819

2021/04/15 05:11 編集

たびたびすみません。 > ユーザーの入力を、ハッシュ&ソルト化をした上で、記録と照合する、 PHP標準関数を使う限りユーザー入力をハッシュ&ソルトする必要性はありません。 ハッシュ&ソルトする関数:https://www.php.net/manual/ja/function.password-hash.php 照合する関数:https://www.php.net/manual/ja/function.password-verify.php > ハッシュ&ソルト化の方式がわからなければ、偽ログインをされることはありません BcryptやArgon2系の脆弱性がない、また平文が盗聴されていない限り、またログイン処理や認証に脆弱性がない場合、総当たり攻撃以外に偽ログインする方法はないと思います。 ハッシュ&ソルトの方式はある程度文字列の規則性を見ればわかってしまいます。
miyabi_takatsuk

2021/04/15 05:13

逆にたびたびありがとうございます 汗 私がセキュリティ知識が足りないのが露呈されてしまいましたね・・・。 そのまま引用させてください!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

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

ただいまの回答率
85.46%

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

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

質問する

関連した質問