3
4
テーマ、知りたいこと
Wordpressのphpファイルにデータベースの接続情報を平文で直接記入してサーバーにアップしても大丈夫なのか知りたいです。
背景、状況
会社のブログページのWordpressで、Contactform7で作ったフォームのドロップダウンメニューの選択肢に対して、人数制限をしたいと考えております。
プラグインなども調べたのですが、ピッタリな良いプラグインが見つからず、自作した方がいいのかと思っています。
調べてみたところ、phpファイルでDBにつなぐために、DB情報をphpファイルに平文で書かれたコードがありました。
この場合、もしこの内容が外部から見られた場合、セキュリティ的に心配だと思います。
phpファイルにデータベースの情報を直接記入して、サーバーにアップしても大丈夫なのでしょうか。
どなたかご教授いただきたいです。
よろしくお願いいたします。
回答41件
#1
総合スコア679
投稿2023/05/17 04:21
この場合、もしこの内容が外部から見られた場合、セキュリティ的に心配だと思います。
PHPの中身が見られるという時点で、セキュリティ的には最悪の事態となります。
なので見られることを前提とする考え自体がいかがなものかと個人的には思います。
そもそもWPのDB接続情報はwp-config.phpに平文で記載する仕様だったかと。
パスワード情報は外部ファイル化して、ドキュメントルートよりも上に設置することで、
より安全になるという意見があるかもしれませんが、あまり意味はないように思います。
#2
総合スコア4341
投稿2023/05/17 04:25
まぁ、一概に「大丈夫です」とも「ダメです」とも言えない質問かと思います。
サーバのどこかにはパスワードを置かなければならないですし、たとえパスワードを暗号化したとして、複合化の処理も近い場所におかなければならないので、暗号化に意味があるか？と言われると難しいです。結局はどこかで腹をくくる必要があります。絶対にリスクは背負いたくないというのであれば、もうサーバは公開しない方がいいです。
過去にも似たような議論があるので、そちらも参考にされたらどうでしょう。
https://teratail.com/questions/58910
#3
総合スコア28650
投稿2023/05/17 08:35
ソースの閲覧権限を攻撃者に取得されるというのは最悪ではありません。
最悪は実行権限を取得されることです。
最悪の事態ではないのに諦める理由が「ほんの少し手を抜くため」ではお粗末ではありませんか？
人間、どこでうっかりしたり考えが足りなかったりするかわからないので、環境変数を使ったり、設定ファイルに分離して非公開ディレクトリに置いたりする程度の注意深さくらいは常にあってもいいのではないかと思います。
#4
総合スコア679
投稿2023/05/17 10:02
ソースの閲覧権限を攻撃者に取得されるというのは最悪ではありません。
最悪は実行権限を取得されることです。
質問者はDB情報の機密性を主題としているため、
アプリケーションのサーバの実行権限は本題とは関係ないと思います。
閲覧権限を取得されればDB接続情報が漏れ、
DBに直接アクセス可能となるため、質問の前提上、最悪と記載しました。
まぁ、DBアカウントの接続元アクセス権を指定できる環境ならば、
アプリケーションサーバのIPに限定しておくのは良いと思います。
#5
総合スコア28650
投稿2023/05/17 10:08
編集2023/05/17 10:13セキュリティー上の問題を質問しているので、関係なくないです。
最悪ではないパターンなのに、最悪なので漏れてもいいと断じる意見があったので書きましたが、そういう意味でないのなら真意を明らかにしましょう。
この場合、もしこの内容が外部から見られた場合、セキュリティ的に心配だと思います。
phpファイルにデータベースの情報を直接記入して、サーバーにアップしても大丈夫なのでしょうか。
#6
総合スコア679
投稿2023/05/17 10:44
最悪なので漏れてもいいと断じる意見があったので書きましたが、そういう意味でないのなら真意を明らかにしましょう。
漏れてもいいと断じる意見はしておりません。
パスワードを見られないように対策するという視点で議論すべきではないと意見しました。
phpファイルにデータベースの情報を直接記入して、サーバーにアップしても大丈夫なのでしょうか。
直接書かずにどうやってWPを成立させるというのでしょうか？
必ずどこかには記載しないとDBに接続はできず、
どこに置いたとしても閲覧されればDBにはアクセスされてしまう可能性があります。
閲覧されるという時点で、ミドルウェアレベルの致命的なバグか、PHPアプリのバグ、サーバに侵入される以外ないと考えているため、設置場所については対策になると思っていません。
#7
総合スコア28650
投稿2023/05/17 11:06
編集2023/05/17 11:08閲覧されるという時点で、ミドルウェアレベルの致命的なバグか、PHPアプリのバグ、サーバに侵入される以外ないと考えているため、
バグ以外にもありますが、バグに限って言っても様々な種類があります。
必ずしも実行権限を奪えるものではありません。
なので、閲覧権限を取得されたら全て諦めるという意見には賛同できません。
たとえば、エラーメッセージがどこかに漏れていても、コードを見られるだけで済むではありませんか。
そのコードにパスワードが無ければ奪われなくて済みます。
けして最悪ではありません。
#8
総合スコア679
投稿2023/05/17 11:15
必ずしも実行権限を奪えるものではありません。
なので、閲覧権限を取得されたら全て諦めるという意見には賛同できません。
DBサーバののアカウント情報を閲覧されることと、
APサーバの実行権限の関係性がいまいち理解できていません。
閲覧されてしまえばDBにはアクセスできてしまうことから、
閲覧される前提での議論ではなく、閲覧されにくい状況をつくる視点で議論したいと私は考えています。
もし、閲覧された後にDB情報を守る手法についてお持ちでしたら議論したいとは思います。
#9
総合スコア28650
投稿2023/05/17 11:16
落ち着いてからもう一度最初から読み直せばきっとわかると思いますよ。
わからなければ ChatGPT にでも私の回答を要約してもらえばいいのでは？
#10
総合スコア789
投稿2023/05/17 16:26
よほど具体的に諸々説明しない限り、セキュリティに関して責任を持って大丈夫とか大丈夫でないとか答えることが出来る人はいないと思いますよ。ただ疑問としてはよくある話だとは思うので、以下全ての内容に責任を持たないという前提で個人的な意見を簡単に書いてみました。
総合スコア4341 投稿2023/05/17 04:25 まぁ、一概に「大丈夫です」とも「ダメです」とも言えない質問かと思います。 サーバのどこかにはパスワードを置かなければならないですし、たとえパスワードを暗号化したとして、複合化の処理も近い場所におかなければならないので、暗号化に意味があるか？と言われると難しいです。結局はどこかで腹をくくる必要があります。絶対にリスクは背負いたくないというのであれば、もうサーバは公開しない方がいいです。 過去にも似たような議論があるので、そちらも参考にされたらどうでしょう。
https://teratail.com/questions/58910
phpではどこで必要になるのか？
phpならphpのプロセスが起動してからDBに接続するまでのどこかで、必要になるでしょう。cgiでもfpm(fastcgi)でも、プロセスのライフタイムはWebサーバー起動～終了タイミングより短いので、これはサーバーが起動してからプロセスが起動する度に何度も必要になる情報です。
手動でパスワード認証などの認証が行えるか？
手動で入力するなら、どこにもパスワードなどの情報を置いておく必要がありません。仮にWebサーバーのライフタイムとプロセスとDB接続のライフタイムが完全に同期していて、Webサーバーの起動を手動で実施するなら、人の手による認証(パスワード入力など)が可能になります。しかしphp(cgi/fpm)では先に見たとおり、ライフタイムが同期しておらず、何度も必要になってしまいます。都度人の手による認証を行うのは現実的とは言えません。php以外でも、仮想化とAutoscalingが流行る現環境では、それらの同期は現実的ではなく、人の手による認証は難しいと思います(それ以前にDB接続が切れる度に人の手で起動というのがもう現実的とは思えませんが)。
自動でパスワード認証などの認証を行う場合、どうなるか？
人の手で認証を行えない場合は、実行コードに直書きしても、ファイルに置いても、サーバーから取ってきたとしても、平文にしても、暗号化したものを復号するにしても、それは全てどこかでプログラム的に自動で行えないといけないわけです。プログラム的に自動で認証を行う以上、パスワード認証を行う場合、どこかで平文のパスワードが出現するわけで、コードを読まれればその場所は特定されてしまうでしょう。特定されればパスワードを盗まれるのはもう時間の問題かと思います。
コードが読まれると仮定した場合
実際それは運用チームがうっかり公開しちゃったのでなければ、攻撃者の何らかの攻撃が成功して侵入された状況に等しく、コードどころかプログラムに必要な任意のファイルが読めるわけで、もはや致命的と言えると思います。
この手のリスク(攻撃が成功してしまった後のリスク)を考えた対策は、コストも高く、簡単にコレがいいとか言えないわけですが、選択肢としては、大きく以下の4通りな気がします。
- 平文パスワードが出現する場所や手段を特定されにくくする
- パスワードが盗まれても、そのパスワードで行えることを限定する
- 何らかの手段で攻撃を検出して何らかの対応をする
- パスワード認証以外の認証方法を使用する(SSLクライアント認証など)
この方法は無数にあり、ここでは詳細に検討しません。
コードが読まれないと仮定した場合
コードが読まれない前提であれば、平文パスワードでもサーバーの外部からの攻撃に対するセキュリティ的には問題はないと思います。ただし、例えばそのコードをgithubなどで公開する場合はうっかりミスで漏洩する問題がありますし、本番環境の運用ルールを考える場合、コードを読む権限のある人全員にそのパスワードを知られることは望ましくないことが多いと思います。つまり、内部からの漏洩リスクを抑える目的でこれに一手間加えることはあるということです。
内部からの漏洩リスクを抑えるためのよくある手段
コードに直接とかファイルに書いたりするよりは、運用上の利便性なども考慮して、環境変数などに入れることが多いと推測します。
https://12factor.net/ja/config
個人的な懸念
環境変数は大抵の言語でグローバル変数以上に簡単に一覧し、値を見ることが出来ます。例えばphpだとデバッグ用のコードが残っていて環境変数を出力してたらうっかりパスワードが流出してたみたいな事故はあるかもしれませんね。(ある程度以上の規模のプロジェクトでは流石にないと思いますが。。。)
#11
総合スコア2037
投稿2023/05/17 18:26
論点整理
調べてみたところ、phpファイルでDBにつなぐために、DB情報をphpファイルに平文で書かれたコードがありました。
この場合、もしこの内容が外部から見られた場合、セキュリティ的に心配だと思います。
phpファイルにデータベースの情報を直接記入して、サーバーにアップしても大丈夫なのでしょうか。
この論点に沿って考えてみます。
まず、Webアプリケーション（とりあえずWordPressを前提として）がDBに接続して動作する以上、どこかでその接続情報の設定が必要になります。
WP の場合、デフォルトではそれは wp-config.php で行われるように構成されており、そのデフォルトの配置はWPのルートディレクトリ直下（またはその1つ上のディレクトリ）です。
また、 DB_HOST などの決められた定数として設定されています。
言い換えると、
- 決められた場所にあるファイルに設定する定数に対して、どのようにして設定値を設定することがセキュアなのか
という議論となります。
前提整理
ここまでの議論で、DB接続情報の設定方法として
- wp-config.php に平文で記載
- wp-config.php を変更し、環境変数から取得するように実装
といった方法が示されています。
また、アプリケーションのソース上にDBへの接続情報があり、それが漏えいする場合、どのようなケースがあるか、と考えると、以下の大きく2つが想定されるかと思います。
-
PHP のソースコード自体が読まれる
- サーバー上のソースコード自体が読まれる（侵入、サーバーの設定ミスなど）
- アプリケーションの動作と無関係に、開発環境やソースコード管理上の問題により読まれる
-
PHP のソースコード上の脆弱性を利用して、アプリケーションに設定されている定数（または環境変数）自体を出力させるなどの方法で漏えいする
- プラグインなどを含め自アプリケーションとかかわりなく漏えいする
- デバッグ用コードの削除忘れなどにより漏えいする（ var_dump() や JS向けの console.log() 、xdebug など、様々なデバッグ支援ツールがあるのでここでは個別には考えません）
考察
上記の 1. であれ 2. であれ、実はそれ以前のどこまでのセキュリティ設計を前提とするかに直結する問題です。
そもそもサーバーに侵入できている場合
サーバーに侵入し放題であればどこに設定されていようと、どのようにアプリが作られていようと大きな問題はなく設定ファイルを読めばいい（どこにどう設定されているかをたどればいい) ため、「接続情報の設定方法」を議論する意味がなくなります。
もちろん、平文か環境変数か、他の何かかもほとんど無駄な議論となります（そのサーバーからアクセスできることは担保できているので、接続情報を見つけさえすればいい）。
※余談ですがWPの場合、wp-config.php に管理画面から更新をかけるときに使われるFTPアップロードのアカウント情報などもあるため、任意のファイルを設置することも容易にできることとなります。
なので、このケースを想定してこの議論を続ける意味はないので、除外します。
サーバー設定（主にhttpd / php )のミスを想定する場合
この場合は、意図せずソースコードがプレインテキストとして表示される、などの「事故」を想定することになります。
どこまでの事故かという想定が必要となりますが、ありそうなのは
- DocumentRoot 以下のディレクトリの .php ファイルをPHPを解釈せずにテキストとして表示している
といったものになるでしょう。
その想定であれば、
- wp-config.php に平文で書かない
- wp-conifig.php の配置をデフォルトから変更する
といった対策は、一定の効果を持ちます。
この場合、
- 環境変数などを利用して設定するなど、アプリケーション外から情報を取得できる方法を利用し、動的に設定するように改修する
- wp-config.php の置き場所をDocumentRoot 外（httpdでアクセスできない場所）に配置し、WP直下の wp-config.php ファイルをカスタマイズしその移動したファイルを
require_onceなどで読み込むようにする。
といった対策は有効と言えるでしょう。
アプリケーションの設計ミスを想定する場合
デバッグ用コードを残しっぱなしなどのケースを想定します。
この場合の防御は困難で、デバッグ用コードを入れる時点で実環境で動かないような工夫をするなどのそれ以前の対策が必要そうです。
このケースが悪質性高いのは、例えば接続情報を環境変数などを利用して平文以外で設定したとしても、アプリケーションの動作過程のどこかに、例えば var_dump( DB_HOST ); があればそこで出力されてしまう、ということになります。
※WPのアーキテクチャ上、動作するには決まった定数名の設定値が使われるため、その設定方法が何であれアプリケーション上の出力は容易。
このケースに対するサーバー設定上の対策等は困難で、しいて対策としてあげるのであれば、デプロイ時のテストをしっかりやる、といった「それ以前」の話になると思います。
そのため、このケースも「平文かどうか」という論点と無関係となるため、議論から除外できます。
DBへのアクセス経路（ネットワーク的な設計）の問題を想定する場合
例えば、DBの接続情報が漏えいしたとして、DBへの接続がIPアドレスにより制限されていた場合、DBに接続するためにはそのIPアドレスのサーバー上でのDB接続操作が必要となります（手法は様々考えられますが）。
逆に、DBがグローバルIPアドレスが設定されておりどこからでもアクセス可能で、かつDB接続情報がIPアドレスによる制限のないものだった場合（ user@% とか）、DBの接続情報の漏えい自体がDBのデータ漏えいと同義と言える状況となります。
これもまた、「平文かどうか」という論点と無関係のレイヤーのセキュリティ課題となるため、議論から除外できます。
どういったリスクを想定するか
ということで、「平文で設定することがリスクか」という議論の前提で考慮すべきなのは、「サーバー設定（主にhttpd / php )のミスを想定する場合」が中心となります。
このポイントへの対策、という1点において考えると、
- DocumentRoot 以下（要するに公開ディレクトリ配下）に平文で接続情報を置くのはリスクが高い
という認識とすることができるかもしれません。
漏えいしたとして、何が問題なのか
逆に言うと、上記の想定で除外した側のパターンについて、平文で設定するかどうかと無関係に、「どのリスクを問題とするか」「どのリスクを許容するか」という、セキュリティレベルの検討が必要になります。
逆に言うと、何は問題がないという前提とするか、になります。
- Aというサーバーからだけ接続できる接続情報が漏えいする
- しかし、Aというサーバー上での操作はどうやっても不可能
という想定なら、その接続情報が漏えいすることは何も問題じゃない、ということになります。
（一般に「Aというサーバー上での操作はどうやっても不可能」が担保できないので問題となるわけですが）
こういった想定ができるなら、上記で検討したそれぞれのケースはすべて想定する必要がないことになり、「大丈夫」という回答になるでしょう。
まとめ
で、最初の議題に回答しようとすると「想定する前提によって異なるが、問題があると考えた場合もサーバー設定のミスに対する対策を踏まえていれば平文かどうか自体が大きな問題とはならない」といったものになります。
このように「セキュリティ上の問題」というのは、単独のポイントで議論する意味はほとんどなく、
- リスク評価
- リスク想定
を多面的に考え、様々な前提のもとに「これでいいか」を検討することになります。
DBに接続するWebアプリケーションである以上、いずれにせよ何らかの形でアプリケーションの実行環境下には設定情報があり、それを利用してアプリケーションは動作するので、単純に「ソースコード上に平文であっていいのか」だけで議論せず、実行環境全体をどう守るか、そのためにはどうする必要があるか、ということを論点とする必要があります。
こういった前提の下、OSSとしてのWPは wp-config.php に平文で設定するように設計されています。
それが必ずしも危険に直結しているわけではない想定のためです（その安全を守るための対策はソースコードの書き方ではなく環境の整え方にある）。
そもそもOSSですので、他の方法で設定したければカスタマイズすればいい、ということでもあります。
書きなぐったため整理しているようでぐちゃぐちゃですが、ここまでの議論の中でも議論の想定に少し違和感があったので、書いてみました。
#12
皆さんご教授いただき、ありがとうございます。
今回、社内に中々相談できる人がおらずこちらに投稿をさせていただきました。
恥ずかしながら、サーバーやphpファイルなどについてわかっておらず、
主にこのようなことであるのかなと考えました。（もし勘違いなどしておりましたら、ご指摘いただきたいです。)
・webアプリケーションを使っている以上、データベースに接続するためには、どこかに必ずIDやパスワードを記載する必要があるということ。
・パスワードを見られることを防ぐために環境変数などを多くの場合使ったりしていること。
・平文のパスワードを見られる前にサーバーのセキュリティを強化しておく必要があること。
また、このことを踏まえてお聞きしたいことがあるのですが、
phpファイルはサーバーに侵入されない場合は見られることがないという風に考えてもいいのでしょうか。
後、議題とは全然関係ないことなのですが、
皆さんはこのような情報交換などをteratailの他にどのような所でされておりますか？
#13
総合スコア28650
投稿2023/05/17 23:05
phpファイルはサーバーに侵入されない場合は見られることがないという風に考えてもいいのでしょうか。
そう主張している人がいるように見えますが、侵入というのを実行権限の奪取と言うなら、そんなことはありません。
#14
総合スコア789
投稿2023/05/18 01:32
総合スコア8
投稿2023/05/17 22:13
皆さんご教授いただき、ありがとうございます。
今回、社内に中々相談できる人がおらずこちらに投稿をさせていただきました。
恥ずかしながら、サーバーやphpファイルなどについてわかっておらず、
主にこのようなことであるのかなと考えました。（もし勘違いなどしておりましたら、ご指摘いただきたいです。)
・webアプリケーションを使っている以上、データベースに接続するためには、どこかに必ずIDやパスワードを記載する必要があるということ。
・パスワードを見られることを防ぐために環境変数などを多くの場合使ったりしていること。
・平文のパスワードを見られる前にサーバーのセキュリティを強化しておく必要があること。
また、このことを踏まえてお聞きしたいことがあるのですが、
phpファイルはサーバーに侵入されない場合は見られることがないという風に考えてもいいのでしょうか。
後、議題とは全然関係ないことなのですが、
皆さんはこのような情報交換などをteratailの他にどのような所でされておりますか？
phpファイルはサーバーに侵入されない場合は見られることがないという風に考えてもいいのでしょうか。
そこは自分で判断してください。最初に書いたように、「よほど具体的に諸々説明しない限り、セキュリティに関して責任を持って大丈夫とか大丈夫でないとか答えることが出来る人はいないと思います」。
#15
総合スコア2037
投稿2023/05/18 06:32
自分のサーバー環境で問題ないか、といったそこまで具体的なことを聞いているわけじゃないんじゃないでしょうか。
一般論として「そこだけでいいの？」という疑問であって、回答は「それ以外も状況によって考えられるよ」「こんな例があるよ」が知りたいのでは。
後、議題とは全然関係ないことなのですが、
皆さんはこのような情報交換などをteratailの他にどのような所でされておりますか？
ちなみに私のこの質問への回答は「 connpass.com などでコミュニティを見つけて参加して、その中での会話とか」ですが、こういった質問が同時に出てくることからも、そういった一般的な議論・相談できる環境がなくて困っている、というように見えるので、いろいろな情報を出しあえるといいんじゃないかと。
総合スコア8 投稿2023/05/17 22:13 皆さんご教授いただき、ありがとうございます。 恥ずかしながら、サーバーやphpファイルなどについてわかっておらず、 また、このことを踏まえてお聞きしたいことがあるのですが、 後、議題とは全然関係ないことなのですが、
今回、社内に中々相談できる人がおらずこちらに投稿をさせていただきました。
主にこのようなことであるのかなと考えました。（もし勘違いなどしておりましたら、ご指摘いただきたいです。)
・webアプリケーションを使っている以上、データベースに接続するためには、どこかに必ずIDやパスワードを記載する必要があるということ。
・パスワードを見られることを防ぐために環境変数などを多くの場合使ったりしていること。
・平文のパスワードを見られる前にサーバーのセキュリティを強化しておく必要があること。
phpファイルはサーバーに侵入されない場合は見られることがないという風に考えてもいいのでしょうか。
皆さんはこのような情報交換などをteratailの他にどのような所でされておりますか？
ついでに残りの部分です。
・webアプリケーションを使っている以上、データベースに接続するためには、どこかに必ずIDやパスワードを記載する必要があるということ。
概ねYes
・パスワードを見られることを防ぐために環境変数などを多くの場合使ったりしていること。
概ねYes、ただし必ずしも「多くの場合」かというとそうではないかも。
ファイルの配置、パーミッションの設定の仕方でカバーすることもある。
・平文のパスワードを見られる前にサーバーのセキュリティを強化しておく必要があること。
前に、というより、全方面的に強化しないと、脆弱な一点からすべて崩れる、というイメージです。
#16
総合スコア789
投稿2023/05/18 06:44
総合スコア2037
投稿2023/05/18 06:32
自分のサーバー環境で問題ないか、といったそこまで具体的なことを聞いているわけじゃないんじゃないでしょうか。
一般論として「そこだけでいいの？」という疑問であって、回答は「それ以外も状況によって考えられるよ」「こんな例があるよ」が知りたいのでは。
後、議題とは全然関係ないことなのですが、
皆さんはこのような情報交換などをteratailの他にどのような所でされておりますか？
ちなみに私のこの質問への回答は「 connpass.com などでコミュニティを見つけて参加して、その中での会話とか」ですが、こういった質問が同時に出てくることからも、そういった一般的な議論・相談できる環境がなくて困っている、というように見えるので、いろいろな情報を出しあえるといいんじゃないかと。
#12
ついでに残りの部分です。
・webアプリケーションを使っている以上、データベースに接続するためには、どこかに必ずIDやパスワードを記載する必要があるということ。
概ねYes
・パスワードを見られることを防ぐために環境変数などを多くの場合使ったりしていること。
概ねYes、ただし必ずしも「多くの場合」かというとそうではないかも。
ファイルの配置、パーミッションの設定の仕方でカバーすることもある。
・平文のパスワードを見られる前にサーバーのセキュリティを強化しておく必要があること。
前に、というより、全方面的に強化しないと、脆弱な一点からすべて崩れる、というイメージです。
自然言語(日本語)の解釈は基本的に人それぞれなので、無責任に話すのでなければ、原則解釈の余地がない事実ベースでないといけないと思います。
特にセキュリティなど「問題が起きてからの被害が深刻になる可能性が高いもの」は、質問者さんやあなたの発言意図がどうあろうと、あまり無責任な物言いが出来ません。この内容を読む人が質問者さんだけとは限らないからです。
#17
総合スコア2037
投稿2023/05/18 07:55
自然言語(日本語)の解釈は基本的に人それぞれなので、無責任に話すのでなければ、原則解釈の余地がない事実ベースでないといけないと思います。
特にセキュリティなど「問題が起きてからの被害が深刻になる可能性が高いもの」は、質問者さんやあなたの発言意図がどうあろうと、あまり無責任な物言いが出来ません。この内容を読む人が質問者さんだけとは限らないからです。
というスタンスということは承知いたしました。
そういう考え方もありますね。参考になります。
そもそも意見交換なので、様々な意見が出てくること自体がいいことだと思いますので、それはそれでいいことと思います。
「セキュリティ的に大丈夫でしょうか」という質問が良くない、というのは同意できますし、それに対して「大丈夫」と回答するのもよくない、というのも同意できます。
ただ、私は、まっすぐに正解だけでなく、「こういう可能性がある」は可能性の範囲の事例として共有されるべき（コミュニティの価値はそういうところにもある）と思っているので
一般論として「そこだけでいいの？」という疑問であって、回答は「それ以外も状況によって考えられるよ」「こんな例があるよ」が知りたいのでは。
と書きました。
「こういうケースもあるので大丈夫とは言えない」の情報は共有されるべきじゃないかなと。
前提がそろわない議論なので、無限に拡散する余地が出てきてしまいますが、意見交換ならそれでいいんじゃないでしょうか。
大事なのは「こういう前提であれば、こういうリスクが残る」の情報共有かと思いました。
※質問者さん、議論を変な方向に発散させてしまってすみません。
#18
総合スコア28650
投稿2023/05/18 09:11
編集2023/05/18 09:17PHP のソースコードに DB のパスワードを書いていいかどうかという一般論だと思いますよ。
利便性とセキュリティーはトレードオフの関係にあることが多いですから、ソース中に書かなければならないと言える状況がもしかしたらあるかもしれませんが、たちまち思い当たりません。
ソースコードをうっかり GitHub で公開したり、サーバーの設定をうっかりミスしたりということが数年経って担当者が変わっても絶対にないと言えるくらいきっちり管理されてるんでしょうか？
#19
総合スコア789
投稿2023/05/18 09:23
編集2023/05/18 17:06では意見として、、、
100%完全に再現できる環境とコードでもない限り、正直セキュリティなんて検討する価値もない、と思っています。アホほど具体的に材料を揃えて「意見を交換」したとしても発散はやむなし、な話だと思いますよ。
質問者にそこまでの知識は必要ないですが、具体的材料すら用意できない状態で、結論だけを問う質問をしてるのに「可能性の範囲の事例として共有される」なんて夢物語ですよ。
砂漠の砂に蛇口をつけたって、そこから水が出るわけではありません。
攻撃的と言われていますが、ただの意見とその説明でありどの辺が攻撃的で誰に攻撃してることになっているのかすらよく分かりません。具体的に指摘されればそこは修正しますので遠慮なく。
#20
総合スコア28650
投稿2023/05/18 09:26
一般的なノウハウを問うているだけの質問に個別の要素が必要だというなら、どの条件が必要になるかを書けばいいのでは？
ソース中に書いていい理由なんてそんなにたくさんないでしょ。
#21
総合スコア789
投稿2023/05/18 10:01
編集2023/05/18 17:07#22
総合スコア28650
投稿2023/05/18 10:04
回答者の teratail 離れが深刻な事態を引き起こしているようですね。
私が書く必要はありません。
なぜなら私はこの質問は一般論でノウハウを聞くだけのものと認識しているからです。
個別の条件が必要と主張するなら、そんな条件はそれほど多くないと思われるので、それを書けば有効な回答になると思いますし、一つも書けないのであれば、たとえ個別の条件が書いてあったとしても、あなたには判断できないでしょう。
#23
#24
総合スコア28650
投稿2023/05/18 10:14
あなたが書かなければいけないと書いているんですよ。
#25
総合スコア28650
投稿2023/05/18 10:21
Git で管理されることの多いソースコードにパスワードを書くことがアンチパターンであるかどうかを問う質問で、「状況次第」と回答するのであれば、その「状況」を例示しなければ回答として無意味とは思いませんか？
#27
総合スコア28650
投稿2023/05/18 10:23
編集2023/05/18 10:23思わないと。
つまりあなたの回答は無意味です。
#28
総合スコア789
投稿2023/05/18 10:25
総合スコア28650
投稿2023/05/18 10:21
Git で管理されることの多いソースコードにパスワードを書くことがアンチパターンであるかどうかを問う質問で、「状況次第」と回答するのであれば、その「状況」を例示しなければ回答として無意味とは思いませんか？
私の意見はすでに
総合スコア789
投稿2023/05/17 16:26
よほど具体的に諸々説明しない限り、セキュリティに関して責任を持って大丈夫とか大丈夫でないとか答えることが出来る人はいないと思いますよ。ただ疑問としてはよくある話だとは思うので、以下全ての内容に責任を持たないという前提で個人的な意見を簡単に書いてみました。
#2 のリンク先に書かれているとおり、DBにアクセスするならパスワードのような認証情報はどこかで必要になります。
phpではどこで必要になるのか？
phpならphpのプロセスが起動してからDBに接続するまでのどこかで、必要になるでしょう。cgiでもfpm(fastcgi)でも、プロセスのライフタイムはWebサーバー起動～終了タイミングより短いので、これはサーバーが起動してからプロセスが起動する度に何度も必要になる情報です。
手動でパスワード認証などの認証が行えるか？
手動で入力するなら、どこにもパスワードなどの情報を置いておく必要がありません。仮にWebサーバーのライフタイムとプロセスとDB接続のライフタイムが完全に同期していて、Webサーバーの起動を手動で実施するなら、人の手による認証(パスワード入力など)が可能になります。しかしphp(cgi/fpm)では先に見たとおり、ライフタイムが同期しておらず、何度も必要になってしまいます。都度人の手による認証を行うのは現実的とは言えません。php以外でも、仮想化とAutoscalingが流行る現環境では、それらの同期は現実的ではなく、人の手による認証は難しいと思います(それ以前にDB接続が切れる度に人の手で起動というのがもう現実的とは思えませんが)。
自動でパスワード認証などの認証を行う場合、どうなるか？
人の手で認証を行えない場合は、実行コードに直書きしても、ファイルに置いても、サーバーから取ってきたとしても、平文にしても、暗号化したものを復号するにしても、それは全てどこかでプログラム的に自動で行えないといけないわけです。プログラム的に自動で認証を行う以上、パスワード認証を行う場合、どこかで平文のパスワードが出現するわけで、コードを読まれればその場所は特定されてしまうでしょう。特定されればパスワードを盗まれるのはもう時間の問題かと思います。
コードが読まれると仮定した場合
実際それは運用チームがうっかり公開しちゃったのでなければ、攻撃者の何らかの攻撃が成功して侵入された状況に等しく、コードどころかプログラムに必要な任意のファイルが読めるわけで、もはや致命的と言えると思います。
この手のリスク(攻撃が成功してしまった後のリスク)を考えた対策は、コストも高く、簡単にコレがいいとか言えないわけですが、選択肢としては、大きく以下の4通りな気がします。
- 平文パスワードが出現する場所や手段を特定されにくくする
- パスワードが盗まれても、そのパスワードで行えることを限定する
- 何らかの手段で攻撃を検出して何らかの対応をする
- パスワード認証以外の認証方法を使用する(SSLクライアント認証など)
この方法は無数にあり、ここでは詳細に検討しません。
コードが読まれないと仮定した場合
コードが読まれない前提であれば、平文パスワードでもサーバーの外部からの攻撃に対するセキュリティ的には問題はないと思います。ただし、例えばそのコードをgithubなどで公開する場合はうっかりミスで漏洩する問題がありますし、本番環境の運用ルールを考える場合、コードを読む権限のある人全員にそのパスワードを知られることは望ましくないことが多いと思います。つまり、内部からの漏洩リスクを抑える目的でこれに一手間加えることはあるということです。
内部からの漏洩リスクを抑えるためのよくある手段
コードに直接とかファイルに書いたりするよりは、運用上の利便性なども考慮して、環境変数などに入れることが多いと推測します。
https://12factor.net/ja/config
個人的な懸念
環境変数は大抵の言語でグローバル変数以上に簡単に一覧し、値を見ることが出来ます。例えばphpだとデバッグ用のコードが残っていて環境変数を出力してたらうっかりパスワードが流出してたみたいな事故はあるかもしれませんね。(ある程度以上の規模のプロジェクトでは流石にないと思いますが。。。)
不明点があるなら引用して具体的にお願いします。
#30
総合スコア28650
投稿2023/05/18 10:33
不明点はありません。
私が何を言っているのかわからないのであれば、繰り返しましょうか？
#32
総合スコア28650
投稿2023/05/18 10:42
編集2023/05/18 11:22まだわからないようなので、とりあえずこれを読んでみてください。
https://secbase.jp/report/20211222_protect-your-code-repository
個別の事例がなくとも回答が可能なことがわかると思います。
「まとめ」に
今回は英国NCSCが公開している、ソースコードリポジトリ保護のためのガイドラインに基づいて、必要となるアクションについて、その一部をご紹介いたしました。
と書かれていますが、NCSC(https://www.ncsc.gov.uk/) は御覧の通り gov.uk ドメイン、つまり英国政府機関です。
#33
総合スコア789
投稿2023/05/18 11:44
編集2023/05/18 14:03総合スコア28650
投稿2023/05/18 10:42
編集2023/05/18 11:22
まだわからないようなので、とりあえずこれを読んでみてください。
https://secbase.jp/report/20211222_protect-your-code-repository
個別の事例がなくとも回答が可能なことがわかると思います。
「まとめ」に
今回は英国NCSCが公開している、ソースコードリポジトリ保護のためのガイドラインに基づいて、必要となるアクションについて、その一部をご紹介いたしました。
と書かれていますが、NCSC(https://www.ncsc.gov.uk/) は御覧の通り gov.uk ドメイン、つまり英国政府機関です。
読みましたが、だから何？という感想しかありません。私が挙げてるThe Twelve-Factor Appの方が一般的だし、「ソースコードリポジトリ保護のためのガイドライン」という点にも？？？です。
3度目ですが、話終わりでいいですよね。
攻撃的と言われていますが、ただの感想含む説明でありどの辺が攻撃的で誰に攻撃してることになっているのかすらよく分かりません。具体的に指摘されればそこは修正しますので遠慮なく。
#34
総合スコア28650
投稿2023/05/18 11:45
編集2023/05/18 11:50まあこれでわからないのなら話が通じないので仕方ないですね。
あなたはソースコードにパスワードを生で埋め込んでコミットする方法をこれからも続けていいですよ。
#35
総合スコア2037
投稿2023/05/18 17:32
総合スコア789
投稿2023/05/18 09:23
編集2023/05/18 17:06
では意見として、、、
100%完全に再現できる環境とコードでもない限り、正直セキュリティなんて検討する価値もない、と思っています。アホほど具体的に材料を揃えて「意見を交換」したとしても発散はやむなし、な話だと思いますよ。
質問者にそこまでの知識は必要ないですが、具体的材料すら用意できない状態で、結論だけを問う質問をしてるのに「可能性の範囲の事例として共有される」なんて夢物語ですよ。
砂漠の砂に蛇口をつけたって、そこから水が出るわけではありません。
攻撃的と言われていますが、ただの意見とその説明でありどの辺が攻撃的で誰に攻撃してることになっているのかすらよく分かりません。具体的に指摘されればそこは修正しますので遠慮なく。
総合スコア28650
投稿2023/05/18 10:04
回答者の teratail 離れが深刻な事態を引き起こしているようですね。
私が書く必要はありません。
なぜなら私はこの質問は一般論でノウハウを聞くだけのものと認識しているからです。
個別の条件が必要と主張するなら、そんな条件はそれほど多くないと思われるので、それを書けば有効な回答になると思いますし、一つも書けないのであれば、たとえ個別の条件が書いてあったとしても、あなたには判断できないでしょう。
行動規範 のリンクを置いておきますね。
特に「容認できない行為」をご覧いただければと思います。
質問者さんへ
本来非常に有意義な問題意識を提起されているので、このようなスレッドの状況になってしまい残念ですね。
疑問を持たず、ただ手順として設定するよりもよほど有意義な思考だと思います。
実際、全く問題ない、といえるものでもありませんし。
総合スコア28650
投稿2023/05/18 09:11
編集2023/05/18 09:17
PHP のソースコードに DB のパスワードを書いていいかどうかという一般論だと思いますよ。
利便性とセキュリティーはトレードオフの関係にあることが多いですから、ソース中に書かなければならないと言える状況がもしかしたらあるかもしれませんが、たちまち思い当たりません。
ソースコードをうっかり GitHub で公開したり、サーバーの設定をうっかりミスしたりということが数年経って担当者が変わっても絶対にないと言えるくらいきっちり管理されてるんでしょうか？
ひとまずは あたりまでをご覧いただきながら、もう少したら正常化されると思いますので、改めて意見交換や不明点、疑問点などの議論が続けられるといいですね。
#36
総合スコア789
投稿2023/05/18 19:18
総合スコア2037
投稿2023/05/18 17:32
#19#21#22 etc.
行動規範 のリンクを置いておきますね。
特に「容認できない行為」をご覧いただければと思います。
質問者さんへ
本来非常に有意義な問題意識を提起されているので、このようなスレッドの状況になってしまい残念ですね。
疑問を持たず、ただ手順として設定するよりもよほど有意義な思考だと思います。
実際、全く問題ない、といえるものでもありませんし。
#18 あたりまでについては本題に直結する話題ですが、それ以降は本来このスレッドでされるべきコミュニケーションではないように見えます。
ひとまずは#18 あたりまでをご覧いただきながら、もう少したら正常化されると思いますので、改めて意見交換や不明点、疑問点などの議論が続けられるといいですね。
どれにも該当していませんよ
総合スコア789 投稿2023/05/18 09:23 編集2023/05/18 17:06 では意見として、、、 100%完全に再現できる環境とコードでもない限り、正直セキュリティなんて検討する価値もない、と思っています。アホほど具体的に材料を揃えて「意見を交換」したとしても発散はやむなし、な話だと思いますよ。 砂漠の砂に蛇口をつけたって、そこから水が出るわけではありません。 攻撃的と言われていますが、ただの意見とその説明でありどの辺が攻撃的で誰に攻撃してることになっているのかすらよく分かりません。具体的に指摘されればそこは修正しますので遠慮なく。 総合スコア2037 投稿2023/05/18 07:55 自然言語(日本語)の解釈は基本的に人それぞれなので、無責任に話すのでなければ、原則解釈の余地がない事実ベースでないといけないと思います。 というスタンスということは承知いたしました。 「セキュリティ的に大丈夫でしょうか」という質問が良くない、というのは同意できますし、それに対して「大丈夫」と回答するのもよくない、というのも同意できます。 一般論として「そこだけでいいの？」という疑問であって、回答は「それ以外も状況によって考えられるよ」「こんな例があるよ」が知りたいのでは。 と書きました。 「こういうケースもあるので大丈夫とは言えない」の情報は共有されるべきじゃないかなと。 ※質問者さん、議論を変な方向に発散させてしまってすみません。
質問者にそこまでの知識は必要ないですが、具体的材料すら用意できない状態で、結論だけを問う質問をしてるのに「可能性の範囲の事例として共有される」なんて夢物語ですよ。
特にセキュリティなど「問題が起きてからの被害が深刻になる可能性が高いもの」は、質問者さんやあなたの発言意図がどうあろうと、あまり無責任な物言いが出来ません。この内容を読む人が質問者さんだけとは限らないからです。
そういう考え方もありますね。参考になります。
そもそも意見交換なので、様々な意見が出てくること自体がいいことだと思いますので、それはそれでいいことと思います。
ただ、私は、まっすぐに正解だけでなく、「こういう可能性がある」は可能性の範囲の事例として共有されるべき（コミュニティの価値はそういうところにもある）と思っているので
前提がそろわない議論なので、無限に拡散する余地が出てきてしまいますが、意見交換ならそれでいいんじゃないでしょうか。
大事なのは「こういう前提であれば、こういうリスクが残る」の情報共有かと思いました。
個人的にはから意味不明な粘着で無関係な話が続いており、どちらかというと私が諌めたつもりなんですけど・・・
まあまだ「意見交換や不明点、疑問点などの議論」などしたいことがあるならそういう場所なので、自由にしてください。私はその邪魔はしていないつもりです。
#37
総合スコア39
投稿2023/05/23 12:35
phpソースをブラウザから閲覧することは出来ません。.phpファイルにアクセスしてソースを表示することは出来ますが、それはphpプログラムが作成したhtmlソースです。しかし、元のphpファイルはサーバーだけにあるとは限りません。開発中のローカルPCやバックアップのメディアにあるかもしれません。重要な情報はコメントも含めて直接記述しないのが賢明です。
#38
総合スコア40
投稿2023/05/23 13:12
PHPに関しては詳しく把握している訳ではないのですが、セキュリティ要件に沿って実装するべきです。
特にセキュリティ要件が定まっていないのなら、最低限の対策としてPHPのソースが漏れないようにする対策だけで十分だと思われます。
後は漏れてもいいようにdbのネットワーク設計を堅牢にするだけで充分ですね。
その他諸々責任が面倒ならインフラ周りは他社に丸投げするのもいいと思われます。
セキュリティのアプローチは製造物だけではなくそれを取り巻くインフラを含めて考えるのが一般的だと思われます。
一部コミット云々書いている方々もいますが、ぶっちゃけネットワークインフラしっかり構築していたらdbのパスワード漏れたくらいでは特に影響は出ません。※1
堅牢なネットワークだと相手のネットワークに侵入しないといけないのでプログラム上の対策は特に意味をなしません。(環境変数に設定するなど)
平文でパスワードハードコーディングしてるから不適切と言うわけではないため、属しているプロジェクトのセキュリティ要件や規約をしっかり読んで徹底しましょう。
※1 技術的には問題ないけれど、社会的には問題になるので気をつけてください。
結論:特にサーバなどのセキュリティに明るくない場合、環境変数を参照するように記述するのが無難だと思われる。
#39
みなさん
色々なご意見をいただき、ありがとうございます。
元々の質問がふんわりしていたせいで、混乱させてしまいすみません。
総合スコア2037
投稿2023/05/17 18:26
論点整理
調べてみたところ、phpファイルでDBにつなぐために、DB情報をphpファイルに平文で書かれたコードがありました。
この場合、もしこの内容が外部から見られた場合、セキュリティ的に心配だと思います。
phpファイルにデータベースの情報を直接記入して、サーバーにアップしても大丈夫なのでしょうか。
この論点に沿って考えてみます。
まず、Webアプリケーション（とりあえずWordPressを前提として）がDBに接続して動作する以上、どこかでその接続情報の設定が必要になります。
WP の場合、デフォルトではそれは wp-config.php で行われるように構成されており、そのデフォルトの配置はWPのルートディレクトリ直下（またはその1つ上のディレクトリ）です。
また、 DB_HOST などの決められた定数として設定されています。
言い換えると、
- 決められた場所にあるファイルに設定する定数に対して、どのようにして設定値を設定することがセキュアなのか
という議論となります。
前提整理
ここまでの議論で、DB接続情報の設定方法として
- wp-config.php に平文で記載
- wp-config.php を変更し、環境変数から取得するように実装
といった方法が示されています。
また、アプリケーションのソース上にDBへの接続情報があり、それが漏えいする場合、どのようなケースがあるか、と考えると、以下の大きく2つが想定されるかと思います。
-
PHP のソースコード自体が読まれる
- サーバー上のソースコード自体が読まれる（侵入、サーバーの設定ミスなど）
- アプリケーションの動作と無関係に、開発環境やソースコード管理上の問題により読まれる
-
PHP のソースコード上の脆弱性を利用して、アプリケーションに設定されている定数（または環境変数）自体を出力させるなどの方法で漏えいする
- プラグインなどを含め自アプリケーションとかかわりなく漏えいする
- デバッグ用コードの削除忘れなどにより漏えいする（ var_dump() や JS向けの console.log() 、xdebug など、様々なデバッグ支援ツールがあるのでここでは個別には考えません）
考察
上記の 1. であれ 2. であれ、実はそれ以前のどこまでのセキュリティ設計を前提とするかに直結する問題です。
そもそもサーバーに侵入できている場合
サーバーに侵入し放題であればどこに設定されていようと、どのようにアプリが作られていようと大きな問題はなく設定ファイルを読めばいい（どこにどう設定されているかをたどればいい) ため、「接続情報の設定方法」を議論する意味がなくなります。
もちろん、平文か環境変数か、他の何かかもほとんど無駄な議論となります（そのサーバーからアクセスできることは担保できているので、接続情報を見つけさえすればいい）。
※余談ですがWPの場合、wp-config.php に管理画面から更新をかけるときに使われるFTPアップロードのアカウント情報などもあるため、任意のファイルを設置することも容易にできることとなります。
なので、このケースを想定してこの議論を続ける意味はないので、除外します。
サーバー設定（主にhttpd / php )のミスを想定する場合
この場合は、意図せずソースコードがプレインテキストとして表示される、などの「事故」を想定することになります。
どこまでの事故かという想定が必要となりますが、ありそうなのは
- DocumentRoot 以下のディレクトリの .php ファイルをPHPを解釈せずにテキストとして表示している
といったものになるでしょう。
その想定であれば、
- wp-config.php に平文で書かない
- wp-conifig.php の配置をデフォルトから変更する
といった対策は、一定の効果を持ちます。
この場合、
- 環境変数などを利用して設定するなど、アプリケーション外から情報を取得できる方法を利用し、動的に設定するように改修する
- wp-config.php の置き場所をDocumentRoot 外（httpdでアクセスできない場所）に配置し、WP直下の wp-config.php ファイルをカスタマイズしその移動したファイルを
require_onceなどで読み込むようにする。
といった対策は有効と言えるでしょう。
アプリケーションの設計ミスを想定する場合
デバッグ用コードを残しっぱなしなどのケースを想定します。
この場合の防御は困難で、デバッグ用コードを入れる時点で実環境で動かないような工夫をするなどのそれ以前の対策が必要そうです。
このケースが悪質性高いのは、例えば接続情報を環境変数などを利用して平文以外で設定したとしても、アプリケーションの動作過程のどこかに、例えば var_dump( DB_HOST ); があればそこで出力されてしまう、ということになります。
※WPのアーキテクチャ上、動作するには決まった定数名の設定値が使われるため、その設定方法が何であれアプリケーション上の出力は容易。
このケースに対するサーバー設定上の対策等は困難で、しいて対策としてあげるのであれば、デプロイ時のテストをしっかりやる、といった「それ以前」の話になると思います。
そのため、このケースも「平文かどうか」という論点と無関係となるため、議論から除外できます。
DBへのアクセス経路（ネットワーク的な設計）の問題を想定する場合
例えば、DBの接続情報が漏えいしたとして、DBへの接続がIPアドレスにより制限されていた場合、DBに接続するためにはそのIPアドレスのサーバー上でのDB接続操作が必要となります（手法は様々考えられますが）。
逆に、DBがグローバルIPアドレスが設定されておりどこからでもアクセス可能で、かつDB接続情報がIPアドレスによる制限のないものだった場合（ user@% とか）、DBの接続情報の漏えい自体がDBのデータ漏えいと同義と言える状況となります。
これもまた、「平文かどうか」という論点と無関係のレイヤーのセキュリティ課題となるため、議論から除外できます。
どういったリスクを想定するか
ということで、「平文で設定することがリスクか」という議論の前提で考慮すべきなのは、「サーバー設定（主にhttpd / php )のミスを想定する場合」が中心となります。
このポイントへの対策、という1点において考えると、
- DocumentRoot 以下（要するに公開ディレクトリ配下）に平文で接続情報を置くのはリスクが高い
という認識とすることができるかもしれません。
漏えいしたとして、何が問題なのか
逆に言うと、上記の想定で除外した側のパターンについて、平文で設定するかどうかと無関係に、「どのリスクを問題とするか」「どのリスクを許容するか」という、セキュリティレベルの検討が必要になります。
逆に言うと、何は問題がないという前提とするか、になります。
- Aというサーバーからだけ接続できる接続情報が漏えいする
- しかし、Aというサーバー上での操作はどうやっても不可能
という想定なら、その接続情報が漏えいすることは何も問題じゃない、ということになります。
（一般に「Aというサーバー上での操作はどうやっても不可能」が担保できないので問題となるわけですが）
こういった想定ができるなら、上記で検討したそれぞれのケースはすべて想定する必要がないことになり、「大丈夫」という回答になるでしょう。
まとめ
で、最初の議題に回答しようとすると「想定する前提によって異なるが、問題があると考えた場合もサーバー設定のミスに対する対策を踏まえていれば平文かどうか自体が大きな問題とはならない」といったものになります。
このように「セキュリティ上の問題」というのは、単独のポイントで議論する意味はほとんどなく、
- リスク評価
- リスク想定
を多面的に考え、様々な前提のもとに「これでいいか」を検討することになります。
DBに接続するWebアプリケーションである以上、いずれにせよ何らかの形でアプリケーションの実行環境下には設定情報があり、それを利用してアプリケーションは動作するので、単純に「ソースコード上に平文であっていいのか」だけで議論せず、実行環境全体をどう守るか、そのためにはどうする必要があるか、ということを論点とする必要があります。
こういった前提の下、OSSとしてのWPは wp-config.php に平文で設定するように設計されています。
それが必ずしも危険に直結しているわけではない想定のためです（その安全を守るための対策はソースコードの書き方ではなく環境の整え方にある）。
そもそもOSSですので、他の方法で設定したければカスタマイズすればいい、ということでもあります。
書きなぐったため整理しているようでぐちゃぐちゃですが、ここまでの議論の中でも議論の想定に少し違和感があったので、書いてみました。
議論とは関係ないことにも回答していただき、ありがとうございます。
何回かConpassのオンラインのもくもく勉強会には参加したことがあったのですが、コミュニティに入ったことはなかったため、探してみたいと思います！
今回の質問で、サーバーやphpファイルに対して、ふんわりとしたイメージのような知識しかなかったのですが、色々な方に教えていただいたおかげで、少しつかめたような気がします。
正直な所、今使っているサーバーのセキュリティがどのレベルでされているのかわからず、私も知識がないためわからないことだらけなので、これから調べてサーバーがどういう状況なのか見ていきたいと思います。
#40
総合スコア15
投稿2023/06/08 10:51
phpファイルにデータベースの情報を直接記入して、サーバーにアップしても大丈夫なのでしょうか。
WebサーバーにApacheを使っているのであれば
Apacheに環境変数を設定しそれを読み込ませる方法はどうでしょうか？
以下の記述をバーチャルホストに記述する
SetEnv NAME "Robert Smith"
#41
総合スコア3
投稿2023/06/19 01:15
No, it is generally not recommended to enter the database connection information directly in the WordPress PHP files, such as the wp-config.php file. Storing sensitive information, such as database credentials, directly in code files can pose security risks. If an attacker gains access to the PHP files, they would have direct access to the database, potentially compromising sensitive data.
A better practice is to store the database connection information in a separate configuration file outside the web root directory. WordPress follows this approach by default with the wp-config.php file, which is usually located one directory level above the WordPress installation directory. This separation adds an additional layer of security because the configuration file is not accessible to the public.
By keeping the database connection information separate, you can also easily manage different configurations for development, staging, and production environments without modifying the core PHP files.
It's important to ensure that the configuration file is properly secured with appropriate file permissions to prevent unauthorized access. Additionally, you can consider encrypting the sensitive data within the configuration file for an extra layer of protection.
Remember, security is a critical aspect of web development, and following best practices, such as separating sensitive information from code files, helps mitigate potential vulnerabilities.