『脅威インテリジェンスの教科書』を読んだ

感想

  • 全体的に見ると業務に生かせそうな箇所は少なかった。実践的な内容ではない、ということでは無い。
  • 参考文献が多い。圧倒的情報量。
  • 2章はセキュリティ担当者向けということもあって自分の業務に親和性の高い内容だった。脆弱性管理について教科書的に学んだことがなかったので勉強になった。実際には適切なツールを導入すると良いのだろう。資産重要度・危険度を把握して適切に管理できるようにしたい。
  • Part 3の応用編は読み物として楽しんだ。特に8章で漫画村の事例は、自分の記憶にも残っていた出来事だったため面白かった。参考文献から首謀者特定に至るまでの話が完全に映画だった。映画化しないかな。

『「Auth0」で作る!認証付きシングルページアプリケーション』を読んだ

感想

  • 2018年出版ということもあり所々躓いたものの概ね最後まで完走できた。githubログインはどういうわけかAccess Deniedが面倒になって投げた。
  • auth0が気になったため一度触ってみたかったので手に取った。auth0便利という感じ。これがIDaaSか。

躓いたところ

  • gem knockが古い
    • rails6.1.4.1で動かすとzeitwerk起因のエラーになる
    • branch: master指定で動いた
  • heroku cliのインストール
    • brew installでは入らなかった
    • ここを見よう
  • git push heroku masterはできない
    • mainに読み替え
  • herokuデプロイ
    • bundle installでplatformがどうのでエラーが出たがメッセージの通りbundle lockすればOK
  • nodejsのバージョンに合致したライブラリが見つからずyarn installがこけた
    • nodejsもyarnも最新バージョンに合わせればOK

『リアルワールドバグハンティング』を読んだ

感想

  • バグバウンティの入門書としてもオススメの一冊だった。特に19章と20章。
  • 付録の多くが知らないものばかりだった。付録だけでも読む価値あり。
  • 誤植が多いのがストレスだった。ちょっと多い。。
  • 各章で忍耐というキーワードが出てくるが本当にその通りだと思った。バグバウンティに限らない問題解決一般に当てはまる金言。
  • 以下は概要のみ知っていて知見が少ない状態なので手を動かして理解を深めたい。
    • SSRF(10章)
    • XXE(11章)
    • サブドメインテイクオーバー(14章)
    • OAuth(17章)
    • その他
      • 2要素認証
      • SSL
  • メモリの脆弱性(13章)は今携わっているレイヤを考えるとまだ深入りしなくて良さそう。

以下、興味深かった点のメモ。

1章

  • オープンリダイレクトのパターン
    • クエリパラメータ
    • XSS(window.location)
    • metaタグ(meta refresh)

3章

  • formのtarget属性でレスポンスの表示箇所を指定できる

6章

14章

18章

誤植

  • 1.3.5: application/octed-stream→application/octet-stream(P.5 12行目)
  • 1.4.1: URLの一種です→URIの一種です(P.8 2-3行目)
  • 4章: カウント→アカウント(P.29 6行目)
  • 6.2
    • ところどころlast_shopパラメータとしているが、正しくは/last_shopのshopパラメータ(P.54 - P.55)
  • 7.1: login/logout CSFRF→login/logout CSRF(P.65)
  • 10.5: Emtertaiment→Emtertainment(P.107)
  • 14.1: レコー ドはサイト名を1つ以上のIPアドレスに対応付けます→Aレコー ドはサイト名を1つ以上のIPアドレスに対応付けます(P.151)
  • 14.7: Modules→Modulus(P.157)
  • 14.7: Lefal Robot→Legal Robot(P.157)
  • 14.7: Roesn→Rosen(P.157)
  • 14.7: api.legailrobot.com→api.legalrobot.com(P.157)
  • 14.8: XML→MX(P.159)
  • 15.4: 報償→報奨 or 報酬(P.167)
    • 報償は「つぐない」を表すので不自然なのでは
  • 16.2: 報償→報奨 or 報酬(P.170)
    • 同上
  • 17.4: アプリケーションはhttps://outlook.office.com%fは正当なURLではないと するエラーを返しました→アプリケーションはhttps://outlook.office.com%2fは正当なURLではないと するエラーを返しました(P.186)
  • 17.4.1: それを完全に書き変えたときときとで→それを完全に書き変えたときとで(P.187)
  • 18.4: Amazon Simple Store Services→Amazon Simple Storage Services(P.196)
  • 18 - 19章: memcache→memcached
  • 20.4: 忘がち→忘れがち(P.260)

Amazonの配送業者が投函方法を間違えた件のポストモーテム

概要

Amazon配送業者が宅配ボックスに違う部屋番号を入力して投函した。

経緯と状況

  • Amazonで本を注文
  • 宅配ボックスに投函したとメールが来たため、確認すると投函先部屋番号を誤っていた
  • 郵便受けには不在票が入っており「部屋番号を間違えました、すみません」というような趣旨のことが書かれていた
  • 投函された時間帯にAmazonの配送業者(050-3131-1651)から電話が入っていたが、気づかなかったため取れなかった

イベント

Amazon配送業者に折り返す

カスタマーサポートへの連絡はwebサイトを参照してください、との自動音声が流れるのみ。

マンションの管理会社に電話

部屋番号ごとに宅配ボックスの暗証番号が決められているため、当然違う部屋の住人は知る由もない。そのためマンション管理会社のコールセンターにかけてみた。ひたすら繋がりづらい。繋がったのち担当者に状況を伝えると、

  • 部屋ごとの宅配ボックスの暗証番号は把握していないため担当部署に問い合わせる必要がある
  • しかし担当部署は定休日で、明日以降の対応になる
  • できれば自分で間違えた先の部屋に訪問して、宅配ボックスを開けてもらうのが一番早い

とのことだった。

間違えた先のお部屋に訪問

出なかった。

Amazonカスタマーサポートに連絡

サポートはこちら。

https://www.amazon.co.jp/gp/css/contact-us-access/ref=hp_202003590_ta

チャットで状況を入力し、もろもろの回答ののち「解決しない」を選ぶと電話サポートかチャットサポートを選ぶことになる。最初電話を選んだが、混み合っているためチャットにしてくれと表示された。チャットを選ぶとすぐに担当者と会話が始まった。問い合わせ先が違ったようで他担当にフォワードされたがとにかく対応が早かった。結果配送業者に連絡してくれる運びとなり、何か状況が分かったらメールしてくれることになった。大変ホスピタリティ溢れる対応だった。プロという感じ。カスタマーサポートすごい。

配送業者から連絡がある

上記の状況を伝えたところ配送業者の次のアクションとして以下が決まった。

  • 夕方か夜に間違えた先の部屋に訪問して宅配ボックスを空けてもらう
  • 上記でダメならマンション管理会社に連絡する

届く

翌日夜に届いた。

私が改善できそうなこと

同じマンションの人間と仲良くなっておく

書いてみたが現実的では無い。もし仲が良かったら訪問時に応えてくれたかもしれない。

初手の段階でAmazonカスタマーサポートに連絡する

面倒なあれこれをやってもらうにはこれが一番。他責なので自分で解決することもない。ググるAmazonのポイントを貰えたとの報告も。

『プログラムはなぜ動くのか』を読んだ

感想

2版は物理で買って数年前に読んでいた。最近3版が出たことと、CPUを作りたい欲が出てきたので、一度この辺りの仕組みをもう一度おさらいしようと思って買った。内容を完璧に理解したわけではないが、概ね分かっていた内容が多かったため特段感想が無い。6章だけ浮いた話題だったのは気になった。次は手を動かす系の本を読むとする。

誤植

報告先は明記されていなかった。

  • 10章 リスト10-4 (3): esp + 4番地にあるデータを eax に格納する→esp + 4番地にあるデータを eax に加算する(No.2852)
  • 10章 リスト10-12 4行目 goto BB2_2→goto LBB2_2(No.3982)
  • COLUMN 近所のおばあちゃんにディスプレイとテレビの違いを説明する: ディルプレイ→ディスプレイ(No.3337)
  • 補章1: avegrage→average(No. 3709)
  • 補章1: リストA-4 コード2行目 avegare→average(No. 3709)
  • 補章1: リストA-4 コード8行目 avegare→average(No. 3709)
  • 補章1: リストA-5 コード3行目 avegare→average(No. 3743)
  • 補章1: リストA-5 コード10行目 avegare→average(No. 3743)

rubyをgdbでデバッグする

公式のrubyイメージ(debian)を使う。

$ docker run --rm -it ruby:3.1.0 bash

以下は全てコンテナ内で実行するコマンド。
手順はこちらを参考にした。
なかなかに時間がかかる。

$ cd ~
$ git clone https://github.com/ruby/ruby
$ cd ruby
$ git switch ruby_3_1
$ autoreconf
$ ./configure optflags="-O0"
# 後のmakeで必要になる。rubyの構文解析に使っている。
$ apt update && apt install -y bison
$ make
$ make install

セットアップは終わり。

$ apt install -y gdb

あとはここを参考にデバッグしたいrubyのメソッドに対応するCの関数を見つけてデバッグすると良い(完)

疑問

Ubuntuのdebug symbolに相当するものはDebianに無いんだろうか。

rubyでOSコマンドを実行できる組み込みライブラリのメソッドを調べた

  • Kernel#.`
  • Kernel#.exec
  • Kernel#.open
  • Kernel#.spawn
  • Kernel#.syscall
  • Kernel#.system
  • Process#.exec
  • Process#.spawn
  • IO.binread
  • IO.binwrite
  • IO.foreach
  • IO.popen
  • IO.read
  • IO.readlines
  • IO.write

ruby2.7.2のコードを追った(どうせなら最新版で見ればよかった)。
涙ぐましいgrepを繰り返した(そのメモ)。
3.1.0で一通り実験したが挙動は同じだったため変わりは無さそう。

調査の中で先頭が"|"で始まる場合の記載に漏れを見つけたのでるりまにPRしてみた。
https://github.com/rurema/doctree/pull/2644

それからOWASPのチートシートにもPRをした。
チートシートには網羅性があると嬉しいので取り込まれることを祈る。
ダメだったらこの記事が自分の備忘録になる。
https://github.com/OWASP/CheatSheetSeries/pull/807

把握してる限りだと組み込みライブラリ以外だとOpen3もOSコマンドを実行できるので追加すると良さそうだが、なかなか疲れたので後でやる気が出たらlib配下も見てみる。
また、もろもろマージされたらbrakemanにもコントリビュートできそうなので見てみる。

追記(1/9): 上記はいずれもbrakeman + rubocopを入れていれば検知できそう