Skip to main content

第3回詳解セキュリティコンテスト輪読会の記録

今回はp.84 - p.122までが範囲で、内容としてはBurpとCSPが中心でした。

6章後半

nginxの仕様上存在する、不注意で起こりうるパストラバーサル

nginxは location に対して置換を行う alias ディレクティブの仕様で、パストラバーサルが発生する alias traversal という脆弱性があります。

CPCTF2022 で出題歴があり、 graneedさんの記事 - 11-1.nginxの設定不備 も併せて読むと良い。また、Apacheでも似たようなaliasに関するパストラバーサルについての問題が出題されたことがあるそう。

Burp Suiteの学習方法

  • TryHackMe が学習の初手としていい感じ。教材みたいに学習を進められる。
  • WebSecurityAcademy はBurpの開発元が出してて最近も更新されているしとても良い問題を解く形式の教材。せっかくならBurp Proの1ヶ月お試し期間を登録して、Burp Proで解いてみるのも良さそう。
    • BurpのProとCommunity Editionの違いは、Proになると機能制限がなくなる点が異なっている。(無料版だと速度が遅いのがなくなる、など)

Burpのdecoder/encoder

通信を伴わないなら、CyberChef も便利。ブロック状にencode/decode処理などを積み上げられるのが便利。

余談だけど、 CyberChefの0dayが含まれる問題 がCTFで出たことがある。

CORSの疑問: POSTにはプリフライトリクエストなくていいのか

CORSの原理を知って正しく使おう - 徳丸さんのyoutube で、「単純でないリクエスト(PUTなど)はプリフライトリクエストが必要だけどPOSTとかは単純なリクエストなのでいらない」という趣旨の話があり、PUTでプリフライトリクエストが必要な理由は分かったが、なぜPOSTではつけなくていいのか？ということが分からず少し調べた。

結論としては、これまでもhtmlでクロスオリジンなリクエストは発生していてセキュリティ対策されていると思われるので新たな脅威としては扱わないということなのでは？という感じ。(あまり確証が得られたわけではない)

参考

他にCORS関連の話題

  • フォームはinputにtokenを入れて、CSRF対策とかbotの連続送信やユーザが誤送信で二重に送ってしまうのを防いだりするのが一般的。
  • CORSが開発で問題になるパターン
    • localhostで別々のポートで起動しているサービス同士の通信でCORSエラーで詰まる
    • goのフレームワークEchoのmiddlewareでは e.Use(middleware.CORS()) というようにデフォルトを使うと全てのオリジンと全てのメソッドを許可してしまう。本番環境では細かく制御する必要がありそう。
    • 認証など、一旦サービスAに飛んでからサービスBにリダイレクトして認証処理を行いサービスAに戻るタイプのやつはOAuthでありがちだけど、サービスAだけ許可してサービスBは許可してないからCORSエラーが出るとかはありそう。
    • フロントエンド開発でS3から画像取得する時にCORSエラーで困ることがある。S3側で設定をする必要がある。
  • portがOriginに含まれるのはなぜ？別サブドメインで別事業者のサービスが起動はわかるけど、別ポートからの攻撃ってありうるのだろうか？(この疑問は歴史的事情の気配がするので気が向いたら調べることにした)
  • ブラウザの歴史とかが大事そう。Webブラウザセキュリティが良い本なので読みたい。

メモ

PayloadAllTheThingsについて

PayloadAllTheThings - SQL Injectionの項 を見ると、色々なペイロードが載っていて良い。

ctf4b textexの作問者writeup でもPayloadAllTheThingsが紹介されていた(LaTeX Injection)

WebサイトやAPIへのアクセス、どこからがまずい？

Burpなどで連続でリクエストを大量に送ることをうっかりしてしまうと、DoS判定されるかもしれない。 岡崎市立中央図書館事件 - wikipedia 通称Librahack事件なども考慮して、リクエストとリクエストの間には時間を空ける、リクエスト数も大量に送らない、ということに気をつけた方がいい。

CTFの問題の文脈でも、数万リクエスト送ることが想定解になることはほとんどないので、原理上大量のリクエストを発行したら解けるとしても別の想定解を疑った方がいいことが多い。

publicなAPIの一日の制限数などをみるとどこまで許されるのか参考にできるかもしれない。ただサービスごとに許容範囲は異なっていそう。

IPAが出している「安全なウェブサイトの作り方」はいいぞ

IPA - 安全なウェブサイトの作り方 に、届出の多かった脆弱性をもとにウェブサイトの開発者や運営者向けのセキュリティの資料が出ています。

CSRFってなんだろう、ということをつまみ食いで調べてみるとかでも十分役立つし、チェックリストもあるので良さそう。

Flatt Securityからもおすすめする記事が出ています

CakeCTF2022楽しみですね

CakeCTF2022 が9/3あたりにあるそうです。 CakeCTF2021の問題リポジトリ は公開されているので復習して本番に備えたいですね。

ICCのAttack&Defenseのソースコードが公開

ICC2022 A/D Services CTFのAttack&Defense形式のソースコードが公開されるのは珍しいと感じました。 動かせるか試したいところです

Macでは5000番ポートが使われている

MacをMontereyにアップデートしたらFlaskが5000番ポートで起動できなくなった AirPlayのレシーバーが5000番を占有しているため。

標準SQLというのがある

標準SQLとは SQLも標準があるらしいが、強制力がないので標準だけ知っていればOKというわけでもなく、個別のSQL文法を学ぶ必要がある。

Shadow DOM closedはセキュリティ用途ではない

Shadow DOM の open/closed はセキュリティ用途では使えない。