Webセキュリティの問題
6075 ワード
関連知識の準備
Webセキュリティを学ぶためにはまず一定のフロントエンド基盤を知る必要があり、フロントエンドは現在HTML+CSS+JSに分かれており、それぞれの用途は HTML:Webページの根本、Webページのどこに画像を表示するか、どこに文字を表示するか、どこに入力を表示するかを設定するための CSS:ページスタイルは、皮膚のようなもので、同じ文字で、太く変色しないなど があります. JS:Web上のノードを操作し、いくつかのデータを処理するためのスクリプト言語 HTTPベース:ネットワーク通信の基本タイプ 関連知識は教育ウェブサイトを通じて科学普及を行うことができ、マークとスクリプト言語であるため、基本的には硬背を死記して入門し、基本的なルールを学ぶことである.
HTTPを置くと、関連教科書を見たり、ブログの通俗的な説明をしたりすることができます.
最初の本
必ず基礎知識の備蓄を見てから本を読みに来なければならない.
入門第1冊の本は指導者に推薦されたのは白い帽子がWebの安全を話して、主に以下の章を読んで、および重点ブラウザセキュリティ:同源ポリシーおよびhttpメカニズムとクッキーは何ですか クロスステーションシナリオ攻撃XSS:反射性ストレージ型およびXSS形成の根本思想!! クロスステーション要求偽造(CSRF):CSRFの実質!! 注入攻撃:注入の実質!!そしてSQLはコンセプトとテクニックを注入します!! ファイルアップロードの脆弱性:形成原理 認証とセッション管理:認証と認可を区別する概念 アクセス制御:注意水平権限権限権限権限超過問題 Webフレームワーク安全:见终わって忘れた…▄【┻┳┳一……☆ Webサーバ構成セキュリティ:一般的なWebサーバを理解し、WebServiceとは別のものであることに注意する 以上やった!!の3章、繰り返し体得して実戦を行う必要があって、後続は実戦の総括があります
3つの主要なセキュリティ問題
Webセキュリティにおける主な3つの問題は,Webセキュリティであるが,その考え方はいかなるネットワーク通信インタラクションのセキュリティ考慮にも用いることができることである. XSS(Cross Site Script):クロスステーションスクリプト注入 CSRF(Cross Site Request Forge):サイト間要求偽造 SQLインジェクション(SQL injection):SQL言語インジェクション 基礎知識の学習を行った後、まずその中の共通性のある部分を総括して、それからそれぞれ3つの問題に対していくつか総括します
まとめ
XSSとCSRFの共通点
HTTPとHTMLの基本的な概念を通じて、私たちは2つの点を知ることができます.すべてのHTTPにおけるネットワーク通信はRequestによる である. HTMLのすべてのノードにおいて、「src=」タグは、ピクチャやFrameのように一度Requestを行ったデータ である.
したがって、XSSおよびCSRFにおける「XS」および「CS」が表すCross Site(クロスステーション)の問題は、このようにしてwww.A.comのドメインの下でスクリプトによりwww.B.comのドメインの下に実行する過程である.
CSRFにおけるRequest Forge(偽造を要求する)は、このようなRequestメカニズムを利用していることがさらに明らかになった.
いくつかの用語の解釈
安全な投稿やディスカッションを見始め、最もよく見られるのは3つの言葉です:浸透/爆破/注入、ここで自分の理解を話します(間違っているかもしれません)
[爆破]と[注入]は2つの手段を指すが、[浸透]は異なる手段で[データ]または[権限]を取得する過程を指す.
爆破の本質は窮挙であり、正しいことを試みるまで試み続けた.注入の本質は正常な入力に悪意のあるコードを挿入し、テキスト解析のメカニズムを利用して非正常な論理の操作を実行することである.
これらのほかに、爬虫類などの用語もあります.私も入門したばかりで、あまり分かりません.
浸透の目的
もしあなたがハッカーであれば、浸透の主な目的はデータで、データは現在お金を売ることができて、もしあなたが白い帽子であれば、浸透の主な目的は権利を持って、浸透の過程の中で最高でどんな権限を得ることができるかを見て、それによって安全措置が適切かどうかを検査します.
XSSまとめ
XSSは反射型と貯蔵型に分けられ、主に注入の手段を通じて、正常なウェブページのテキストに悪意のあるコードを挿入し、ブラウザによるHTMLのテキスト解析メカニズムを利用して、非正常論理のスクリプトを実行する.
まず、XSSの発生に必要な条件をまとめ、反射型と貯蔵型を区別します.必要な条件は次のとおりです. Webサイトに入力パラメータが必要な場所 ユーザの入力は、何らかの方法で再び現れる .
条件1の入力とは必ずしもラベルのテキストボックスタイプではない、選択欄、またはsubmitであってもよく、ツールによるintercept修正パラメータのみで、入力値を制御ことができる.
条件2は反射型と貯蔵型を区別する鍵であり、多くの本では「反射型は被害者が一度対話する必要があるが、貯蔵型被害者はリンクをクリックするだけでトリガーされる」ことで区別されている.実際に区別する点は、条件1の入力で、サイトが何らかの貯蔵手段で再提示されたときに他の人に伝達するかどうかで区別するほうがよい.
XSS防護の手段
HTMLまたはJSの[入力チェック]と[出力符号化]により、一般的な敏感文字を入力時にフィルタリングしたり、出力時にエスケープしたりする.HTMLページは読み取りとレンダリングの2つのプロセスに分かれているため、エスケープされた文字は、読み取りの過程で実行されず、レンダリングの過程でエスケープされた文字をエスケープし、ユーザーの理解に影響を与えない.
反射型XSSと格納型XSSの例
はんしゃがた
名前を入力するテキストボックスがあり、キーの提出を行うと、あなたの名前が戻ってきたページの内容に表示されます.このページを離れると、すべての入力が戻ってこないので、操作中に入力した名前だけが見えます.ここにXSS漏れ穴があれば、反射型です.
これは応答時間とは関係ありません.2時間後に結果を返すとしても、反射型です.彼は2つの条件が必要です.ユーザ操作 が必要である.プロセスが中断すると、入力データは に戻らない.
きおくがた
名前を入力するテキストボックスがあり、提出すると、あなたの名前がサーバーに送られてデータベースに保存され、返された結果、すべてのデータベースの名前がページの内容に戻ります.このページを離れても、次に入力した名前にアクセスするのはこのページにあります.2回のアクセスだけでなく、他の人がこのサイトにアクセスしても見えます.XSSの脆弱性があれば、保存型です.
注意、ここはデータベースに保存することも、他の保存手段にすることもできます.つまり、サイトのメカニズムはあなたの入力をHTMLページ全体の内容の一部としています.よくあるのは伝言板で、みんなの伝言は中に保存されています.だから、保存型には一般的にこの2つの特徴があります.はユーザ操作を必要とせず、このHTMLページを解析すると がトリガーされる.悪意のあるコードは必ずしもあなたの本機が生んだものではありません.他の人が生んだ かもしれません.
CSRFまとめ
サイトをまたいで偽造を要求する核心の本質はユーザーのSessionを盗むことであり、あるいはCookieである.現在主流の状況ではSessionはCookieに存在するからである.攻撃者は被害者の具体的なアカウントとパスワードに関心を持たない.ユーザーが登録すると、Sessionはユーザーの唯一の証明であり、攻撃者がSessionを得ることができれば、被害者を偽装してサーバーに入ることができるからである.
HTMLのRequestメカニズムを利用して、攻撃者は被害者のwww.B.comドメイン名の下のウェブサイトに送信し、内部に悪意のある「src=www.A.com」のRequest命令が埋め込まれている.被害者がB.comを開くと、現在のブラウザはちょうどA.comにログインし、A.comのCookieをブラウザに入れている.では、B.comでRequestサイトA.comを降りると、A.comのSessionを持っていきます.サーバは、B.comの悪意のあるリクエストがユーザー自身が発行したものだと勘違いします.
このようなB.comの下で隠れたアクセスA.comはCSの跨局の意味であり、「src=」のこのような要求方式はA.comのSessionを持って行って、RF要求の偽造である.
CSRFの保護
CSRFが成功したのは、B.comがA.comのSessionを取り出したためであることが判明し、多くのブラウザはHttpOnlyタグを採用し、Cookieが別のドメインからJSスクリプトで取り出すことを防止している.しかし、B.comでは要求を偽造し、攻撃者は直接Sessionを手に入れるのではなく、被害者にA.comにログインしてSessionをブラウザに存在させるように誘導するだけである.
CSRFの一般的な主な目的は、ウェブサイトの管理者を攻撃することであり、管理者がバックドアとして新しい管理者ユーザを作成することによって、より多くの操作を行うことである.上述のようなCSRFの偽装行為は、CSRF+Tokenの方式であり、要求のたびにTokenの文字セグメントを追加して、ユーザ本人の操作であるかRequest Forgeかを検証する.
SQL注入まとめ
注入攻撃とは注入を手段とする攻撃方法であり、その中で最も有名でよく見られるのはSQL注入であり、実際にSQL注入を除いて、テキスト解析に基づくメカニズムはすべて注入攻撃を行うことができる.コマンドライン注入 XML注入 CRLF改行符号注入(Carriage Return Line Feed Injection) その発生の本質は、テキスト解析に基づくメカニズムでは、コードが悪意のあるコードであるか否かを見分けることができず、通常、テキスト解析の言語はコンパイルされないため、順番に読み取り、実行するだけである.
SQL注入の基本手段
SQL文の値をロック
or経由で常にTrue、またはand経由で常にFalse
SQL盲注
まずあるSQL文を推測して、それから実行したフィードバックの結果を通じて推測が正確かどうかを判断して、あるvalue値を入力すると仮定して、システムは正確な戻り結果を与えて、この時自分のSQL推測文judgeを書き出します
入力を行い、戻り結果がvalueと同じであればjudgeの推測が正しいことを示し、judgeの推測が間違っていれば
SQL注入の保護
注入類攻撃の核心原因が多くの言語の順序実行メカニズムとテキスト解析の本質であることがわかる以上、私はこのようなメカニズムを破るだけで注入攻撃の発生を防止することができる.
SQLの注入を例にして、JAVAの中のバインド変数などの方法で予防することができて、JAVAのバインド変数の方法はユーザーの入力を1種の変数として、SQL文に対してプリコンパイルを行って、このように実行する時順番に実行するのではありませんて、入力を1種の変数として処理に入って、実行する時に動態的なSQL文をつなぎ合わせることはできません悪意のある攻撃コードがSQL文に書き込まれることを防止して解析と実行を行う.
関連知識の準備
Webセキュリティを学ぶためにはまず一定のフロントエンド基盤を知る必要があり、フロントエンドは現在HTML+CSS+JSに分かれており、それぞれの用途は
HTTPを置くと、関連教科書を見たり、ブログの通俗的な説明をしたりすることができます.
最初の本
必ず基礎知識の備蓄を見てから本を読みに来なければならない.
入門第1冊の本は指導者に推薦されたのは白い帽子がWebの安全を話して、主に以下の章を読んで、および重点
3つの主要なセキュリティ問題
Webセキュリティにおける主な3つの問題は,Webセキュリティであるが,その考え方はいかなるネットワーク通信インタラクションのセキュリティ考慮にも用いることができることである.
まとめ
XSSとCSRFの共通点
HTTPとHTMLの基本的な概念を通じて、私たちは2つの点を知ることができます.
したがって、XSSおよびCSRFにおける「XS」および「CS」が表すCross Site(クロスステーション)の問題は、このようにしてwww.A.comのドメインの下でスクリプトによりwww.B.comのドメインの下に実行する過程である.
CSRFにおけるRequest Forge(偽造を要求する)は、このようなRequestメカニズムを利用していることがさらに明らかになった.
いくつかの用語の解釈
安全な投稿やディスカッションを見始め、最もよく見られるのは3つの言葉です:浸透/爆破/注入、ここで自分の理解を話します(間違っているかもしれません)
[爆破]と[注入]は2つの手段を指すが、[浸透]は異なる手段で[データ]または[権限]を取得する過程を指す.
爆破の本質は窮挙であり、正しいことを試みるまで試み続けた.注入の本質は正常な入力に悪意のあるコードを挿入し、テキスト解析のメカニズムを利用して非正常な論理の操作を実行することである.
これらのほかに、爬虫類などの用語もあります.私も入門したばかりで、あまり分かりません.
浸透の目的
もしあなたがハッカーであれば、浸透の主な目的はデータで、データは現在お金を売ることができて、もしあなたが白い帽子であれば、浸透の主な目的は権利を持って、浸透の過程の中で最高でどんな権限を得ることができるかを見て、それによって安全措置が適切かどうかを検査します.
XSSまとめ
XSSは反射型と貯蔵型に分けられ、主に注入の手段を通じて、正常なウェブページのテキストに悪意のあるコードを挿入し、ブラウザによるHTMLのテキスト解析メカニズムを利用して、非正常論理のスクリプトを実行する.
まず、XSSの発生に必要な条件をまとめ、反射型と貯蔵型を区別します.必要な条件は次のとおりです.
条件1の入力とは必ずしもラベルのテキストボックスタイプではない、選択欄、またはsubmitであってもよく、ツールによるintercept修正パラメータのみで、入力値を制御ことができる.
条件2は反射型と貯蔵型を区別する鍵であり、多くの本では「反射型は被害者が一度対話する必要があるが、貯蔵型被害者はリンクをクリックするだけでトリガーされる」ことで区別されている.実際に区別する点は、条件1の入力で、サイトが何らかの貯蔵手段で再提示されたときに他の人に伝達するかどうかで区別するほうがよい.
XSS防護の手段
HTMLまたはJSの[入力チェック]と[出力符号化]により、一般的な敏感文字を入力時にフィルタリングしたり、出力時にエスケープしたりする.HTMLページは読み取りとレンダリングの2つのプロセスに分かれているため、エスケープされた文字は、読み取りの過程で実行されず、レンダリングの過程でエスケープされた文字をエスケープし、ユーザーの理解に影響を与えない.
反射型XSSと格納型XSSの例
はんしゃがた
名前を入力するテキストボックスがあり、キーの提出を行うと、あなたの名前が戻ってきたページの内容に表示されます.このページを離れると、すべての入力が戻ってこないので、操作中に入力した名前だけが見えます.ここにXSS漏れ穴があれば、反射型です.
これは応答時間とは関係ありません.2時間後に結果を返すとしても、反射型です.彼は2つの条件が必要です.
きおくがた
名前を入力するテキストボックスがあり、提出すると、あなたの名前がサーバーに送られてデータベースに保存され、返された結果、すべてのデータベースの名前がページの内容に戻ります.このページを離れても、次に入力した名前にアクセスするのはこのページにあります.2回のアクセスだけでなく、他の人がこのサイトにアクセスしても見えます.XSSの脆弱性があれば、保存型です.
注意、ここはデータベースに保存することも、他の保存手段にすることもできます.つまり、サイトのメカニズムはあなたの入力をHTMLページ全体の内容の一部としています.よくあるのは伝言板で、みんなの伝言は中に保存されています.だから、保存型には一般的にこの2つの特徴があります.
CSRFまとめ
サイトをまたいで偽造を要求する核心の本質はユーザーのSessionを盗むことであり、あるいはCookieである.現在主流の状況ではSessionはCookieに存在するからである.攻撃者は被害者の具体的なアカウントとパスワードに関心を持たない.ユーザーが登録すると、Sessionはユーザーの唯一の証明であり、攻撃者がSessionを得ることができれば、被害者を偽装してサーバーに入ることができるからである.
HTMLのRequestメカニズムを利用して、攻撃者は被害者のwww.B.comドメイン名の下のウェブサイトに送信し、内部に悪意のある「src=www.A.com」のRequest命令が埋め込まれている.被害者がB.comを開くと、現在のブラウザはちょうどA.comにログインし、A.comのCookieをブラウザに入れている.では、B.comでRequestサイトA.comを降りると、A.comのSessionを持っていきます.サーバは、B.comの悪意のあるリクエストがユーザー自身が発行したものだと勘違いします.
このようなB.comの下で隠れたアクセスA.comはCSの跨局の意味であり、「src=」のこのような要求方式はA.comのSessionを持って行って、RF要求の偽造である.
CSRFの保護
CSRFが成功したのは、B.comがA.comのSessionを取り出したためであることが判明し、多くのブラウザはHttpOnlyタグを採用し、Cookieが別のドメインからJSスクリプトで取り出すことを防止している.しかし、B.comでは要求を偽造し、攻撃者は直接Sessionを手に入れるのではなく、被害者にA.comにログインしてSessionをブラウザに存在させるように誘導するだけである.
CSRFの一般的な主な目的は、ウェブサイトの管理者を攻撃することであり、管理者がバックドアとして新しい管理者ユーザを作成することによって、より多くの操作を行うことである.上述のようなCSRFの偽装行為は、CSRF+Tokenの方式であり、要求のたびにTokenの文字セグメントを追加して、ユーザ本人の操作であるかRequest Forgeかを検証する.
SQL注入まとめ
注入攻撃とは注入を手段とする攻撃方法であり、その中で最も有名でよく見られるのはSQL注入であり、実際にSQL注入を除いて、テキスト解析に基づくメカニズムはすべて注入攻撃を行うことができる.
SQL注入の基本手段
SQL文の値をロック
or経由で常にTrue、またはand経由で常にFalse
number OR 1=1
number AND 1=2
string' OR '1'='1
string' AND '1'='2
SQL盲注
まずあるSQL文を推測して、それから実行したフィードバックの結果を通じて推測が正確かどうかを判断して、あるvalue値を入力すると仮定して、システムは正確な戻り結果を与えて、この時自分のSQL推測文judgeを書き出します
value AND judge
入力を行い、戻り結果がvalueと同じであればjudgeの推測が正しいことを示し、judgeの推測が間違っていれば
SQL注入の保護
注入類攻撃の核心原因が多くの言語の順序実行メカニズムとテキスト解析の本質であることがわかる以上、私はこのようなメカニズムを破るだけで注入攻撃の発生を防止することができる.
SQLの注入を例にして、JAVAの中のバインド変数などの方法で予防することができて、JAVAのバインド変数の方法はユーザーの入力を1種の変数として、SQL文に対してプリコンパイルを行って、このように実行する時順番に実行するのではありませんて、入力を1種の変数として処理に入って、実行する時に動態的なSQL文をつなぎ合わせることはできません悪意のある攻撃コードがSQL文に書き込まれることを防止して解析と実行を行う.