Webセキュリティの問題と解決策

現在よく見られるWebセキュリティの問題は以下のとおりです.

ソースポリシー

XSS

CSRF

SQL注入

クリックハイジャック

window.Openerセキュリティの問題

ファイルアップロードの脆弱性

どうげんせんりゃく
両方のURLのプロトコル、ドメイン名、ポートが同じであれば、同源と呼びます.

同源ポリシーは、異なるソースからのJSスクリプトによる現在のDOMオブジェクトの読み書き操作を制限する.

同源ポリシーは、異なるソースのサイトから現在のサイトを読み出すCookie、LocalStorageなどの操作を制限します.

同源ポリシーは、XMLHttpRequestなどの方法でサイトのデータを異なるソースのサイトに送信することを制限する.

対応する解決方法:

ドメイン間リソース共有(CORS):サービス側はドメイン間リソース許可ドメイン間リソースを設定します.

コンテンツセキュリティポリシー(CSP):信頼できるコンテンツソースをホワイトリスト形式で構成します.

ドキュメント間メッセージメカニズム:window.postMessageは、異なるソースのDOMと通信することができる.

XSS
クロススタンドスクリプト攻撃(Cross Site Scripting)
1,ストレージ型XSS攻撃
ストレージ型XSSは、脆弱性を利用して悪意のあるJSコードを提出し、例えば入力可能な領域に悪意のあるscriptラベルを入力してサーバに提出し、ユーザーがウェブサイトを開くと悪意のあるスクリプトが実行してユーザー関連情報を取得する.
2,反射型XSS攻撃
反射型XSSは、ユーザーが入力したデータを簡単にブラウザに「反射」するだけで、攻撃者が悪意のあるリンクをクリックしたり、フォームを提出したり、悪意のあるサイトに入ったりするときに、スクリプトを注入して攻撃者のサイトに入る必要があることが多い.よく使われる手段は、例えばメールやグループなどのルートを通じてクリックを誘導する.
3,DOMによるXSS攻撃
DOMベースのXSS攻撃とは,悪意のあるスクリプトによりページを修正するDOM構造であり,クライアントで発生する攻撃である.
4、予防策

クッキーなどの機密情報をhttponlyに設定し、ブラウザはページのJavascriptからHttpOnly属性のあるCookieへのアクセスを禁止します.

入力チェック、ユーザーの入力を信じないでください.すべての入力に対して厳格な検査を行う.

出力チェックでは,ユーザの入力に問題があり,サービス側の出力にも問題がある.

特殊文字のエスケープまたはフィルタ

CSP(Content Security Policy)、コンテンツセキュリティポリシー.信頼できるコンテンツソースをホワイトリスト形式で構成します.

CSP構成方式:

// meta


// HTTP  
Content-Security-Policy: script-src 'unsafe-inline' 'unsafe-eval' 'self' *.domain.cn *.domain.com;report-uri /error/csp

CSRF(Cross-site request forgery)
中訳はクロスステーション要求偽造であり、信頼されたユーザをハイジャックしてサーバに予期せぬ要求を送信する攻撃方式である.通常、CSRF攻撃は、攻撃者が被害者のCookieによってサーバの信頼をだまし取るものであり、被害者が何も知らないうちに被害者名義で偽造要求を攻撃サーバに送信し、権限保護下での操作を許可なく実行することができる.
予防策:

検証コード、検証コードはCSRF攻撃に対抗する最も簡潔で有効な防御方法とされている.しかし、最も主要な解決策としてはならない.

Referer Check.HTTPプロトコルによれば、HTTPヘッダには、そのHTTP要求のソースアドレスが記録されたReferというフィールドがある.Refer Checkでは、要求が正当な「ソース」から来ているかどうかを確認できます.

token検証を追加します.CSRF攻撃が成功したのは、ハッカーがユーザーの要求を完全に偽造することができるためであり、この要求の中のすべてのユーザー検証情報はクッキーに存在するため、ハッカーはこれらの検証情報を知らないままユーザー自身のクッキーを直接利用してセキュリティ検証を通過することができる.したがってCSRFを防ぐには,要求にハッカーが偽造できない情報を入れ,クッキーに存在しないことが重要である.HTTPリクエストには、ランダムに生成されたtokenをパラメータとして追加し、このtokenを検証するためにサーバ側にブロッキングを確立することができ、リクエストにtokenまたはtokenの内容が正しくない場合は、CSRF攻撃である可能性があると判断してリクエストを拒否する.

SameSite.CookieのSameSite属性にはStrict,Lax,Noneの3つの値がある.Sreict-ブラウザはサードパーティCookieを完全に禁止します.LaxLax-比較的ゆったりしています.サイト間では、サードパーティサイトからのリンクが開いているか、サードパーティサイトからGet方式のフォームが発行されているかの2つの方法でCookieが携帯されます.ただし、サードパーティサイトでPostメソッドを使用したり、img、iframeなどのラベルでロードされたURLを使用したりすると、これらのシーンはCookieを携帯しません.None-Cookieデータはどんな場合でも送信されます.

SQL注入
ちゅうにゅうモード
SQLインジェクションの攻撃方法は、アプリケーションがデータベースから返されるコンテンツを処理することによって、明示的なインジェクション、エラーインジェクション、ブラインドインジェクションに分けられます.
1、注入可能:攻撃者は直接に現在のインタフェースの内容の中で獲得したい内容を獲得することができる
2、エラーメッセージ注入:データベースクエリの返信結果はページに表示されないが、アプリケーションがデータベースエラーメッセージをページに印刷したため、攻撃者はデータベースエラー文を構築し、エラーメッセージから取得したい内容を取得することができる
3、盲注:データベースの検索結果は直感的なページから取得できない.攻撃者はデータベースロジックやデータベースライブラリの実行遅延などの方法で取得したい内容を取得する
予防策:

不要なデータベースエラー情報

を削減する.

ターゲットサイトが動的に文字列をつなぎ合わせる方式でデータベース

にアクセスすることを禁止する.

データベース権限

SQLリザーブ

のフィルタリングと浄化
ハイジャックをクリック
名前の通り、ユーザーはボタンをクリックしたが、ユーザーの本当の意思ではないイベントをトリガーした.
予防策:
1,JSはターゲットサイトに埋め込むページに以下のコードを追加することを禁止し、topを使用することもできる.location.名前とself.location.hostnameで判断する

script>
    if (top.location != window.location) {
        top.location = window.location;
    }

2.サービス側は、ブラウザにページをまたはに許可するかどうかを示すX-Frame-Options応答ヘッダを追加する