HTTPプロトコルとセキュリティリスク

HTTPプロトコル

TCP / IPプロトコルスタックのアプリケーション層プロトコルの数、HTTPプロトコルと呼ばれる最も広く使用されるプロトコルを含みます。そのようなサイトにアクセスするときのように、日常生活の広い範囲でHTTPプロトコルを使用して、使用されるプロトコルはHTTPプロトコルです。
ここに画像を挿入説明

HTTPプロトコル
HTTPは要求応答モードでは、ステートレスなアプリケーション層プロトコルに基づいています。

リクエストに応じて
サーバーを返すHTTP応答メッセージを待って、後でWebサーバーにリクエストを送信するクライアントのニーズ。
ステートレスな
HTTPプロトコル全体の処理サーバの中から各種の情報が記録されません。

多くの場合、TCPデータパケットにパッケージ化されたHTTP送信することを、TCPコネクションに基づいて、Webアプリケーションの大部分は、現在アクセスしたウェブサイトをブラウザを使用しているHTTPプロトコルの上に構築されているが、HTTPプロトコルに基づいています標準として。

URLにHTTPプロトコル
HTTPリソースをルックアップするために使用する識別情報を含む、URIの特定の種類のURLです。
次のように一般的なURLの形式は次のとおりです。

http://host[“:”port][path]：

HTTP HTTPプロトコルを介してネットワークリソースを検索することを約束。
ホストは、ホストのドメイン名またはIPアドレスを表します。
ポートは、デフォルトは空のポート80で、ポート番号を指定します。
パスは、URIは、リソースを要求し、指定しました

例えば、
http://news.sina.com.cn/c/z/xjpfyzsg2014/
それは特定のURLです

HTTPリクエストメッセージの形式
要求ライン、ヘッダーメッセージ、リクエストボディ：HTTPリクエストは、3つの部分から構成されています。

要求ライン：あなたがアクセスリソースにしたいものを指定します
メッセージヘッダー：HTTP契約で指定されたフィールドの意味。HTTPメッセージヘッダは、共通ヘッダ、要求ヘッダ、応答ヘッダ、ヘッダ・エンティティを含みます。各ヘッダフィールドは名前+である「：」+、メッセージヘッダフィールドの名前は、ケース鈍感スペース+値の組成物です。
リクエストボディ：リクエスト・メッセージで指定された特定のコンテンツが含まれています。

HTTPリクエストライン
を要求する方法は、URI要求のプロトコル・バージョンに続くスペースで区切られた図柄の列、、、次の形式で始まります。
Method Request-URI HTTP-Version CRLF

方法：要求メソッドを示します。
Request-URI：それは、統一資源識別子です。
HTTP-バージョン：HTTPプロトコルのバージョンの要求を示します。
CRLF：キャリッジリターンとラインを表し、

例えば、我々は、Baiduのホームページ、ブラウザのデバッグを開くためにF12を入力してください。ネットワークが見つかり、ページをクリックして、リフレッシュ、ブラウザは、要求の内容を見ることができます。
ここに画像を挿入説明

GET / HTTP/1.1  // 请求行
Host: www.baidu.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3314.0 Safari/537.36 SE 2.X MetaSr 1.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9  //请求头
// 请求正文
......

HTTPプロトコルの方法

要求リソースのRequest-URIによって識別される：GET
POST：Request-URIによって識別されるリソースの後に追記新しいデータ
HEAD：のRequest-URIヘッダで識別されるリソースに応じて、要求メッセージ
PUT：サーバーへ、そしてリクエスト-URIとしてのアイデンティティーを持つストレージ・リソース要求
DELETE：Request-URIによって識別されるリソースを削除するには、サーバに要求
TRACE：エコー要求情報要求サーバは、主にテストや診断に使用する受信します
CONNECT：将来の使用のために予約
サーバーのクエリの要求またはクエリのパフォーマンス関連のオプションやその他のリソース：OPTIONS

HTTPプロトコルの応答メッセージのフォーマット
を含む：ラインの初期状態では、第一のライン部、エンティティボディ。

HTTP/1.1 200 OK   // 状态行
Bdpagetype: 2
Bdqid: 0xf63dd9120001138a
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Wed, 18 Mar 2020 05:02:14 GMT
Expires: Wed, 18 Mar 2020 05:02:14 GMT
Server: BWS/1.1
Set-Cookie: BDSVRTM=172; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=30968_1426_21087_30903_30998_30824_31086; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Traceid: 1584507734025483316217743576778242331530
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked   // 以上都是首部行等
// 实体主体
............

セキュリティは、HTTPプロトコルをリスク

（1）フィッシング
攻撃者は何らかの方法でサイトのために偽造します。例えば、攻撃者は、顧客のためにこのサイトをフィッシングサイトを、サイトのコンテンツをウェブサイトを設計しますとまったく同じ標的にされ、かつ適切な接続上のクライアントのクリックは、それが可能であるとき、最終的には、アクセスするネットワーク上の道へのアクセスを広げますそれは、非常に精通しているだまされる可能性があります。主な理由はだまさフィッシングサイトは、httpプロトコルには、厳密な認証メカニズムが存在しないため、真か偽かわからないということです、この方法では、ユーザーに関する機密情報を得ることができる攻撃者です。

ここに画像を挿入説明
（2）クロスサイトスクリプティング攻撃

スクリプト：ブラウザを実行するために解析することができる小さなプログラム。
スクリプティング攻撃（スクリプト攻撃）：ユーザデータを取得したり、システムを損傷するよう、攻撃者がブラウザに攻撃スクリプトを送っていたがそのように解釈しました。

ユーザデータのセキュリティを保護するために、一般的にブラウザがアクセスクロスセッション（セッション）のデータにスクリプトを許可していません。
Webブラウザとの通信を確立するために、ユーザは、我々は別の接続またはセッション間でのデータのセッションはブラウザを保護されて呼び出し接続を確立するたびHTTPプロトコルは、一般的にスクリプトがあり、データを転送するためにTCPを使用していますこれは、他のページ上のデータにアクセスするセッションやブラウザを交差することはできません。

<SCRIPT>Alert(Document.Cookie)</SCRIPT>

上記の文書の情報を表示するには、クッキーアラート機能を使用して簡単なスクリプト、すなわちクッキーは、たとえば、ユーザーのローカルファイルに関する機密情報が含まれている、ショッピングサイトを訪問し、Webサーバがユーザのアカウントとパスワードの情報を送るが格納されています局部的に、もはやアカウントとパスワードを入力して、初めてのウェブサイトをご覧ください。

スクリプティング攻撃手順の
攻撃者がローカルのクッキー目標分析の実行を読んだ後、ターゲットにスクリプトプログラムを送信し、攻撃者にこの情報を送信します。
ここに画像を挿入説明
セッションまたはスクリプトは、他のページ上のデータにアクセスするためのクロスブラウザことはできません。

クロスサイトスクリプティングのプロセス

そのようなAのプロセスでは、攻撃者がデータを取得するためには、攻撃者が直接攻撃の対象とするスクリプトを送信することはできません。
クロスサイトにそれを達成するためにどのように？
まず、攻撃者が現在攻撃スクリプトコードであってもよいがサーバーに送信され、スクリプトはローカルサーバ、ターゲットサーバへのアクセス時間に保存されます、あなたはこれらのスクリプトを含むWebページにアクセスすることができ、これらのページかもしれませんこれは、実行、ローカルの攻撃者と解析にダウンロードされています。実装の過程で攻撃に送られたものに適切な情報を得ることが可能です。

方法を生成することができ、スクリプトを含むWebサーバーのスクリプトページにアップロードされ、攻撃者は以下のとおりです。

フォーラムは
、ユーザーが情報を提出することができます
コメント
商品のレビュー、情報を提出することができ、アフターマーケットの評価
IMは
、ユーザーがメッセージを送信することができます
社会的には、ネットワークアプリケーション
、ユーザーがメッセージを送受信することを可能にする、との議論評価

条件は、クロスサイトスクリプティング攻撃を発生します

ユーザがコンテンツを提供することを可能にするウェブ・アプリケーションへの入力情報をユーザに許可します
ユーザ入力データは、情報にアクセスできる場合、ストレージが動的に生成されたWebサーバ、攻撃することができ、動的にページを生成するために使用することができます。
ユーザ入力が検出されていない攻撃者が不正なプログラムが提供する正当性が検証されていません

クロスサイトスクリプティング攻撃の分類

永続的なクロスサイト（XSSの永続的またはストアドXSS）
サーバーに保存されている攻撃データ。ユーザーは通常のWebページ、動的に生成されたWebページにアクセスすると、サーバーがユーザーに返さ通常のWebページでの悪質な命令を含めるとなります。
クロスサイト非永続的（非永続的なXSSやXSSを反映）
悪意のあるスクリプトスクリプトや、被害者として実行、（サーバは、悪意のあるユーザーが送信したデータに基づいてページを生成する）の後にHTTPリクエストに応じて即座に得られます。
クロスサイトのドキュメントオブジェクトモデル（DOMベースのXSS）
のクライアント側のスクリプト（例えばJavaScriptは）動的にHTMLを生成する場合の時間は、厳密な検査とフィルタリングパラメータは、それはDOM（ドキュメントオブジェクトモデル）、クロスサイト攻撃につながることはできませんがあります。

ブラウザを介してユーザーがWebページにアクセスするときに、ユーザーが返されるドキュメントオブジェクトモデル、すべてのHTMLオブジェクトは、文書が最も重要な文書が、それはまた、（たとえば、場所、URL、リファラやボディなど）の単語オブジェクトが多く含まれているオブジェクト

document.location 
document.URL 
document.URLUnencoded 
document.referrer 
document.write() 
document.writeln() 
document.boby.innerHtml

Documentオブジェクトが呼び出しまたはプロパティの割り当てによって、多くのプロパティとメソッド、これらのメソッドが含まれ、例えば、クロスサイトスクリプティング攻撃、ことができるようになります。

http://www.abc.com/welcome.html 
<HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var 
pos=document.URL.indexOf("name=")+5; 
document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> 
<BR> Welcome to our system … </HTML>

ユーザーが名前を入力するようユーザに要求するこのページにアクセスすると、このページが動的にユーザーが入力した名前に基づいて適切なコンテンツを表示します。通常の状況下では、ブラウザに表示されますWelcome to our system
が、我々は次のようにコードの一部を埋め込む：
http://www.abc.com/welcome.html?name= < script>alert(document.cookie)</ script>
この場合、攻撃者はユーザーに対してクロスサイトスクリプティング攻撃を達成するために、ユーザー名といくつかのスクリプトコードを置き換えられます。

公開しないでください。

公開された74元の記事・ウォンの賞賛9 ・ビュー20000 +

プライベートの手紙の懸念