0

URLに従ってユーザーにページを表示するこの特定のアプローチの利点と欠点は何ですか?
私が知る限り、ウェブページを構築するための 2 つの基本的なアプローチがあります。

  1. www.whatever.com/index.php?page=userProfil.php
  2. www.whatever.com/userProfil.php

    さて、ポイント 1 と 2 のモデルを呼び出し、php + mysql + apache + クライアントサイド JavaScript (ユーザー チェック用) を使用したいとします - 背景情報のためだけです。sererlets、jsp、Tomcat を使用する場合、モデルの基本的な考え方はほとんど同じですが、いくつかの小さな違いがあると思います。最後に私のプラットフォームは php +mysql です...

    もう 1 つのことは、セキュリティと将来の保証 (プラットフォームを php から別のプラットフォームに変更する) の目的で、".php" または " .html" またはその他のファイル タイプです。

    したがって、これを使用するオプションがあります（きれいなURLの場合）：
  3. www.whatever.com/userProfile/

mod_rewriteと呼ばれるよくグーグルで調べた場合、いくつかのルールを使用してモデル（add 1と2を参照）をadd 3に変換します。
正直に言うと、今のところadd 3について実際にはあまり理解していません。

それで：

  • モデル 1 と 2 は「ファイル構造モデル」と呼ぶことができると思います。つまり、add1 には 1 つのページ (1 つのファイル) があり、いくつかのモジュールが含まれています。したがって、add 1 では毎回 1 つのファイルを呼び出します。追加 2 ページごとに新しいファイルがあります。したがって、追加2の場合、複数のファイルを呼び出します-異なるページの異なるファイルに対して。
  • 追加 3 の場合、ポイント 1 と 2 はユーザーには隠されています。これは良いことだと思います。なぜなら、彼は私のファイル構造 (セキュリティのための +) を知らないからです。

結論と質問:

  • add 1 と 2 の長所と短所 - ファイル構造

  • add3のメリットとデメリット

  • add 1 と add 2 と add 3 を組み合わせた基本的な概要 (1,2 ファイル構造 + add 3 はどのように見えるか)

  • 私は add 1 と 2 の使い方を知っているので、おそらくそのうちの 1 つを使用し、後で add 3 を追加したいと思います (それを知ったとき) - 可能ですか?

4

2 に答える 2

0

さて、あなたの質問は理にかなっていますが、番号付けと説明を使用してPHPサイトを構築するための最良かつ最も実用的な方法は、オプション1にオプション3を追加して、通常SEOフレンドリーと呼ばれるものを作成することです（別名：人間が読める、nice、simple など) URL です。

実用的な観点から言えば、すべての呼び出しが共通のファイルを通過するようにシステムを構築することindex.phpは、最初はコーダーとしての負担が少し大きくなります。しかし、何だと思いますか？あなたはプログラマーで、可能な限り長期的な安定性とセキュリティを備えたツールを作成しています。そのため、可能な限りオプション 1 に合わせてコーディングすることが、あなたの最善の利益であり、サイトの最善の利益でもあります。

セキュリティの観点から、オプション 1 が常に勝つ理由を説明するのは非常に簡単です。コンテンツのリクエストを介して解析index.phpすることで、大量のファイルや機能に自分自身を分散させるのではなく、1 つの領域で発生する可能性のあるセキュリティ問題に対して簡単にプログラミングできます。では、セキュリティ ホールを発見し、その修正方法を知っているとしましょう。index.php1、10、100、さらには 1,000 ページ、またはそれ以上のページがあるかどうかに関係なく、ホールにパッチが適用されるように、サイトのコア コードにパッチを追加して、すべてのファイルを通過させることができます。

また、2013 年には、URL 呼び出しにファイル名を使用しないでください。「適切な」URL を作成するオプション 3 は、それを解決します。これにより、実際のファイル システム URL が世界から隠されます。そして、実際に PHP を使用しているという事実を世界から隠します。セキュリティ計画の一部として、ヘッダーを介してPHPを使用していることをサイトが世界に発表しないようにする必要がありますが、その概念はこの質問の範囲外です。

また、コードを目立たなくする素敵な URL を持つことの利点は次のとおりです。たとえば、PHP に飽きて、コーディングのために Python や Ruby に移行したいとします。さて、基盤となるプログラミング言語が隠されているので、別の言語でサイトを再プログラムできるようになりました。スクリプトが illd サイトの URL に期待どおりに反応することを確認している限り、問題ありません。

于 2013-11-03T14:43:14.323 に答える
0

最初のアプローチには明らかなセキュリティ上の問題があります。悪意のあるユーザーには、ユーザー入力に基づいてファイルを含めていることが明らかなので、page変数を適切にサニタイズし、パスワードなどの機密データを含むファイルを含めることができないようにする必要があります (つまり、英数字のみpage[ ., .., /, null-byte, unicode special chars など] を除外し、「.php」ファイル拡張子のみを含めることを許可し、機密データを呼び出しスクリプトと同じディレクトリに置かず、www の外側にさえも置きません。 -root などなど)。

2番目のアプローチはIMOの方が優れており、明示的なファイルのインクルードはありません。しかし、それはあなたがPHPを使用していることを示しています。これは必ずしも悪いことではありませんが、理論的には、攻撃者にとって潜在的な脆弱性の検索を絞り込むことができます（誰かがPHPの重大な脆弱性を発見し、スクリプトキディ検索のために世界中のサイトが核攻撃を受けると想像してください）を使用して Google 経由で被害者の場合inurl:index.php）。

どちらの方法にも SEO の問題があります (最初の方法には 2 番目の方法よりも落とし穴があります)。あなたが書いたように、別のプラットフォームに移行したい場合のように、「.php」拡張子をエミュレートするか、URL の変更によりトラフィックを失う必要があります (リダイレクトを設定した場合でも)。

私は個人的には 3 番目のアプローチを好みます。Apache サーバーでセットアップするのはそれほど難しくなく、基本的に数行を入力する必要があり.htaccessます (もちろん、すべてをカスタマイズできます)。

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php

これらの行を導入すると、存在しないファイルへのすべてのリクエストが index.php に送られます。次に、アプリケーションで変数を解析してサニタイズ$_SERVER['REQUEST_URI']し、データベースやファイル、または他の場所からページを取得する必要があります。このようにして、かなり SEO に適した URL を取得し、攻撃者に開示する情報を少なくすることができます (少なくとも経験の浅い人にとっては、ファイル拡張子を見る以外にも、サイトが実行されているプラ​​ットフォームを知る方法は他にもたくさんあります)。

于 2013-11-03T14:20:43.843 に答える