Skip to content

Instantly share code, notes, and snippets.

@motoyasu-saburi

motoyasu-saburi/security-test-cheat-sheet.md

Last active February 13, 2021 10:04
Show Gist options
  • Save motoyasu-saburi/20b0aaf807c0cd8d74ca438af7f3e0d7 to your computer and use it in GitHub Desktop.
Save motoyasu-saburi/20b0aaf807c0cd8d74ca438af7f3e0d7 to your computer and use it in GitHub Desktop.
Download ZIP
セキュリティテスト自分用メモ
Raw
security-test-cheat-sheet.md

Security test cheat sheet

check list

  • XSS
  • SQL Injection
  • HTTP Injection
  • Command Injection
  • ディレクトリトラバーサル
  • ファイルアップロード
  • Paramter Manipulation
  • Open Redirect
  • アカウントロック
  • ログアウト
  • ログインフォーム
  • ログインエラーメッセージ
  • 個人情報の外部送受信
  • Cookieの有効期限
  • 認証の回避
  • 権限昇格
  • 権限のない情報へのアクセス
  • Http-Only secure属性
  • セッションIDのランダム性
  • Session Fixed
  • セッションの強制指定
  • CSRF
  • Server Error Message
  • システム情報の開示
  • 既知のソフトウェア脆弱性
  • 強制ブラウジング
  • ディレクトリリスティング
  • etc

Payload List　（Cheat Sheet)

網羅的にまとまっている
https://github.com/swisskyrepo/PayloadsAllTheThings https://github.com/EdOverflow/bugbounty-cheatsheet https://github.com/OWASP/CheatSheetSeries https://github.com/ngalongc/bug-bounty-reference https://github.com/danielmiessler/SecLists

XSS
https://github.com/s0md3v/AwesomeXSS https://github.com/cujanovic/Markdown-XSS-Payloads

XSS (FrontEnd Template Injection (mustacheと呼ばれる {{}} という記法)
https://github.com/cure53/mustache-security/tree/master/wiki

Open Redirect
https://github.com/cujanovic/Open-Redirect-Payloads

CRLF Injection
https://github.com/cujanovic/CRLF-Injection-Payloads

SSRF
https://github.com/cujanovic/SSRF-Testing

Java Unsafe Deserialization
https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet

Black Box Test

SSRF

intranet IP range (RFC 1918) 0.0.0.0 – 10.255.255.255, 172.16.0.0–172.31.255.255, 192.168.0.0–192.168.255.255

AWS meta data http://169.254.169.254/latest/meta-data/

よく利用するPortと合わせて調べる

21, (FTP)
22, (SSH)
80, (Web)
443, (SSL Web)
8080, (Proxy)

text ベースのSSRFもあるため、以下のパラメータパターンも試すと良いかも。

  • file:// — Accessing local filesystem
  • http:// — Accessing HTTP URLs
  • ftp:// — Accessing FPP URLs
  • php:// — Accessing values I/O stream
  • data:// — Data Protocol(RFC 2397)
  • phar:// — PHP Archive
  • gopher:// — A protocol designed for dictionary based menu(File Distribution)
  • dict:// — Dictionary network Protocol
  • ldap:// - LDAP

S3 の権限チェック

S3 の権限チェック http://flaws.cloud/ S3 の read, write 権限で everyone, Any Authenticated AWS User のどちらかが指定されていないかを確認する

  1. S3のIP確認 dig +nocmd DOMAIN_NAME any +multiline +noall +answer
  2. awsホストのリージョンなどを確認 nslookup IP
  3. --no-sign-request でS3のリストが取れるか aws s3 ls s3://S3-DOMAIN-NAME.com/ --no-sign-request --region ap-northwest-1
  4. 適当なAWSアカウントにてS3の権限があるか aws s3 --profile YOUR_ACCOUNT ls s3://S3-DOMAIN-NAME.com
  5. 権限がある場合はS3のデータを同期させて機密データがないかを確認 aws s3 sync s3://S3-DOMAIN-NAME.com/ . --no-sign-request --region ap-northeast-1

White Box Test

以下はJavaを例としているが、IDEの中に組み込めるセキュリティ系の静的コード解析ツールの検出タイプ一覧が日本語でまとまっているため、 何が、どのようにして脆弱性となるのかが網羅的にまとまっている。

http://find-sec-bugs.github.io/bugs_ja.html

XSS

当たり前だが、jQueryとか低レイヤーなjavascriptのAPIで直接DOMを弄ったり、 サーバサイドレンダリングでエスケープ処理せずパラメータ出力したり、 動的にAngularなどテンプレート書き出しするとXSSが発生する（最後のはテンプレートインジェクションとかな気はするけど。）

Angular.js

https://portswigger.net/blog/xss-without-html-client-side-template-injection-with-angularjs ?ver=12 などに ?ver=12{{8*8}} で演算されたるかで最終的には判定。 基本XSSが発生しにくい構造となっているが、サーバサイドのテンプレートエンジンのファイルを見て、 Angularのテンプレートを動的生成している場所や、APIとかでHTMLを返してfetchしている箇所を探す。　　 ng-app の中で {{}} といった記法が記入できるとできるかも。 フロントのバージョン確認はこちらが良さそう　https://qiita.com/mixplace/items/44df9226c2e4c5df7384

Vue.js

https://gist.github.com/motoyasu-saburi/7ffee217f74229c0093f463f10e60457 上記のVueのイベントハンドラ(?)を利用している箇所をgrepし、動的パラメータが入っていないかチェック

React

(正直知見が少ない。)

https://ooooooo.hatenablog.com/entry/2016/12/13/071514

  • リンクに javascript:alert(0) などが指定できるケース
  • cssが自由に記述できて expression() が出来るケース（IEのみ)

https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml dangerouslySetInnerHTML 危ないメソッド利用もあるけど流石に利用されないと思う。

https://blog.ssrf.in/post/modern-javascript-framework-xss/ React.createElement に propsを直接入れるとXSSが起こせる

const props = JSON.parse('{"name": {"dangerouslySetInnerHTML" : { "__html": "<svg/onload=alert(1)>"}}}');
ReactDOM.render(React.createElement("p", props.name), document.getElementById('root'))

Knockout.js

http://www.levigross.com/2014/06/11/how-to-find-xss-in-knockout.js-applications/ data-bind=html: <p>a</p> となっている属性を探す。これはKnockoutが内部でinnerHtmlを叩いているだけ（らしい）。 対象となるデータの属性は以下

  • html
  • CSS
  • style
  • attribute

以下のコメントアウトも遅延評価するため、ifの中身でXSSが発生することもあるとか。

<!-- ko if: {{ user_control_var }} -->
<!-- /ko -->

OS Command Injection

各言語のOS Command実行メソッドを記載 grep できるレベルの粒度（１行程度）を記載 （殆ど import文が対象になるが、実行をしているかは中身をしっかり読むこと。）

Java

import java.lang.Runtime; 
import java.lang.Process;
new ProcessBuilder("ls", "-l").start();

Scala

import sys.process._

Ruby

system('mkdir hoge')
`date` # バッククォートパターン
IO.popen("cat", "r+") { ...
require "open3"
require "systemu"

PHP

exec('ls');
shell_exec('ls');
escapeshellcmd('ls');

Go lang

import "os/exec"

nginx

https://qiita.com/no1zy_sec no1zy_sec 氏 nginxのセキュリティツール gixy 　に記載されたドキュメント (https://github.com/yandex/gixy/tree/master/docs/en/plugins) を翻訳しているので参照

HTTP Splitting (HTTP Header Injection)

nginx のconfigで以下を検索 rewrite, add_header, proxy_set_header, proxy_pass

該当箇所が以下のような場合に置いて、　action でマッチした部分に %0d%0a の文字が改行が発生する

location ~ /v1/((?<action>[^.]*)\.json)?$ {
  add_header X-Action $action;
  return 200 "OK";
}

GET /v1/hogehoge%0d%0ahttp-header-injection:true.json

SSRF

proxy_pass の第２引数が攻撃者が指定可能な場合にSSRFが発生させられるかも。

location ~ /proxy/(.*)/(.*)/(.*)$ {
    proxy_pass $1://$2/$3;
}

この場合マッチした2番目に$2が入る。以下のようなリクエストを投げると外部にプロキシーで処理させようとするのでSSRFできる(?) GET /proxy/http/evilexample-xxxxxx.com/hoge

Origin, Referrerの検証不備

$http_origin, $http_referer の ifディレクティブで利用される正規表現を確認し、誤りがないかをチェック

if ($http_origin ~* ((^https://www\.yandex\.ru)|(^https://ya\.ru)$)) { ...

パストラバーサル

location にて指定しているパスの末尾に / がない場合、パストラバーサルになる場合がある （なので ``）

location /i {
    alias /data/w3/images/;
}

この場合 GET /i../app/config.py で　/data/w3/app/config.py のファイルが送られることになる。 正規表現で location(.+)[^\/\s]\s*{ とかでマッチしたやつを見て同じような奴がないか調べる。 （雑なので違う奴も結構引っかかる。）

Host Header Forgery

$host の代わりに $http_host を利用していると Hosst Header Forgeryがおこるかも proxy_set_header Host $http_host;

$http_host ではリクエストヘッダのHostを参照するためそこに不正な値が入ると問題が起きる。 $http_host の代わりに常に $host を利用すると良い

SSRF

AWS

AWS EC2 では、対象インスタンスのメタデータを取得できるAPIが存在する。 そのため、SSRFがあった場合は次のURIなどで、対象クレデンシャルを取得できる。 http://169.254.169.254/latest/meta-data/iam/security-credentials/

kubernetes

EC2 から、Dockerによる運用の流れが起きており、これによって、一つ上にあげた、AWS EC2を対象としたSSRFなどが通用しにくくなった。 しかし、Kubernetes などでも、同様の攻撃ができる（らしいが、試していない）。

元ツイート: https://twitter.com/akhilreni_hs/status/1179833758041526272 次のエンドポイントを (AWS) ECS /proc/self/environ で送ると、UUIDが取得できる。 その後、次のエンドポイントにリクエストを投げると、クレデンシャルが取得できる。 http://169.254.170.2/v2/credentials/<UUID> これでアタッチされたロールのIAM Keyが取得できる。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment