テーブルにDBプレフィックスを使用する方が安全ですか？

Question

データベースプレフィックスを使用するシステムを見つけました。セキュリティ機能と呼ぶ人もいます。 1つのデータベースに複数のインストールを行う方法と呼ぶ人もいます。

主な利点は、テーブル名全体を推測するのが難しいということです。一方、データベースへのアクセスがある場合は、スキーマ/テーブルリストを理解できると思います。

それは実行可能なセキュリティ機能ですか？

Anders · Accepted Answer

これはあいまいさによるセキュリティです。すべてのケースであなたを傷つけることはないかもしれませんが、それだけでは実行可能なセキュリティを提供しません。あなたの保護としてこれに依存しないでください。

短いたとえ

家のMONEYというラベルの瓶にお金を入れているとしましょう。家を出るときにドアをロックするのを忘れることがあることを知っているので、泥棒がそれを見つけないように瓶のラベルをCOOKIESに変更します。あなたは今より安全だと思いますか？もちろん、非常に怠惰でばかばかしい泥棒はそれを見逃すかもしれませんが、お金を盗むためにマスター泥棒である必要はありません。代わりにドアをロックすることを覚えておくほうがいいのではないでしょうか。

コンピュータの世界に戻る

SQLインジェクションの脆弱性がある古いphpBBインストールがあるとします。デフォルトでは、テーブルの前にはphpbb_が付いています。これをobscure_に変更します。これは役に立ちますか？

ナイーブスキャンでは、ハードコーディングされたテーブル名（すべてのパスワードを含むphpbb_usersなど）を見つけることができないため、失敗する可能性があります。しかし、スクリプトの子供でも、SHOW TABLESを実行してobscure_usersを見つけるスクリプトを実行できます。実際、SQLインジェクションの脆弱性を利用して、テーブルの内容allを自動的にダンプするツールがあります。

結論

ここでの教訓は何ですか？テーブルのプレフィックスを変更する（jarのラベルを変更する）と、最も基本的なダムの自動攻撃（愚かな怠惰な泥棒）から保護される可能性がありますが、スクリプトキディ（jarを検索する泥棒）による単純な攻撃に対しては依然として脆弱です。 SQLインジェクションのような実際の脆弱性がある場合、解決策はその脆弱性を修正（ドアをロック）することであり、不明瞭な薄いベールを追加しないことです。

とは言え、一部の攻撃を遅くする可能性がある単純な予防策は、有害な副作用がない場合は「防御の深さ」として価値があるかもしれません。 実装したからといって、安心してはいけません。

（補足として、同じデータベースで複数のインストールを実行すると、状況によっては、それ自体がセキュリティに影響を与える可能性があると言う必要があります。）

Philipp · Answer

いいえ、ヘビ油です。

誰かがアプリケーションにSQLインジェクションの脆弱性を見つけた場合、テーブル名を知らないことは非常に小さな障害です。多くのストックインジェクションペイロード（古き良きユニバーサルパスワード' OR '1' = '1など）は、テーブル名を知る必要すらありません。また、攻撃者が任意のテーブルからデータをダンプする方法を発見した場合、システムテーブルINFORMATION_SCHEMA.TABLES（または使用するデータベースシステムによっては同等）をダンプするだけで、他のすべてのテーブルの名前を取得できます。

しかし、それは必ずしもtoxicヘビ油ではありません。複数のインストールで同じデータベースを共有できることは、（低予算のWebホスティング会社のように、MySQLクラスターで単一のデータベースのみを使用できるようにするなど）正当な機能であり、ランダムである限り接頭辞であり、テーブル名は人間が読める形式であり、メンテナンスにはそれほど影響しません。しかし、それは多くのセキュリティを追加しません。

O. Jones · Answer

WordPressなどの広く採用されているDBMSベースのシステムでは、my_fav_prefix_postsの代わりにwp_postsなどのテーブル名を使用するようにインスタンスを構成するのが一般的です。

どうして？スクリプトキディの速度を低下させるとされています。

数年前、WordPressインスタンスに大量の攻撃がありました。洗練されていないサイバー犯罪者（スクリプトキディ））は、洗練されていない攻撃ソフトウェア（スクリプト）を使用して、脆弱性を探す多数のサーバーにアクセスしました。スクリプトが攻撃リストで次のサーバーに移動したwp_postsテーブルが見つかりませんでした。もちろん、数週間後、スクリプトは少し洗練され、WordPressインスタンスになりました彼らのテーブルを目の前に隠すことができなくなった。

これが神話の起源であり、代替のデータベースプレフィックスによってセキュリティがさらに強化されると思います。彼らはしません。

Serge Ballesta · Answer

これはセキュリティに何も追加しないと思います。しかし、スキーマに依存して異なるアプリケーション間でテーブルを分離することができない（またはしたくない）場合、異なるプレフィックスを使用することで、競合のリスクなしに異なるアプリケーションが同じデータベースを共有できます。

しかし、実際のセキュリティは追加されません。