ホームページ >バックエンド開発 >PHPチュートリアル >PHP でのセッションは安全ですか?

PHP でのセッションは安全ですか?

WBOY
WBOYオリジナル
2016-06-20 12:39:12980ブラウズ

特別な処理をせずに、PHP でネイティブ セッションを使用するだけでは、非常に安全ではありません。 PHP はセッション実装のみを提供します。その後のセキュリティ作業はプログラマーが柔軟に習得する必要があるため、PHP プログラミングは非常に柔軟です。

私は長い間 PHP を開発してきましたが、セキュリティの問題についてはまったく気にしたことがなく、常にプロジェクトを完了することに重点を置いていました。最近、インターネットでセキュリティに関する記事を目にしただけです。それを読んだ後、私は以前のプロジェクトに大きなセキュリティホールがあったことに気づき、プロジェクトを選んでテストしてみたところ、簡単にその被害に遭ってしまうことが分かりました。ここでは、PHP のセッションがどのように安全でないのか、またプロジェクト内のセキュリティを強化する方法を説明するために私が作成したテスト例を共有します。

セッションの原理や仕組みについては、インターネット上に良い紹介記事がたくさんありますので、自分で調べることもできます。テスト用の例を直接共有しましょう。

このテストの例は主にログインページであり、ログインに成功した後、パスワードを変更できます。

インターフェイスは次のとおりです

まず、プロジェクトの入り口で関数 session_start() を使用してセッションを開きます。このようにして、クライアントがリクエストを開始すると、ID 識別子、つまり SessionID が生成されます。これは、Cookie を通じてクライアントに保存され、クライアントとサーバー間の各通信は、識別のためにこの SessionID に依存します。

ログインに成功すると、ユーザー ID とユーザー名がセッションに保存されます

$_SESSION['userid'] = ユーザー ID$_SESSION['uname'] = ユーザー名

今後のすべての操作では、$_SESSION['userid'] が存在するかどうかを判断することで、ユーザーがログインしているかどうかがチェックされます。コードは次のとおりです。

if ( isset ( $_SESSION ['userid'])) return true ;パスワード変更インターフェイスは、ajax post を介してサーバーにデータを送信します。

$.post("Interface*******",

{

oldpass:oldpass,

newpass:newpass ,

userid:uid,

},

function

(データ){ data = eval('(' + data+ ')');

$('.grant_info').html(infos[data.info]).show();

}

);

このコードは HTML ページに記述したため、HTML コードを見ればインターフェイス アドレスがわかることに注意してください。

このようにしてパスワードを変更するためのインターフェースが実装されています。まず、ユーザーがログインしているかどうかを判断します。ユーザーがログインしている場合は、パスワードの変更操作が実行されます。

テスト例の実装アイデアは大まかに上記の通りです。

SessionID を使用した攻撃

1. 1 つ目は、SessionID を取得することです。もちろん、攻撃者がこの ID を取得する方法はたくさんあります。私のレベルでは説明しません。入手方法はこちら。最初に通常どおりこのプロジェクトにアクセスし、次にブラウザを通じて SessionID を確認して正当なユーザー ID を取得することで、これをシミュレートできます。この ID はリクエスト ヘッダーで確認できます

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Encoding: gzip、deflate

Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3

接続: keep -alive

クッキー: Hm_lvt_bf1154ec41057869fceed66e9b3af5e7=1450428827,1450678226,1450851291,1450851486;

PHPSESSID=2eiq9hcpu3ksri4r587; ckt9jt7;

ホスト: ******

Referer: ******

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0

セッションID取得後, ユーザーがログインに成功すると、ユーザーの情報がサーバー上のセッションに保存されます。

2. SessionID を取得した後、攻撃者がパスワードを変更するためのインターフェイスをすでに知っている場合、ユーザーのパスワードを直接変更できます。攻撃者がまだインターフェイス アドレスを取得していない場合は、ページ コードを調べることでインターフェイス アドレスを見つけることができます。次のコマンドを使用できます。

#curl --cookie "PHPSESSID=2eiq9hcpu3ksri4r587ckt9jt7" ページアドレス

上で述べたように、この例では、ajax コードは HTML ページに記述されているため、インターフェイスのアドレスはこのページで確認できます

HTML コードの一部は次のとおりです

……

var uid = $(".userid").val();

$ .post("/User /User/modifypass_do",

{

oldpass:oldpass,

newpass:newpass,

userid:uid,

} ,

関数

(データ){ data = eval('(' +data+ ')');

$('.grant_info' ).html(infos[data.info]).show();

}

);

……

< input type= "password" name= "confirmpass" id= "textfield_c" placeholder= " パスワードの確認" >

/>

3. インターフェースを取得したら、curl 経由でデータを送信して、パスワード変更のポストをシミュレートできます

コマンドは次のとおりです

#curl --cookie "PHPSESSID=2eiq9hcpu3ksri4r587ckt9jt7" -d oldpass=111111 -d newpass=000000 -d userid=ユーザー ID インターフェイス アドレス

このユーザーが既にログインしている場合、攻撃者は上記のコマンドを実行することでユーザーのパスワードを変更できます。

解決策

上記の攻撃に対しては、検証方法を複雑にすることで安全性を高めることができます。 1 つの方法は、リクエスト ヘッダーで User-Agent 項目を使用してセキュリティを強化することです

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ * ;q=0.8

受け入れエンコーディング: gzip、deflate

受け入れ言語: zh-CN,zh;q=0.8,en-US;q=0.5,en;q= 0.3

接続: キープアライブ

Cookie: Hm_lvt_bf1154ec41057869fceed66e9b3af5e7=1450428827,1450678226,1450851291,1450851486; cpu3ksri4r587ckt9jt7;

ホスト: ******

リファラー: ******

ユーザーエージェント: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0

いつプロジェクトが開始されたとき、最初は session_start() 関数を使用してセッションを開始しました。これで、このコードを session_start()

$_SESSION['User_Agent'] = md5($_SERVER['HTTP_USER_AGENT']);

の下に追加して、毎回ログインするかどうかを決定できるようになりました。その場合、以下のように判定条件を追加します。

If(isset($_SESSION['userid']) && $_SESSION['User_Agent'] == md5($_SERVER['HTTP_USER_AGENT'])) {

return true;

}

こうすることで、上記の単純な攻撃を回避できます

概要:

Ofもちろん、実際には、この状況での攻撃は決して単純ではありません。まず、SessionID を取得することが困難です。次に、上記の状況を回避するために、サーバーと通信するコードを可能な限り暗号化する必要があります。コードを 2 回変更した後は、攻撃の複雑さを増すことはできますが、攻撃を排除することはできません。攻撃にはさまざまな方法がありますが、これは単なる 1 つのアイデアにすぎませんが、実際の状況に応じてコードのセキュリティを強化することができるのは原則として同じです。私のレベルが限られているため、私は仕事で遭遇した問題を共有しているだけであり、他の人に良い意見がある場合は、一緒に議論して改善するために以下のメッセージを残してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。