Shikata Ga Nai

Private? There is no such things.

arachniのPassive Scanについてリストしてみた

Hello there, ('ω')ノ

 

脆弱性診断ツールごとに機能を把握しようと思って。

まずは、arachniのPassive Scanについてメニューからリストアップすることに。

 

 

f:id:ThisIsOne:20200223161953p:plain

 

■Code injection
 コードインジェクション

 ⇨ Injects code snippets and assess whether or not execution was successful.
   コードスニペットを挿入し、実行が成功したかどうかを評価します。

 

 

■Code injection (php://input wrapper)
 コードインジェクション

 ⇨ Injects PHP code into the HTTP request body and uses the php://input wrapper to try and load it.
   HTTPリクエストの本文にPHPコードを挿入し、php://input wrapperを使用してそれをロードしようとします。

 

 

■Code injection (timing)
 コードインジェクション

 ⇨ Injects code snippets and assess whether or not the injection was successful using a time delay.
   コードスニペットを注入し、時間遅延を使用して注入が成功したかどうかを評価します。

 

■CSRF (csrf)

 ⇨ It uses differential analysis to determine which forms affect business logic and checks them for lack of anti-CSRF tokens.
   差分分析を使用して、ビジネスロジックに影響するフォームを判断し、CSRFトークンがないことを確認します。


■File Inclusion

 ⇨ Injects paths of common files (like /etc/passwd and boot.ini) and evaluates the existence of a file inclusion vulnerability based on the presence of relevant content or errors in the HTTP response body.
   一般的なファイル(/etc/passwd and boot.iniなど)のパスを挿入し、関連するコンテンツの存在またはHTTP応答本文のエラーに基づいて、ファイル包含の脆弱性の存在を評価します。

 


■LDAP Injection

 ⇨ It tries to force the web application to return LDAP error messages, in order to discover failures in user input validation.
   ユーザー入力の検証の失敗を発見するために、Webアプリケーションに強制的にLDAPエラーメッセージを返させようとします。

 

■NoSQL Injection
 NoSQLインジェクション

 ⇨ NoSQL injection check, uses known DB errors to identify vulnerabilities.
   NoSQLインジェクションチェックは、既知のDBエラーを使用して脆弱性を識別します。

 

■Blind NoSQL Injection (differential analysis)
 ブラインドNoSQLインジェクション(差分分析)

 ⇨ It uses differential analysis to determine how different inputs affect the behavior of the web application and checks if the displayed behavior is consistent with that of a vulnerable application.
   差分分析を使用して、さまざまな入力がWebアプリケーションの動作にどのように影響するかを判断し、表示される動作が脆弱なアプリケーションの動作と一致しているかどうかを確認します。

 

■OS command injection
 OSコマンドインジェクション

 ⇨ Tries to find Operating System command injections.
   オペレーティングシステムのコマンドインジェクションを見つけようとします。

 

 

■OS command injection (timing)
 OSコマンドインジェクション

 ⇨ Tries to find operating system command injections using timing attacks.
   タイミング攻撃を使用して、オペレーティングシステムのコマンドインジェクションを見つけようとします。

 

 

■Path Traversal
 パストラバーサル

  ⇨ It injects paths of common files ( like /etc/passwd and boot.ini) and evaluates the existence of a path traversal vulnerability based on the presence of relevant content in the HTML responses.
   一般的なファイル(/etc/passwd and boot.iniなど)のパスを挿入し、HTML応答の関連コンテンツの存在に基づいてパストラバーサルの脆弱性の存在を評価します。

 

■Response Splitting
 応答の分割

 ⇨ Injects arbitrary and checks if any of them end up in the response header.
   任意を挿入し、それらのいずれかが応答ヘッダーに含まれるかどうかを確認します。

 

 

■Remote File Inclusion (rfi)
 リモートファイルインクルージョン

 ⇨ Injects a remote URL in all available inputs and checks for relevant content in the HTTP response body.
   利用可能なすべての入力にリモートURLを挿入し、HTTP応答本文の関連コンテンツをチェックします。

 

■Session fixation
 セッション固定

 ⇨ Checks whether or not the session cookie can be set to an arbitrary value.
   セッションCookieを任意の値に設定できるかどうかを確認します。

 

 

■Source code disclosure
 ソースコードの開示

 ⇨ It tries to identify whether or not the web application can be forced to reveal source code.
   Webアプリケーションにソースコードの公開を強制できるかどうかを識別しようとします。

 

 

■SQL Injection (sql_injection)
 SQLインジェクション

 ⇨ SQL injection check, uses known SQL DB errors to identify vulnerabilities.
   SQLインジェクションチェック。既知のSQL DBエラーを使用して脆弱性を特定します。

 

■Blind SQL Injection (differential analysis)
 ブラインドSQLインジェクション(差分分析)

 ⇨ It uses differential analysis to determine how different inputs affect behavior of the web application and checks if the displayed behavior is consistent with that of a vulnerable application.
   差分分析を使用して、さまざまな入力がWebアプリケーションの動作にどのように影響するかを判断し、表示される動作が脆弱なアプリケーションの動作と一致しているかどうかを確認します。

 

 

 

■Blind SQL injection (timing attack)
 ブラインドSQLインジェクション(タイミング攻撃)

 ⇨ Blind SQL Injection check using timing attacks.
   タイミング攻撃を使用したブラインドSQLインジェクションチェック。

 

 

■Trainer
 トレーナー

 ⇨ Pokes and probes all inputs of a given page in order to uncover new input vectors. It also forces Arachni to train itself by analyzing the server responses.
   新しい入力ベクトルを発見するために、特定のページのすべての入力を調べてプローブします。また、サーバーの応答を分析することにより、Arachni自身を訓練させます。

 


■Unvalidated redirect
 未検証のリダイレクト

 ⇨ Injects URLs and checks the Location HTTP response header field and/or browser URL to determine whether the attack was successful.
   URLを挿入し、Location HTTP応答ヘッダーフィールドやブラウザURLをチェックして、攻撃が成功したかどうかを判断します。

 

 

■Unvalidated DOM redirect
 未検証のDOMリダイレクト

 ⇨ Injects URLs and checks the browser URL to determine whether the attack was successful.
   URLを挿入し、ブラウザのURLをチェックして、攻撃が成功したかどうかを判断します。

 

■XPath Injection
 XPathインジェクション

 ⇨ XPath injection check
   XPathインジェクションチェック

 

■XSS (xss)

 ⇨ Injects an HTML element into page inputs and then parses the HTML markup of tainted responses to look for proof of vulnerability.
   HTML要素をページ入力に挿入し、汚染された応答のHTMLマークアップを解析して、脆弱性の証拠を探します。


■DOM XSS

 ⇨ Injects an HTML element into page DOM inputs and then parses the HTML markup of tainted responses to look for proof of vulnerability.
   HTML要素をページDOM入力に挿入し、汚染された応答のHTMLマークアップを解析して脆弱性の証拠を探します。


■DOM XSS in script context
 スクリプトコンテキストのDOM XSS

 ⇨ Injects JS taint code and checks to see if it gets executed as proof of vulnerability.
   JS汚染コードを挿入し、脆弱性の証拠として実行されるかどうかを確認します。

 

 

■XSS in HTML element event attribute
 HTML要素のXSSイベント属性

 ⇨ Cross-Site Scripting in event tag of HTML element.
   HTML要素のイベントタグでのクロスサイトスクリプティング。

 

■XSS in path
 パス内のXSS

 ⇨ Cross-Site Scripting check for path injection
   パスインジェクションのクロスサイトスクリプティングチェック

 

■XSS in script context
 スクリプトコンテキストのXSS

 ⇨ Injects JS taint code and check to see if it gets executed as proof of vulnerability.
   JS汚染コードを挿入し、脆弱性の証拠として実行されるかどうかを確認します。

 

■XSS in HTML tag
 HTMLタグのXSS

 ⇨ Cross-Site Scripting in HTML tag.
   HTMLタグのクロスサイトスクリプティング。

 

■XML External Entity
 XML外部エンティティ

 ⇨ Injects a custom External Entity into XML documents prior to submitting them and determines the existence of a vulnerability by checking whether that entity was processed based on the resulting HTTP response.
   送信する前にカスタム外部エンティティをXMLドキュメントに挿入し、結果のHTTP応答に基づいてそのエンティティが処理されたかどうかを確認することにより、脆弱性の存在を判断します。

 

 

Best regards, (^^ゞ