4

フロントエンドとバックエンドを備えた Web アプリケーションに取り組んでいます。パブリックはフロントエンドに情報を保存でき、特定の人は挿入された詳細を管理および編集できます。

個人情報の性質上、アプリケーションのセキュリティは非常に重要です。情報が安全であることを確認するために私が取った対策が適切かどうか疑問に思っています.

1 - 「低」レベルのセキュリティ
ドメインには独自の SSL 証明書と DNSSEC があります。アプリケーションはプライベート VPS で実行されます。すべてのパスワード (UNIX ユーザー、データベース ユーザーなど) はすべて、もちろん強力です。

2 - ディレクトリ構造 

 /data
    |- lib                   // store php classes and runtime information
    |    |- constants.php    // stores, among others, the private key
    |- cnt                   // logical content
    |- public                // the public root where nginx directs to
    |      |- img            // images
    |      |- res            // other resources
    |      |- index.php      // only contains include('../private.php');
    |- private.php           // the real webapplication root

そのため、PHP で何か問題が発生した場合、コードが吐き出され、ディレクトリ構造が損なわれます。誰かが NGINX-webserver を通して見ることができるのは public フォルダーだけです。

3 - データベース
pos​​tgreSQL に保存された情報は、openssl_encrypt で暗号化SHA_256_AESされ、php ファイルに保存された秘密鍵で暗号化されます (ディレクトリ構造を参照/data/lib/constants.php)。したがって、データベースが危険にさらされたり盗まれたりした場合、秘密鍵がないとデータを読み取ることができません。

4 - 管理ユーザー
ログインしているユーザーは、cookie に保存された sha1 セッション ID を取得します。サーバーに保存されているセッションのログイン状態です。セッション (ID) はフォームから取得できます。これは、javascript を介して sha1 でエンコードされたパスワード ハッシュをインターネット経由で送信するだけです。もちろん、パスワードはソルトされており、特定のルールがあります（長さ> 8、特殊文字など）

5 - XSS、CSRF、$_POST
すべてのユーザー入力がフィルタリングされています。サーバーでの変更は、リクエスト後のみに行われます。すべてのフォームには、ランダムに生成された CSRF セキュリティ トークンがあります。

私が満足していない唯一のことは、秘密鍵がサーバー上で利用可能であるという事実ですが、public-webroot では利用できません。これはどういうわけか行われていませんか、それともこれを行う別の方法はありますか?

何か不足していますか？

4

0 に答える 0