Security基礎研修

パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部
※本資料は2023年3月時点の情報であり、当該部門における2023年新卒の研修教材です。

Transcript

1. Security Training for new graduates in 2023 パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部 ※本資料は2023年3月時点の情報であり、2023年新卒の研修教材です。
2. 準備 ワークでHTTP通信をインターセプトするツールが必要になります。 本研修では、Burp Suite(Community Edition)を利用します。 下記リンクからインストールしてください。 PortSwigger. Professional / Community 2023.2.3. https://portswigger.net/burp/releases/professional-community-2023-2-3?requestededition=community ご自身のMacOSを確認してインストー ルしてください。 左上の🍎アイコンから「このMacにつ いて」をクリックして、プロセッサを 確認。
3. 準備 PortSwigger社のWebSecurityAcademyを利用します。 下記リンクからアカウントを作成してください。 PortSwigger. Create your account. https://portswigger.net/users/register
4. 研修のゴール 広義には、セキュリティとはアプリケーション、ネットワーク、クライアント等様々なレイ ヤーで対策すべき内容ですが、本研修では主にWebアプリケーション開発において必要とさ れる、セキュリティ知識、技術を学習することを目的とします。
5. 免責 本研修で学習する攻撃手法の悪用は禁止です。 悪用、興味本位等で他社のWebサービスに攻撃を仕掛けた場合に発生する損害、責任は一切 負いません。
6. 目次 • Mindset • Web basics ◦ Same-origin policy ◦ Cross-origin resource sharing(CORS) ◦ Cookie & Session • Web vulnerabilities ◦ Cross-site request forgeries(CSRF) ◦ Cross-site scripting(XSS) ◦ SQL injection ◦ OS command injection ◦ Directory traversal • Conclusion 6
7. Mindset
8. 脆弱性 アプリケーション等の不具合等や設計ミスが原因となって発生した情報セキュリティ上の欠 陥のことを言います。 総務省. 「脆弱性（ぜいじゃくせい）とは？」. https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/risk/11.html#:~:text=脆弱性（ぜいじゃくせい）とは、 コンピュータのOS,ホールとも呼ばれます。
9. 脆弱性対策は義務 日本であれば、個人情報の保護に関する法律の第23条で定められています（2022/04/06時 点） e-Gov. 「個人情報の保護に関する法律」. https://elaws.e-gov.go.jp/document?lawid=415AC0000000057 各国で定められた法基準に合わせて適切な措置を取る必要があります。 （EU圏内であればGDPR、カリフォルニア州であればCCPA等）
10. 脆弱性があると何が起きるのか • 個人情報等の秘密情報を勝手に閲覧されてしまう • Webサイトの内容が書き換えられてしまう • 別の利用者になりすまし、投稿、買い物、送金されてしまう • Webサイトが利用不可な状態になってしまう 等々、例を挙げたらキリがないです。
11. 脆弱性が突かれた結果… • 利用者が受けた経済的損失の補填 • 取引先企業等への賠償責任 • Webサイトの停止による機会損失 • 社会的信用の失墜による会社全体の売上の低下 データ漏えい等が発生した場合は最悪で、一度漏洩してしまったデータは回収することがで きません。
12. インシデントが起こったとしても事業は継続できます。損害金額も大きくはないかもしれ ません。 しかし、一度失った社会的信用を取り戻すにはとても時間がかかります。 最悪の場合、信頼が戻らず、サービス停止や事業継続が難しくなる場合もあります。 我々は常に多くの個人情報を扱う立場であるため、これらの事例を教訓としセキュリティ を学習するモチベーションとしてください。 ここまでのまとめ
13. Web basics
14. Same-origin policy
15. Same-origin policy 15 同一生成元ポリシー。 そのオリジンのリソースに干渉する事ができるのは、同じオリジンのみとするウェブブラウザに搭載さ れた機能です。 つまり、異なるオリジン（クロスオリジン）からのリソースへの干渉は制限されます。 http://example1.com http://example2.com http://example1.com /api/users /api/users
16. オリジン 16 オリジンとは URL のスキーム (プロトコル)、 ホスト (ドメイン)、 ポート で定義されま す。 つまり、スキーム、ホスト、ポートがすべて一致すると同一オリジンと言えます。
17. URIの仕様 17 http://example.com:80/blog?date=20220407&q=hoge#huga • URIスキーム: http • ホスト名: example.com • ポート番号: 80 • パス: /blog • クエリパラメータ: date=20220407&q=hoge • URIフラグメント: #huga
18. 同一オリジンの例 18 // httpの既定ポートの80番が指定されているので、同一オリジンである http://example.com http://example.com:80 // スキーム、ホストが同一なので同一オリジンである http://example.com/app1/index.html http://example.com/app2/index.html
19. 同一オリジンではない例 19 // ポートが異なるので同一オリジンではない http://example.com http://example.com:3000 // スキームが異なるので同一オリジンではない http://example.com https://example.com // サブドメインではあるが、ホストが異なるので同一オリジンではない http://example.com http://www.example.com http://myapp.example.com
20. Cross-origin resource sharing(CORS)
21. Cross-origin resource sharing 21 オリジン間リソース共有。 一般的には頭文字を取ったCORS（コーズ、コルス、シーオーアールエス）と呼ばれます。 あるオリジンで動作しているウェブアプリケーションに、異なるオリジンのリソースへアクセスできる ようにブラウザに許可を与える仕組みです。 http://example1.com http://example2.com http://example1.com /api/users /api/users
22. Access-Control-Allow-Origin 22 クロスオリジンからのリソースへのアクセスを許可する場合に、HTTPレスポンスヘッダに付与します。 サーバー側で対応するものです。 // 前のページの例であれば、以下のようなレスポンスヘッダーが生成されます Access-Control-Allow-Origin: http://example2.com // ワイルドカードを指定すると、全てのクロスオリジンからのアクセスを許可する（非推奨） Access-Control-Allow-Origin: *
23. Access-Control-Allow-Origin 23 ちなみに、 公開APIはフロントエンドから直接アクセスされる事は想定していないため、 Access-Control-Allow-Originは設定していない。 （APIKeyなどがリクエストに必要になるケースがあるため、フロントエンドから直接リクエストを送っ てしまうとAPIKeyが外部に流出することになる） CORSに関してはあくまでブラウザの話になるので、Curlやサーバー内部でリクエストする際は関係な い。（普通外部のAPI使う時はサーバー側のAPIでラップして使うことがほとんどのはず）
24. Preflight Request 24 シンプルなリクエストに該当しない場合、リクエストの送信前にプリフライトリクエストが送信され、 安全性の確認が行われます。 モダンブラウザであれば、通常はブラウザから自動的に送信されるので、特に意識する必要はありませ ん。 Mozilla. オリジン間リソース共有 (CORS). https://developer.mozilla.org/ja/docs/Web/HTTP/CORS#単純リクエスト
25. イメージ 25 url: /api/user method: OPTIONS Client Server プリフライトリクエスト Mozilla.「Preflight request (プリフライトリクエスト)」. https://developer.mozilla.org/ja/docs/Glossary/Preflight_request メインリクエスト url: /api/user method: POST
26. Cookie & Session
27. HTTPのステートレス性 HTTPは状態を持たないプロトコルとして設計されています。それぞれのリクエストは独立したものとし て扱われます。 そのため、毎回リクエストに全ての情報を送信しなければいけません。 27 Aです。ハンバーガーの配達をお願いします。 かしこまりました。住所はどちらでしょうか？ 東京都千代田区千代田1-1です。 かしこまりました。お届けします。 ステートフルな会話 Aです。ハンバーガーの配達をお願いします。 かしこまりました。住所はどちらでしょうか？ 東京都千代田区千代田1-1です。 あなたは誰ですか？何を注文されますか？ ステートレスな会話 この会話成立させるには 「Aです。東京都千代田区千代 田1-1にハンバーガーの配達をお 願いします」 とリクエストする必要がある。
28. ステートレスによる課題 ステートフルなプロトコルと比べてスケーラビリティの高いプロトコルなので、Webアプリケーションへ の適正は高いですが、状態を保持できないと不都合があります。 例えば、Amazon等のECサイトでは 1. 商品を検索する 2. 商品を買い物カゴへ入れる 3. 買い物カゴに入っている商品を購入する という操作を行いますが、これらのリクエストは独立しています。 買い物カゴに入れても、購入リクエストを送信する時には買い物カゴは空なので購入できません。 28
29. Cookie サーバとブラウザ間で状態を保存するための仕組みです。 一般的には、ログイン等のタイミングでサーバ側が生成したセッション情報をレスポンスに付与しま す。それをクライアントのブラウザに保存することで、そのリクエストがどのクライアントから送られ てきたのか管理します。 ログアウト等が実行されるまでの間は、それ以降のリクエストにCookieが付与されます。 29
30. イメージ 30 url: /api/user method: GET Client Server Set-Cookie: SESSIONID=12345678 url: /api/hamburgers method: GET cookie: SESSIONID=12345678
31. Cookieの脆弱性 前述した通り、ブラウザに保存されたCookieをもとにユーザーを特定しているので、何らかの方法で Cookieを抜き取ることで、そのユーザーになりすませる、と言えます。（これを悪用したものがセッ ションハイジャックと言われる攻撃手法） このような理由からCookieを悪用しようとする攻撃手法がいくつも存在します。間違っても平文でCookie に秘匿情報を保存しないように注意してください。（推測可能なものもNG） これらの脅威から守るためにCookieの正しい利用方法を紹介します。 31
32. Domain属性 理由がなければ設定しない。 • Cookie を受信することができるドメインを指定する属性 • 未設定の場合は、Cookieを生成したサーバーにのみ送信されるので、セキュリティ上ではこれが最 も安全 • 複数のドメインに対して有効なCookieを生成したい場合等が利用シーンにあげられる ◦ ただし、Windows7、Windows8.1のIEについてはeTLDに該当する一部のドメインが設定できて しまうクッキモンスターバグがある。（PSLを各ベンダ毎に管理していたのが根本原因）例え ばexample.tokyo.jpに対して指定する場合は、example.tokyo.jpですが、tokyo.jpのクッキーが 作れてしまう問題。モダンブラウザでは対策されていますが、セッション固定化攻撃のリス クが増加するため注意が必要です。 Jxck. 「Public Suffix List の用途と今起こっている問題について」.　　 https://blog.jxck.io/entries/2021-04-21/public-suffix-list.html 32
33. Secure属性 理由がなければ有効に設定する。 • Cookieの送信をHTTPSに限定する ◦ CookieはHTTP、HTTPS問わず、送信されてしまう ◦ HTTPの通信を盗聴されてCookieを盗み出される可能性がある 33
34. HttpOnly属性 理由がなければ有効に設定する • JavaScriptからのCookieの参照を禁止する ◦ 後述するXSS脆弱性に有効 34
35. SameSite属性 利用シーンに応じた適切な設定をする • 設定値は、None（なし）、Lax（緩い）、Strict（厳しい）の3種類 ◦ 未設定の場合は、Laxが設定される（一部のモダンブラウザ, safari,firefoxはNoneっぽい） ▪ 徳丸浩の日記. 「2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか」. https://blog.tokumaru.org/2022/01/ ◦ Noneを設定する場合は、Secure属性の有効化が必須（一部のモダンブラウザ） ◦ 後述するCSRF脆弱性に有効 35 Mozilla. Set-Cookie. https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie Google. 「新しい SameSite=None; Secure Cookie 設定への対応準備」. https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ja e-Words. SameSite属性 【SameSite Cookie】. https://e-words.jp/w/SameSite%E5%B1%9E%E6%80%A7.html
36. Cookieに関する規制 近年では個人情報保護の観点からCookieの利用を規制する動きがあります。 EUで施行されたGDPRを始め、日本でも2022年4月からCookieは個人関連情報（閲覧履歴、位置情報等も 該当する）にあたるとされ、第三者に提供する場合に本人の同意が必要になります。（取得側で個人 データとして取得する場合） 36 e-Gov. 個人情報の保護に関する法律. https://elaws.e-gov.go.jp/document?lawid=415AC0000000057
37. Cookieの何が問題か Cookieは個人の行動履歴を特定する目的でも利用されます。（トラッキング） 例えば、ECサイトで閲覧していた商品が別のサイトの広告欄で表示される経験ありませんか？ これはあるWebサイトを閲覧した際に、そのサイトに設置された広告経由等で送られたCookieにより、実 現されている仕組みです。 一般的にそのサイトで必要な情報を保存するために用いられるCookieをファーストパーティCookieと言 い、広告等複数のサイトを横断して行動履歴をトラッキングする等の目的で利用されるCookieをサード パーティCookieと言います。 前述した個人情報保護法改正による規制はサードパーティCookieが対象となります。 37
38. リタゲ広告のイメージ 38 https://ecA.com https://ecB.com ecA.comを 閲覧した ecB.comを 閲覧した 1. ecA.comにアクセス https://ad.com 2. ecA.comに設置されたad.com の広告からリクエスト 3. ad.comからサードパーティ クッキーが生成される 5. ecB.comに設置されたad.com の広告からリクエスト 6. このクッキーを所有する ユーザーはecA.com,ecB.comの サイトを閲覧したという履歴が 広告サイトに蓄積される 4. ecB.comにアクセス
39. JSON Web Token Cookieはステートフルなセッション管理方法ですが、一方最近ではステートレスなセッション管理方法として略してJWT （ジョット）が利用されるケースも見られます。（サビ開はほとんどこれ） 複数のマイクロサービスで構成されるサービスが増え、認証情報の持ち運びができることから人気が高まっています。 Sessionと異なり、保存場所の選択肢にはインメモリ、WebStorage等も含まれます。 保存場所が変わっても基本的なアプローチはCookieと同様の考え方である点に注意してください。（見られて困る情報は 保存しない、JWTであれば署名を付ける）
40. Web vulnerabilities
41. Cross-site request forgeries(CSRF)
42. CSRF ブラウザからクライアントが意図しないリクエストをサーバに送信させる攻撃手法。 サーバー側でリクエストを十分に検証せず処理するように設計されている場合、正規のリクエストとし て扱われ、被害が発生する。
43. イメージ 正規サイトA 5. 正規サイトからのリクエストなので 正規リクエストとして 処理される 2. 悪意のあるユーザーが作成したサイトに 正規サイトAに対する リクエストが埋め込まれている 偽サイトA’ 4. ユーザーは気づかず リクエストが送信される 6. ユーザーが意図しない結果が 反映される 1. 正規サイトAに ログイン済 3. ユーザーが 偽サイトA’にアクセス
44. CSRF脆弱性の事例 • パソコン遠隔操作事件 Wikipedia. 「パソコン遠隔操作事件」. https://ja.wikipedia.org/wiki/パソコン遠隔操作事件#犯行の手口 その他にもパスワード変更、送金、商品の購入等を目的として仕掛けられることもあります。 44
45. CSRF脆弱性を探してみよう🔍 CSRF 攻撃を使用してユーザーの電子メールアドレスを変更する HTML を作成し、それをエクスプロイト サーバーにアップロードしてください。 PortSwigger. Lab: CSRF vulnerability with no defenses. https://portswigger.net/web-security/csrf/lab-no-defenses ※注意: Solution, Community solutionsは開かないようにしてください。 💡ヒント • まずはメールアドレス変更のリクエストを探してみましょう。 • 攻撃サイトでユーザーは操作を行いません。ユーザーがアクセスした瞬間にリクエストが送信され るようにしてください。 • スクリプトが完成したら「Deliver exploit to victim」をクリックするのを忘れずに・ 45 分かりにくいですが、画面上部のGo to exploit serverからHTMLが 作成できます。
46. 解説 46 PortSwigger. Lab: CSRF vulnerability with no defenses. https://portswigger.net/web-security/csrf/lab-no-defenses
47. CSRF脆弱性への対策 根本的な対策は、正規のリクエストであるかサーバー側で確認する。 • トークンの埋め込み • 本人確認をする • Refererのチェック • CookieのSameSite属性の設定
48. トークンの埋め込み 第3者が知り得ない秘密情報（＝トークン）をリクエストに要求することで正規のリクエストであるか判 別します。 フレームワークを利用した開発を行う場合は、トークン生成、チェック機能が提供されていることが多 いので、比較的容易に実装可能です。CSRF脆弱性における汎用的な対策にあたるため推奨される方法で すが、XSS脆弱性のあるサイトの場合はこの対策だけでは不十分となる点に注意してください。 Youtube. 徳丸浩のウェブセキュリティ講座. 「XSS脆弱性があるとCSRF対策は突破できる」. https://www.youtube.com/watch?v=t23FHC5hRDk
49. 本人確認をする 例えば、購入ページであれば購入の確定前にパスワードを再入力するページを挟む等の方法を指しま す。 Githubでもセキュリティ侵害が発生しうる重要な操作を行う箇所でこのような操作が求められるケースが あります。（sudoモード） ただし、重要なページに絞らないと煩雑な操作になってしまうことや、パスワード入力を求めるタイミ ングを誤ると脆弱性が混入することになるので注意が必要です。 GitHub. GitHub Docs. Sudo モード. https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/sudo-mode
50. Refererのチェック 手段としては考えられますが、推奨できない方法です。 • Refererの送信有無がクライアントの設定次第になる • 操作方法によってRefererが付かない（URLに直アクセス、新しいタブで開く等） • チェック漏れが起きやすい ※ 余談 正しくはReferrerですが、スペルミスでRefererとなっているようです。 Wikipedia. HTTPリファラ. https://ja.wikipedia.org/wiki/HTTP%E3%83%AA%E3%83%95%E3%82%A1%E3%83%A9#%E7%B6%B4%E3%82%8A
51. CookieのSameSite属性の設定 Same Site=Lax 、もしくは Same Site=Strict の設定をすることで、クロスオリジンからのPOST等の危 険なメソッドの実行時にCookieの送信がされません。 送金や商品の購入のようなケースは防げますが、先程紹介した認証しなくても処理を実行できてしまう ケースは防ぐことはできないので、あくまで緩和策と捉えてください。
52. Cross-site scripting(XSS)
53. XSS 攻撃者が攻撃対象となるWebサイトに、何らかの方法で混入させた任意のJavaScriptコードをクライアン トのブラウザ上で実行させる攻撃手法。Webアプリケーションにおける被害の中で最も多いのが、この脆 弱性です。（IPA2021年第4四半期調べ） IPA. ソフトウェア等の脆弱性関連情報に関する届出状況. https://www.ipa.go.jp/files/000095630.pdf この脆弱性が混入すると様々な被害が発生します。 • 被害者となるユーザーになりすます • 被害者となるユーザーが実行できる操作、アクセスできる情報の読み取り • Webサイトの改ざん 53
54. Reflected XSS 脆弱性のあるWebサイトのリンクに悪意のあるスクリプトを含ませて、偽メールや偽サイトに設置しま す。その後、ユーザーがそのリンク先へアクセスすることで悪意のあるスクリプトをクライアント上で 実行させる攻撃手法です。 典型的な例は検索画面等が挙げられます。 リクエストしたクライアントへスクリプトが返ってくることから「Reflected XSS」と呼ばれています。 54
55. Reflected XSSのイメージ 55 攻撃対象のサイト 1. 悪意のあるユーザーが作成した罠サイトに 正規サイトAへのリンクが埋め込まれてい る。（パラメータに攻撃用のスクリプトが含 まれている） 罠サイト 3. 罠サイト経由でアクセス 4. ユーザーのブラウザ上で悪意の あるスクリプトが実行される 2. ユーザーが 罠サイトで罠を閲覧
56. Stored XSS 事前に攻撃者は悪意のあるスプリクトをWebサイトのデータベース等に保存させます。 その後、ユーザーが閲覧する度、保存されている悪意のあるスクリプトが実行されます。Reflected XSS と比較して、誘導する手間がかからないため攻撃難易度は低いと言えます。 典型的な例では、掲示板やブログのコメント機能等が挙げられます。 56
57. Stored XSSのイメージ 57 攻撃対象のサイト 1. 悪意のあるユーザーが事前に攻撃対象 サイトのDB等にスクリプトを登録する。 2. ユーザーがアクセス 3. ユーザーのブラウザ上で悪意の あるスクリプトが実行される
58. DOM-based XSS サーバ側ではなく、フロントエンド側のコード脆弱性を悪用した攻撃です。 利用方法について注意を払うべく代表的な機能には • document.write • innerHTML/outerHTML • location.href • eval 等が挙げられます。 58
59. XSSを探してみよう🔍① ブログの検索機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()を実行してください。 PortSwigger. Lab: Reflected XSS into HTML context with nothing encoded. https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded 💡ヒント • Reflected-XSS 59
60. 解説 60 URLクエリに含まれる文字列をそのまま出力してしまっている。 PortSwigger. Lab: Reflected XSS into HTML context with nothing encoded. https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded
61. XSSを探してみよう🔍② ブログのコメント機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()` を実行してください。 PortSwigger. Lab: Stored XSS into HTML context with nothing encoded. https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded 💡ヒント • Stored-XSS 61
62. 解説 62 以前登録したデータがエスケープされずに保存されてしまった ため、データ取得時にスクリプトが実行されてしまっている。 PortSwigger. Lab: Stored XSS into HTML context with nothing encoded. https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded
63. XSSを探してみよう🔍③ ブログの検索機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()` を実行してください。 PortSwigger. Lab: DOM XSS in document.write sink using source location.search. https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink 💡ヒント • DOM-Based XSS 63
64. 解説 64 document.writeで書き込んでいるため、HTMLのリテラルが 破壊された。 PortSwigger. Lab: DOM XSS in document.write sink using source location.search. https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink
65. XSSを探してみよう🔍④ ブログの検索機能にXSS脆弱性が隠されています。XSS攻撃を仕掛けてalert()` を実行してください。 PortSwigger. Lab: DOM XSS in innerHTML sink using source location.search. https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-innerhtml-sink 💡ヒント • scriptタグ以外の方法でJavaScriptを実行する方法を考えてみてください。 • DOM-Based XSS • ロード時にアラートが出ないとダメかも？ 65
66. 解説 66 W3C. Scripting. https://www.w3.org/TR/2014/REC-html5-20141028/scripting-1.html#the-script-element innerHTMLだとScriptタグの内容は実行されないので、imgタグ等にあるイベントハンドラを利用する。 エスケープされていないため、URLクエリに書かれた内容がそのままHTMLタグとして解釈されてしまった。 PortSwigger. Lab: DOM XSS in innerHTML sink using source location.search. https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-inn erhtml-sink
67. XSSを探してみよう🔍⑤ フィードバック送信ページにXSS脆弱性が含まれています。「Back」をクリックした時にクライアントに 保存されているCookieをalertしてください。 PortSwigger. Lab: DOM XSS in jQuery anchor href attribute sink using location.search source. https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-jquery-href-attribute-sink 💡ヒント • Anchorタグからjavascriptを発火させるにはどのようにしたら良いでしょうか。 • Reflected-XSS 67
68. 解説 68 JavaScriptスキームの仕組みを使った攻撃です。 エスケープ無しでURLクエリの内容を画面要素に反映させてしまっている。
69. XSSを探してみよう🔍⑥ ブログの検索機能にXSS脆弱性が隠されています。検索ワード入力ボックスにマウスオーバーしたら alert()を実行するようにしてください。 PortSwigger. Lab: Reflected XSS into attribute with angle brackets HTML-encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-attribute-angle-brackets-html-encoded 💡ヒント • ここまで進んだ人達であれば自力で解けるはず。。。！ 69
70. 解説 70 PortSwigger. Lab: Reflected XSS into attribute with angle brackets HTML-encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-attribute-angle-brackets-html-encoded
71. XSSを探してみよう🔍⑦ ブログのコメント機能にXSS脆弱性があります。コメント作成者名がクリックされた時にalert()が実行さ れるようにしてください。（コメントの「Website」を入力しないと作成者名がリンクにならないので注 意！） PortSwigger. Lab: Stored XSS into anchor href attribute with double quotes HTML-encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-href-attribute-double-quotes-html-encoded 💡ヒント • ここまで進んだ人達であれば自力で解けるはず。。。！ 71
72. 解説 72 PortSwigger. Lab: Stored XSS into anchor href attribute with double quotes HTML-encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-href-attribute-double-quotes-html-encoded
73. XSSを探してみよう🔍⑧ ブログの検索機能にXSS脆弱性が隠されています。検索を実行した時にalert()が実行されるようにしてく ださい。 PortSwigger. Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-javascript-string-angle-brackets-html-encoded 💡ヒント • JavaScriptのコードリテラルを破壊してください。 73
74. 解説 74 サーバでHTMLを生成する際にURLクエリの内容をエスケープせず、HTMLに書き出してしまっている。 PortSwigger. Lab: Reflected XSS into a JavaScript string with angle brackets HTML encoded. https://portswigger.net/web-security/cross-site-scripting/contexts/lab-javascript-string-angle-brackets-html-encoded
75. XSSの必須対策 一般的には以下のような対策が取られます。 • リテラルを破壊するメタ文字のエスケープ HTMLであれば「<」「>」「”」「&」等。Scriptであれば「\」「’」「”」等。 • HTTPレスポンスに文字エンコーディングのセット 75
76. XSSの緩和対策 また、その他に緩和策として以下の方法が取られます。 • ユーザーからの入力値の検証 • Content-security Policyの設定 ※1 • X-XSS-Protectionの設定(レガシーブラウザのサポートが必要な場合のみ) • CookieのHttpOnly属性の有効化（セッションハイジャックのみ） ※1 Mozilla. コンテンツセキュリティポリシー (CSP). https://developer.mozilla.org/ja/docs/Web/HTTP/CSP 76
77. SQL injection
78. SQL injection 外部から受け取ったパラメータでSQLを実行する場合に、意図しないクエリが発行され、データベースが 不正に操作される脆弱性。 データベースの内容を直接閲覧、改ざんされる等、非常に影響が大きい脆弱性のため絶対に混入させて はいけないです。
79. イメージ メールアドレス、パスワードが一致したらログインできる。 内部的には以下のようなクエリが発行される。 SELECT * FROM users WHERE email = ‘hoge@example.com’ and password = ‘password’; // OR 1 = 1で必ずtrueが返る SELECT * FROM users WHERE email = 'hoge@example.com' OR 1 = 1 --' and password = ''; メールアドレスにhoge@example.com’ OR 1 = 1 –-と入力することで パスワードの認証を突破できてしまう。
80. SQL injectionの原因 パラメータ化された部分を実際の値に展開する時、リテラルとして文法的に正しく文を生成していない ためです。 SQL文として意味のある文字列が適切にエスケープされていないために、パラメータに与えられた値がリ テラルの外にはみ出した状態になり、リテラルの後ろに続く文として解釈され、SQLインジェクションが 発生します。 // シングルクォートが適切にエスケープされていれば、SQLインジェクションは発生しなかった SELECT * FROM users WHERE email = 'hoge@example.com\' OR 1 = 1 --' and password = 'password';
81. SQL injectionを探してみよう①🔍 商品カテゴリの検索機能に SQL インジェクションの脆弱性があります。脆弱性を見つけ、未リリースも 含んだ全ての商品の一覧を表示してください。 PortSwigger. Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data. https://portswigger.net/web-security/sql-injection/lab-retrieve-hidden-data 💡 ヒント • ソースコードの内部では受け取ったパラメータからどのようにクエリを作成するのか想像してみま しょう。
82. 解説 82 const db = new DB(); db.open(); const sql = `SELECT * FROM products WHERE category_name = '${category}' AND release = 1`; db.query(sql); db.close(); 以下のようなスクリプトが組まれているのではないか、と推 測できる。 categoryに’+OR+1=1+--に書き換えてリクエストすると以 下のクエリが発行される。（+はスペースの代わり） SELECT * FROM products WHERE categories = '' OR 1=1 --' AND release = 1
83. SQL injectionを探してみよう②🔍 商品カテゴリの検索機能に SQL インジェクションの脆弱性があります。 データベースにはusersという別のテーブルがあり、usernameとpasswordというカラムが存在します。すべての ユーザー名とパスワードを取得し、その情報を使用して管理者ユーザーとしてログインしてください。 PortSwigger. Lab: SQL injection UNION attack, retrieving data from other tables. https://portswigger.net/web-security/sql-injection/union-attacks/lab-retrieve-data-from-other-tables 💡ヒント • まず、ユーザーから受け取った値でクエリを生成している箇所を見つけてください。 • そのクエリを利用してusersテーブルからデータを取得する方法を考えてください。（UNION） ◦ 脆弱性のあるクエリのカラム数を探索してみてください。 ◦ カラム数が特定できたらカラムのデータ型を探索してみてください。 ◦ カラム数とデータ型が特定できたらusersテーブルと結合してみてください。
84. 解説 84 1. まず、カラム数を特定するために、Nullが入ったダミーテーブルをUNIONで連結してみる。 2. カラム数が特定できたら、次にデータ型を特定するために様々なデータ型のダミーテーブルをUNIONで連結してみる。 3. データ型の特定ができたら、それに合わせてusersテーブルを取得するクエリをUNIONで連結する。 PortSwigger. Lab: SQL injection UNION attack, retrieving data from other tables. https://portswigger.net/web-security/sql-injection/union-attacks/lab-retrieve-data-from-other-tables
85. SQL injectionの対策 基本的な対策は、プレースホルダーを利用してSQL文を組み立てるようにすること。 IPA. 安全なSQLの呼び出し方. https://www.ipa.go.jp/files/000017320.pdf その他に、SQLの詳細なエラーメッセージをユーザーに出力しない対策も有効です。エラーメッセージか らテーブルの構成等が漏れ、攻撃に利用されるのを防ぎます。 // パラメータ部分に?を割り当てている db.query('SELECT * FROM products WHERE categories = ?', 'Gift')
86. OS command injection
87. OS command injection 外部から受け取ったパラメータでOSコマンドを実行する場合に、任意のコマンドが実行されてしまう脆 弱性。 利用シーンは少ないはずですが、OSコマンドを利用して処理を行う場合は別の方法がないか検討し直し てください。利用しないことがこの脆弱性からアプリケーションを守る一番の対策になります。
88. OS command injectionを探してみよう🔍 商品の在庫確認機能にOSコマンドインジェクションの脆弱性が存在します。パラメータで渡された商品 IDと店舗IDをもとにシェルスクリプトを実行して、標準出力された内容を返却します。 whoamiコマンドを実行して、現在のユーザ名を出力してください。 PortSwigger. Lab: OS command injection, simple case. https://portswigger.net/web-security/os-command-injection/lab-simple 💡 ヒント • whoamiはunix系列の現在のユーザーを表示するコマンドです。 • リクエストのパラメータが直接シェルスクリプトに引数として渡されると想定してください。 • ディレクトリの中身の参照やファイルの追加、削除等も行ってみてください。
89. 解説 89 PortSwigger. Lab: OS command injection, simple case. https://portswigger.net/web-security/os-command-injection/lab-simple
90. OS command injectionの対策 基本的な対策は、OSコマンドを利用しない実装を検討すること。 やむを得ず利用しなければいけないケースは • ユーザーから渡された値は検証する。 • OSコマンドのメタ文字をエスケープする。（ライブラリに頼るのが吉） 等の対策が考えられます。 90
91. Directory traversal
92. Directory traversal 外部から受け取ったパラメータでファイルの内容を表示させる場合に、意図しないファイルが閲覧され てしまうような脆弱性。 実装によっては、改ざん・削除等もありえるため、非常に影響が大きいです。SQLインジェクション同様 絶対に混入しないようにすべき脆弱性です。
93. Directory traversalを探してみよう🔍 商品の詳細ページの画像表示にDirectory traversalの脆弱性があります。/etc/passwdのファイル内容を表 示してください。 PortSwigger. Lab: File path traversal, simple case. https://portswigger.net/web-security/file-path-traversal/lab-simple 💡 ヒント • HTTP Historyから通信の内容を確認してみてください。 • パス指定には絶対パスの他に、相対パス指定もある。 リクエストの内容を変更した場合は、HTTP History のOriginal requestからEdited requestを選択すると変 更後のリクエストの内容を確認できます。
94. 解説 94
95. 意図しないファイルの公開 公開する必要のないファイルが公開ディレクトリに置かれていたり、公開不要なディレクトリが公開 ディレクトリになっている等の設定ミスが起因で意図しないファイルが公開されてしまうケースもあり ます。 以下は、nginxにおける設定ミスで起きるディレクトリトラバーサルの例です。 Qiita. @no1zy_sec(no1zy). 「nginxの設定ミスで起こるパス トラバーサル」. https://qiita.com/no1zy_sec/items/e541f1c838874ff400bb, 2018年06月 10日
96. Directory traversalの対策 基本的な対策は、外部からファイル名を指定できる仕様を避ける。 その他に • ファイル名にディレクトリを含めないようにする。（想定しているディレクトリ以外はアクセスさ せない） • 非公開ファイルを公開フォルダに設置しない。 アプリケーションの範疇を超えて対策できる場合は • WAF（Web Application Firewall）の設置。 • ディレクトリリスティングの無効化。 等の対策が考えられます。
97. Conclusion
98. 最後に 今回紹介した脆弱性の殆どは、ユーザーから入力されるデータが原因です。どんなユーザーがそのサー ビスを利用するか分かりません。いつでもサービスは危険に晒されています。 入力されたデータは検証、サニタイズすることを忘れないでください。 今回触れた内容はごく一部です。まだまだ注意するべき点はたくさんあります。研修資料作成にあたっ て参考にした以下の書籍、サイトを見ることをオススメします。 • 徳丸 浩. 「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実 践」. https://www.amazon.co.jp/dp/4797393165/ref=cm_sw_r_tw_dp_3HAS2XYB4CYVNE9TYWA6 • PortSwigger. Web Security Academy. https://portswigger.net/web-security
99. End