- XSS
- SQL Injection
- HTTP Injection
- Command Injection
- ディレクトリトラバーサル
- ファイルアップロード
- Paramter Manipulation
- Open Redirect
- アカウントロック
- ログアウト
- ログインフォーム
- ログインエラーメッセージ
- 個人情報の外部送受信
- Cookieの有効期限
- 認証の回避
- 権限昇格
- 権限のない情報へのアクセス
- Http-Only secure属性
- セッションIDのランダム性
- Session Fixed
- セッションの強制指定
- CSRF
- Server Error Message
- システム情報の開示
- 既知のソフトウェア脆弱性
- 強制ブラウジング
- ディレクトリリスティング
- etc
網羅的にまとまっている
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
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 の権限チェック
http://flaws.cloud/
S3 の read, write 権限で everyone
, Any Authenticated AWS User
のどちらかが指定されていないかを確認する
- S3のIP確認
dig +nocmd DOMAIN_NAME any +multiline +noall +answer
- awsホストのリージョンなどを確認
nslookup IP
- --no-sign-request でS3のリストが取れるか
aws s3 ls s3://S3-DOMAIN-NAME.com/ --no-sign-request --region ap-northwest-1
- 適当なAWSアカウントにてS3の権限があるか
aws s3 --profile YOUR_ACCOUNT ls s3://S3-DOMAIN-NAME.com
- 権限がある場合はS3のデータを同期させて機密データがないかを確認
aws s3 sync s3://S3-DOMAIN-NAME.com/ . --no-sign-request --region ap-northeast-1
以下はJavaを例としているが、IDEの中に組み込めるセキュリティ系の静的コード解析ツールの検出タイプ一覧が日本語でまとまっているため、 何が、どのようにして脆弱性となるのかが網羅的にまとまっている。
http://find-sec-bugs.github.io/bugs_ja.html
当たり前だが、jQueryとか低レイヤーなjavascriptのAPIで直接DOMを弄ったり、 サーバサイドレンダリングでエスケープ処理せずパラメータ出力したり、 動的にAngularなどテンプレート書き出しするとXSSが発生する(最後のはテンプレートインジェクションとかな気はするけど。)
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
https://gist.github.com/motoyasu-saburi/7ffee217f74229c0093f463f10e60457 上記のVueのイベントハンドラ(?)を利用している箇所をgrepし、動的パラメータが入っていないかチェック
(正直知見が少ない。)
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'))
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実行メソッドを記載 grep できるレベルの粒度(1行程度)を記載 (殆ど import文が対象になるが、実行をしているかは中身をしっかり読むこと。)
import java.lang.Runtime;
import java.lang.Process;
new ProcessBuilder("ls", "-l").start();
import sys.process._
system('mkdir hoge')
`date` # バッククォートパターン
IO.popen("cat", "r+") { ...
require "open3"
require "systemu"
exec('ls');
shell_exec('ls');
escapeshellcmd('ls');
import "os/exec"
https://qiita.com/no1zy_sec
no1zy_sec 氏 nginxのセキュリティツール gixy
に記載されたドキュメント (https://github.com/yandex/gixy/tree/master/docs/en/plugins)
を翻訳しているので参照
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
proxy_pass
の第2引数が攻撃者が指定可能な場合にSSRFが発生させられるかも。
location ~ /proxy/(.*)/(.*)/(.*)$ {
proxy_pass $1://$2/$3;
}
この場合マッチした2番目に$2が入る。以下のようなリクエストを投げると外部にプロキシーで処理させようとするのでSSRFできる(?)
GET /proxy/http/evilexample-xxxxxx.com/hoge
$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
の代わりに $http_host
を利用していると Hosst Header Forgeryがおこるかも
proxy_set_header Host $http_host;
$http_host
ではリクエストヘッダのHostを参照するためそこに不正な値が入ると問題が起きる。
$http_host
の代わりに常に $host
を利用すると良い
AWS EC2 では、対象インスタンスのメタデータを取得できるAPIが存在する。
そのため、SSRFがあった場合は次のURIなどで、対象クレデンシャルを取得できる。
http://169.254.169.254/latest/meta-data/iam/security-credentials/
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が取得できる。