APPインタフェース設計セキュリティ問題-appインタフェース認証
7751 ワード
私の問題は、セキュリティ関連の処理をしないと、データベースを変更する可能性のある操作がゴミデータの提出に遭遇する可能性があります.結局、これらの情報を見つけるにはhttpパッケージを探せばいいのです.
システムにユーザーログインはありません
初心者の問題(サービス開発をしたことがありません)、できれば、いくつかの主流の方法のリンクをあげて、ありがとうございます
直感的にまとめる方法2:
1.要求ヘッダにユーザーusernameとpasswordを連れて、サーバー側に検証を行い、下のビジネスロジックを継続します.ちょっと:サーバ側apiが勝手に呼び出されるのを防止しました.欠点:毎回ユーザー名とパスワードがインタラクティブで、インタラクション量が大きく、パスワードの明文転送が安全ではありません.
2.最初のリクエストは、usernameとpasswordを要求し、検証に合格し、cookieをクライアントに植え、appはcookie値を保存する.リクエストのたびにクッキーを持参します.コメント:pc上のブラウザ認証の原理と同じです.
以上の2つの点では、ユーザーを登録してこそ、ビジネスロジックにアクセスする権利がありますが、appにはデータapiを登録する必要がないものがたくさんあります.
3.token生成規則を制定し、一部のサーバー側とクライアントが所有する共通属性によってランダム列を生成し、クライアントはこの列を生成し、サーバーは要求を受け取ってもこの列を検証する.欠点:ランダムシリアル生成規則は秘密にしなければならない.たとえば、PHPフレームワークを使用するプロジェクトでは、フレームワークが相互作用するたびにmoduleとactionの2つのパラメータがルーティングされます.そうすれば、私は下のルールでtokenを生成することができます.
appはユーザーリストを要求します.apiは「index.php?module=user&action=list」app生成token=md 5 sum('user'.'2012-11-28'.'$@%!'.list)=880 fed 4 ca 2 aabd 20 ae 9 a 5 dd 774711 de 2;実際のリクエストは「index.php?module=user&action=list&token=880 fed 4 ca 2 aabd 20 ae 9 a 5 dd 774711 de 2」
サーバ側は要求を受けて同じ方法でtokenを計算し、
まずこの3つを言って、すべてプロジェクトで使ったことがあります.
一般的な構造方法ここではeoeネットワークインタフェースの長い間の関連約束を例に挙げます.
共通パラメータ:
パラメータ名
値をとる
意味
コメント
uniquely_code
文字列
このユーザーの携帯電話のデバイス番号
必須、デバイス固有コード
api_key
文字列
割り当てられたapi_key
必須
nonce
文字列
ユニークコード
必須
timestamp
数値
タイムスタンプ、アクセス時間の識別
必須
api_sig
署名値
規則に従って計算された署名
必須
alt
文字列、現在xmlをサポート
結果を返すデータフォーマットが必要です
オプション、デフォルト:xml
page
数値
結果セットの数ページ目の結果を取得
オプション、デフォルト:1
limit
数値
結果セットは、ページごとにいくつかの結果を返します.
オプション、デフォルト:20
locale
文字列、フォーマットzh-rCN
現在のユーザーのlocaleコード
オプション、デフォルト:unknown-rUnknown
PS:各インタフェースは、それぞれのビジネスロジックに必要なパラメータに加えて、以下の共通パラメータを含む必要があります.認証ルール:署名値の計算:api_Sig=MD 5("api_key"+@api_key+"+"nonce"+@nonce+"timestamp"+@timestamp+"uniquely_code"+@uniquely_code+api_secret)送信要求:上記パラメータリストに必要なパラメータに加えて計算されたapi_sigがGET方式で送信される.
もちろん、アルファベットを並べ替えて「secret key」を加えてhashを作るなど、他の方法もありますが、全体的に一般的な認証方法は大きく異なります.会社のインタフェースが上記の方法を採用しており、セキュリティレベルの要求が特に高い場合は、NDKで実現することをお勧めします.
システムにユーザーログインはありません
初心者の問題(サービス開発をしたことがありません)、できれば、いくつかの主流の方法のリンクをあげて、ありがとうございます
直感的にまとめる方法2:
1.要求ヘッダにユーザーusernameとpasswordを連れて、サーバー側に検証を行い、下のビジネスロジックを継続します.ちょっと:サーバ側apiが勝手に呼び出されるのを防止しました.欠点:毎回ユーザー名とパスワードがインタラクティブで、インタラクション量が大きく、パスワードの明文転送が安全ではありません.
2.最初のリクエストは、usernameとpasswordを要求し、検証に合格し、cookieをクライアントに植え、appはcookie値を保存する.リクエストのたびにクッキーを持参します.コメント:pc上のブラウザ認証の原理と同じです.
以上の2つの点では、ユーザーを登録してこそ、ビジネスロジックにアクセスする権利がありますが、appにはデータapiを登録する必要がないものがたくさんあります.
3.token生成規則を制定し、一部のサーバー側とクライアントが所有する共通属性によってランダム列を生成し、クライアントはこの列を生成し、サーバーは要求を受け取ってもこの列を検証する.欠点:ランダムシリアル生成規則は秘密にしなければならない.たとえば、PHPフレームワークを使用するプロジェクトでは、フレームワークが相互作用するたびにmoduleとactionの2つのパラメータがルーティングされます.そうすれば、私は下のルールでtokenを生成することができます.
appはユーザーリストを要求します.apiは「index.php?module=user&action=list」app生成token=md 5 sum('user'.'2012-11-28'.'$@%!'.list)=880 fed 4 ca 2 aabd 20 ae 9 a 5 dd 774711 de 2;実際のリクエストは「index.php?module=user&action=list&token=880 fed 4 ca 2 aabd 20 ae 9 a 5 dd 774711 de 2」
サーバ側は要求を受けて同じ方法でtokenを計算し、
$module = $_GET['module'];
$action = $_GET['action'];
$token = md5sum($module.date('Y-m-d',time()).'#$@%!*'.$action);
if($token != $_GET['token']){
alarm('access deny');
exit();
}
?>
まずこの3つを言って、すべてプロジェクトで使ったことがあります.
一般的な構造方法ここではeoeネットワークインタフェースの長い間の関連約束を例に挙げます.
共通パラメータ:
パラメータ名
値をとる
意味
コメント
uniquely_code
文字列
このユーザーの携帯電話のデバイス番号
必須、デバイス固有コード
api_key
文字列
割り当てられたapi_key
必須
nonce
文字列
ユニークコード
必須
timestamp
数値
タイムスタンプ、アクセス時間の識別
必須
api_sig
署名値
規則に従って計算された署名
必須
alt
文字列、現在xmlをサポート
結果を返すデータフォーマットが必要です
オプション、デフォルト:xml
page
数値
結果セットの数ページ目の結果を取得
オプション、デフォルト:1
limit
数値
結果セットは、ページごとにいくつかの結果を返します.
オプション、デフォルト:20
locale
文字列、フォーマットzh-rCN
現在のユーザーのlocaleコード
オプション、デフォルト:unknown-rUnknown
PS:各インタフェースは、それぞれのビジネスロジックに必要なパラメータに加えて、以下の共通パラメータを含む必要があります.認証ルール:署名値の計算:api_Sig=MD 5("api_key"+@api_key+"+"nonce"+@nonce+"timestamp"+@timestamp+"uniquely_code"+@uniquely_code+api_secret)送信要求:上記パラメータリストに必要なパラメータに加えて計算されたapi_sigがGET方式で送信される.
もちろん、アルファベットを並べ替えて「secret key」を加えてhashを作るなど、他の方法もありますが、全体的に一般的な認証方法は大きく異なります.会社のインタフェースが上記の方法を採用しており、セキュリティレベルの要求が特に高い場合は、NDKで実現することをお勧めします.