ヘッドスタッフのためだけに（Fred -ii-がこのコードを使用しないと言った理由がわかります）-これを順番に分解していきます（そうではありません）質問を提起している人を個人的に掘り下げます-しかし、LAMPスタック上に中途半端な安全なアプリケーションを構築しようとすると、少しの注意と先見の明が必要であるという考えを与えるために...人類は助けます）：
ポイント1
大したことではありませんが、実際にセッションを開始する場合は、$_POSTがあるかどうかに関係なくセッションを開始する必要があります。 データかどうか。おそらく、構成ファイルが必要であり、何よりも先にセッションを一番上から開始する必要があります。
ターミナルエラーではありません（セッション検証がないため）-奇妙なだけです。
ポイント2
このファイルに出力があります（echo ）したがって、ドキュメントルートの下にあり、Webツリーで使用可能である必要があります。
include("config.php");
これは実際には正しく記述されていません。おそらくrequire_once 'config.php';である必要があります。 （これは必須のプログラムファイルであり、失敗を許可できるオプションのインクルードではないと仮定します）が、それは エラーではありません。エラーは、ドキュメントルート内に設定ファイルがあることです。そのファイルのサーバーの設定ミスや単純なタイプミスにより、理論的には、そのファイルの内容がプレーンテキストで画面に出力され、データベース接続文字列（および他に何を知っているか）がworld+dogに表示される可能性があります。
構成ファイルは、Webツリーの外部に存在する必要があります。それができない場合は、.htaccessなどで保護されたディレクトリ内に存在する必要があります。 Deny from all 。 HTTP経由でアクセスできないようにする必要があります。
ポイント3
mysql ライブラリは非推奨であり、まったく使用しないでください。 MySQLiまたはPDOは、理想的にはバインドされたパラメーター/値を使用する方法です。
個人的にはPDOを取得しました。
ポイント4と5
$password = mysql_real_escape_string(stripslashes(md5($_POST['password'])));
まず、この順序が間違っています。 $_POST['password']をハッシュしています そしてそして スラッシュを削除しようとしています-ハッシュされた後はスラッシュはありません。ただし、パスワードにスラッシュ（またはその他）を使用できないようにする場合は、文字列をハッシュする前にパスワードを削除する必要があります。
次のmd5 パスワードハッシュアルゴリズムとして使用しないでください。これは脆弱であることが判明しており、文字列の衝突を必要以上に頻繁に発生させる可能性があります。
はい、すべきです パスワード自体ではなく、パスワードのハッシュまたは「指紋」のみを保存しますが、理想的には、（少なくともsha1を使用してソルトおよびハッシュする必要があります。 ）これらのパスワードを単にmd5()に投げ込むのではなく 機能。
参照： http://uk3.php.net/mcrypt たとえば
そして、選択した検索エンジンを使用して「パスワードソルティングハッシュ」を検索します。
ポイント6
SELECT id FROM $table
WHERE username = '" . $username . "'
and password = '" . $password . "';
=に追加しました これは元の質問にはありませんでしたが、それでもクエリのユーザー名とパスワードが一致しません ...誰かがあなたのユーザー名にSQLインジェクションを取得できた場合、パスワードはチェックされません。想像してみてください：
SELECT user.id
FROM user WHERE user.username = 'fred' OR 1 = 1
-- AND user.password = 'abc123'
データベース層でのパスワードチェックを信頼するよりも、データベースからユーザーIDとパスワードフィンガープリントを選択してから、アプリケーションでパスワードを評価することをお勧めします。また、アプリケーション自体で専用のハッシュおよびソルティングアルゴリズムを使用して、パスワードを検証できることも意味します。
ポイント7
$_SESSION['user'] = $_POST["username"];
これは単にユーザー名をセッションに保存しているだけですか？特に、セッションにはハイジャック 。
セッションIDは、ライブセッションのCookieから簡単に盗聴される可能性があり、他の誰かのログインを「借用」するために必要なのはそれだけです。少なくとも、ユーザーのIPアドレス、UserAgent文字列、またはすべてのページで比較できる比較的静的なデータのその他の組み合わせを関連付けることで、セッションが乗っ取られる可能性を軽減するように努める必要があります...ただし、実際にはどのアプローチにも欠点があります。 （特に、私が見つけたように、AOLを使用している訪問者がいる場合）-しかし、ユーザーのセッションが誤ってダンプされる可能性はほとんどなく、おそらく99％以上の効果的なセッションフィンガープリントを作成してハイジャックを軽減できます。
理想的には、セッションのトークンを作成して、CSRF ユーザーがデータベースに対して「特権」アクションを実行する必要がある場合に攻撃します（詳細などを更新します）。トークンは、ユーザーがログインしたときにデータベースやSSL Cookieに保存された完全にランダムで一意のコードである可能性があります（ユーザーがデータを送信するだけなので、HTTPSの外部でデータベースを更新するアクションを実行できないと仮定します）インターネット全体でクリアテキストで-これは悪い考えです 。
トークンは、すべてのフォームの非表示のフォームフィールドに配置され、そのフォームが送信されるたびにCookie（またはセッションまたはデータベース）に保存されている値と照合されます。これにより、フォームを送信する人が少なくともWebサイトでライブセッションを行うことができます。