$30 off During Our Annual Pro Sale. View Details »

Security基礎研修

techtekt
August 23, 2023

 Security基礎研修

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

techtekt

August 23, 2023
Tweet

More Decks by techtekt

Other Decks in Programming

Transcript

  1. Security
    Training for new graduates in 2023
    パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部
    ※本資料は2023年3月時点の情報であり、2023年新卒の研修教材です。

    View Slide

  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につ
    いて」をクリックして、プロセッサを
    確認。

    View Slide

  3. 準備
    PortSwigger社のWebSecurityAcademyを利用します。
    下記リンクからアカウントを作成してください。
    PortSwigger. Create your account. https://portswigger.net/users/register

    View Slide

  4. 研修のゴール
    広義には、セキュリティとはアプリケーション、ネットワーク、クライアント等様々なレイ
    ヤーで対策すべき内容ですが、本研修では主にWebアプリケーション開発において必要とさ
    れる、セキュリティ知識、技術を学習することを目的とします。

    View Slide

  5. 免責
    本研修で学習する攻撃手法の悪用は禁止です。
    悪用、興味本位等で他社のWebサービスに攻撃を仕掛けた場合に発生する損害、責任は一切
    負いません。

    View Slide

  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

    View Slide

  7. Mindset

    View Slide

  8. 脆弱性
    アプリケーション等の不具合等や設計ミスが原因となって発生した情報セキュリティ上の欠
    陥のことを言います。
    総務省. 「脆弱性(ぜいじゃくせい)とは?」.
    https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/risk/11.html#:~:text=脆弱性(ぜいじゃくせい)とは、
    コンピュータのOS,ホールとも呼ばれます。

    View Slide

  9. 脆弱性対策は義務
    日本であれば、個人情報の保護に関する法律の第23条で定められています(2022/04/06時
    点)
    e-Gov. 「個人情報の保護に関する法律」. https://elaws.e-gov.go.jp/document?lawid=415AC0000000057
    各国で定められた法基準に合わせて適切な措置を取る必要があります。
    (EU圏内であればGDPR、カリフォルニア州であればCCPA等)

    View Slide

  10. 脆弱性があると何が起きるのか
    ● 個人情報等の秘密情報を勝手に閲覧されてしまう
    ● Webサイトの内容が書き換えられてしまう
    ● 別の利用者になりすまし、投稿、買い物、送金されてしまう
    ● Webサイトが利用不可な状態になってしまう
    等々、例を挙げたらキリがないです。

    View Slide

  11. 脆弱性が突かれた結果…
    ● 利用者が受けた経済的損失の補填
    ● 取引先企業等への賠償責任
    ● Webサイトの停止による機会損失
    ● 社会的信用の失墜による会社全体の売上の低下
    データ漏えい等が発生した場合は最悪で、一度漏洩してしまったデータは回収することがで
    きません。

    View Slide

  12. インシデントが起こったとしても事業は継続できます。損害金額も大きくはないかもしれ
    ません。
    しかし、一度失った社会的信用を取り戻すにはとても時間がかかります。
    最悪の場合、信頼が戻らず、サービス停止や事業継続が難しくなる場合もあります。
    我々は常に多くの個人情報を扱う立場であるため、これらの事例を教訓としセキュリティ
    を学習するモチベーションとしてください。
    ここまでのまとめ

    View Slide

  13. Web basics

    View Slide

  14. Same-origin
    policy

    View Slide

  15. Same-origin policy
    15
    同一生成元ポリシー。
    そのオリジンのリソースに干渉する事ができるのは、同じオリジンのみとするウェブブラウザに搭載さ
    れた機能です。
    つまり、異なるオリジン(クロスオリジン)からのリソースへの干渉は制限されます。
    http://example1.com
    http://example2.com
    http://example1.com
    /api/users
    /api/users

    View Slide

  16. オリジン
    16
    オリジンとは URL のスキーム (プロトコル)、 ホスト (ドメイン)、 ポート で定義されま
    す。
    つまり、スキーム、ホスト、ポートがすべて一致すると同一オリジンと言えます。

    View Slide

  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

    View Slide

  18. 同一オリジンの例
    18
    // httpの既定ポートの80番が指定されているので、同一オリジンである
    http://example.com
    http://example.com:80
    // スキーム、ホストが同一なので同一オリジンである
    http://example.com/app1/index.html
    http://example.com/app2/index.html

    View Slide

  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

    View Slide

  20. Cross-origin
    resource
    sharing(CORS)

    View Slide

  21. Cross-origin resource sharing
    21
    オリジン間リソース共有。
    一般的には頭文字を取ったCORS(コーズ、コルス、シーオーアールエス)と呼ばれます。
    あるオリジンで動作しているウェブアプリケーションに、異なるオリジンのリソースへアクセスできる
    ようにブラウザに許可を与える仕組みです。
    http://example1.com
    http://example2.com
    http://example1.com
    /api/users
    /api/users

    View Slide

  22. Access-Control-Allow-Origin
    22
    クロスオリジンからのリソースへのアクセスを許可する場合に、HTTPレスポンスヘッダに付与します。
    サーバー側で対応するものです。
    // 前のページの例であれば、以下のようなレスポンスヘッダーが生成されます
    Access-Control-Allow-Origin: http://example2.com
    // ワイルドカードを指定すると、全てのクロスオリジンからのアクセスを許可する(非推奨)
    Access-Control-Allow-Origin: *

    View Slide

  23. Access-Control-Allow-Origin
    23
    ちなみに、
    公開APIはフロントエンドから直接アクセスされる事は想定していないため、
    Access-Control-Allow-Originは設定していない。
    (APIKeyなどがリクエストに必要になるケースがあるため、フロントエンドから直接リクエストを送っ
    てしまうとAPIKeyが外部に流出することになる)
    CORSに関してはあくまでブラウザの話になるので、Curlやサーバー内部でリクエストする際は関係な
    い。(普通外部のAPI使う時はサーバー側のAPIでラップして使うことがほとんどのはず)

    View Slide

  24. Preflight Request
    24
    シンプルなリクエストに該当しない場合、リクエストの送信前にプリフライトリクエストが送信され、
    安全性の確認が行われます。
    モダンブラウザであれば、通常はブラウザから自動的に送信されるので、特に意識する必要はありませ
    ん。
    Mozilla. オリジン間リソース共有 (CORS). https://developer.mozilla.org/ja/docs/Web/HTTP/CORS#単純リクエスト

    View Slide

  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

    View Slide

  26. Cookie & Session

    View Slide

  27. HTTPのステートレス性
    HTTPは状態を持たないプロトコルとして設計されています。それぞれのリクエストは独立したものとし
    て扱われます。
    そのため、毎回リクエストに全ての情報を送信しなければいけません。
    27
    Aです。ハンバーガーの配達をお願いします。
    かしこまりました。住所はどちらでしょうか?
    東京都千代田区千代田1-1です。
    かしこまりました。お届けします。
    ステートフルな会話
    Aです。ハンバーガーの配達をお願いします。
    かしこまりました。住所はどちらでしょうか?
    東京都千代田区千代田1-1です。
    あなたは誰ですか?何を注文されますか?
    ステートレスな会話
    この会話成立させるには
    「Aです。東京都千代田区千代
    田1-1にハンバーガーの配達をお
    願いします」
    とリクエストする必要がある。

    View Slide

  28. ステートレスによる課題
    ステートフルなプロトコルと比べてスケーラビリティの高いプロトコルなので、Webアプリケーションへ
    の適正は高いですが、状態を保持できないと不都合があります。
    例えば、Amazon等のECサイトでは
    1. 商品を検索する
    2. 商品を買い物カゴへ入れる
    3. 買い物カゴに入っている商品を購入する
    という操作を行いますが、これらのリクエストは独立しています。
    買い物カゴに入れても、購入リクエストを送信する時には買い物カゴは空なので購入できません。
    28

    View Slide

  29. Cookie
    サーバとブラウザ間で状態を保存するための仕組みです。
    一般的には、ログイン等のタイミングでサーバ側が生成したセッション情報をレスポンスに付与しま
    す。それをクライアントのブラウザに保存することで、そのリクエストがどのクライアントから送られ
    てきたのか管理します。
    ログアウト等が実行されるまでの間は、それ以降のリクエストにCookieが付与されます。
    29

    View Slide

  30. イメージ
    30
    url: /api/user
    method: GET
    Client Server
    Set-Cookie: SESSIONID=12345678
    url: /api/hamburgers
    method: GET
    cookie: SESSIONID=12345678

    View Slide

  31. Cookieの脆弱性
    前述した通り、ブラウザに保存されたCookieをもとにユーザーを特定しているので、何らかの方法で
    Cookieを抜き取ることで、そのユーザーになりすませる、と言えます。(これを悪用したものがセッ
    ションハイジャックと言われる攻撃手法)
    このような理由からCookieを悪用しようとする攻撃手法がいくつも存在します。間違っても平文でCookie
    に秘匿情報を保存しないように注意してください。(推測可能なものもNG)
    これらの脅威から守るためにCookieの正しい利用方法を紹介します。
    31

    View Slide

  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

    View Slide

  33. Secure属性
    理由がなければ有効に設定する。
    ● Cookieの送信をHTTPSに限定する
    ○ CookieはHTTP、HTTPS問わず、送信されてしまう
    ○ HTTPの通信を盗聴されてCookieを盗み出される可能性がある
    33

    View Slide

  34. HttpOnly属性
    理由がなければ有効に設定する
    ● JavaScriptからのCookieの参照を禁止する
    ○ 後述するXSS脆弱性に有効
    34

    View Slide

  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

    View Slide

  36. Cookieに関する規制
    近年では個人情報保護の観点からCookieの利用を規制する動きがあります。
    EUで施行されたGDPRを始め、日本でも2022年4月からCookieは個人関連情報(閲覧履歴、位置情報等も
    該当する)にあたるとされ、第三者に提供する場合に本人の同意が必要になります。(取得側で個人
    データとして取得する場合)
    36
    e-Gov. 個人情報の保護に関する法律. https://elaws.e-gov.go.jp/document?lawid=415AC0000000057

    View Slide

  37. Cookieの何が問題か
    Cookieは個人の行動履歴を特定する目的でも利用されます。(トラッキング)
    例えば、ECサイトで閲覧していた商品が別のサイトの広告欄で表示される経験ありませんか?
    これはあるWebサイトを閲覧した際に、そのサイトに設置された広告経由等で送られたCookieにより、実
    現されている仕組みです。
    一般的にそのサイトで必要な情報を保存するために用いられるCookieをファーストパーティCookieと言
    い、広告等複数のサイトを横断して行動履歴をトラッキングする等の目的で利用されるCookieをサード
    パーティCookieと言います。
    前述した個人情報保護法改正による規制はサードパーティCookieが対象となります。
    37

    View Slide

  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にアクセス

    View Slide

  39. JSON Web Token
    Cookieはステートフルなセッション管理方法ですが、一方最近ではステートレスなセッション管理方法として略してJWT
    (ジョット)が利用されるケースも見られます。(サビ開はほとんどこれ)
    複数のマイクロサービスで構成されるサービスが増え、認証情報の持ち運びができることから人気が高まっています。
    Sessionと異なり、保存場所の選択肢にはインメモリ、WebStorage等も含まれます。
    保存場所が変わっても基本的なアプローチはCookieと同様の考え方である点に注意してください。(見られて困る情報は
    保存しない、JWTであれば署名を付ける)

    View Slide

  40. Web vulnerabilities

    View Slide

  41. Cross-site
    request
    forgeries(CSRF)

    View Slide

  42. CSRF
    ブラウザからクライアントが意図しないリクエストをサーバに送信させる攻撃手法。
    サーバー側でリクエストを十分に検証せず処理するように設計されている場合、正規のリクエストとし
    て扱われ、被害が発生する。

    View Slide

  43. イメージ
    正規サイトA
    5. 正規サイトからのリクエストなので
    正規リクエストとして
    処理される
    2. 悪意のあるユーザーが作成したサイトに
    正規サイトAに対する
    リクエストが埋め込まれている
    偽サイトA’
    4. ユーザーは気づかず
    リクエストが送信される
    6. ユーザーが意図しない結果が
    反映される
    1. 正規サイトAに
    ログイン済
    3. ユーザーが
    偽サイトA’にアクセス

    View Slide

  44. CSRF脆弱性の事例
    ● パソコン遠隔操作事件
    Wikipedia. 「パソコン遠隔操作事件」. https://ja.wikipedia.org/wiki/パソコン遠隔操作事件#犯行の手口
    その他にもパスワード変更、送金、商品の購入等を目的として仕掛けられることもあります。
    44

    View Slide

  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が
    作成できます。

    View Slide

  46. 解説
    46
    PortSwigger. Lab: CSRF vulnerability with no defenses.
    https://portswigger.net/web-security/csrf/lab-no-defenses

    View Slide

  47. CSRF脆弱性への対策
    根本的な対策は、正規のリクエストであるかサーバー側で確認する。
    ● トークンの埋め込み
    ● 本人確認をする
    ● Refererのチェック
    ● CookieのSameSite属性の設定

    View Slide

  48. トークンの埋め込み
    第3者が知り得ない秘密情報(=トークン)をリクエストに要求することで正規のリクエストであるか判
    別します。
    フレームワークを利用した開発を行う場合は、トークン生成、チェック機能が提供されていることが多
    いので、比較的容易に実装可能です。CSRF脆弱性における汎用的な対策にあたるため推奨される方法で
    すが、XSS脆弱性のあるサイトの場合はこの対策だけでは不十分となる点に注意してください。
    Youtube. 徳丸浩のウェブセキュリティ講座. 「XSS脆弱性があるとCSRF対策は突破できる」.
    https://www.youtube.com/watch?v=t23FHC5hRDk

    View Slide

  49. 本人確認をする
    例えば、購入ページであれば購入の確定前にパスワードを再入力するページを挟む等の方法を指しま
    す。
    Githubでもセキュリティ侵害が発生しうる重要な操作を行う箇所でこのような操作が求められるケースが
    あります。(sudoモード)
    ただし、重要なページに絞らないと煩雑な操作になってしまうことや、パスワード入力を求めるタイミ
    ングを誤ると脆弱性が混入することになるので注意が必要です。
    GitHub. GitHub Docs. Sudo モード.
    https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/sudo-mode

    View Slide

  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

    View Slide

  51. CookieのSameSite属性の設定
    Same Site=Lax 、もしくは Same Site=Strict の設定をすることで、クロスオリジンからのPOST等の危
    険なメソッドの実行時にCookieの送信がされません。
    送金や商品の購入のようなケースは防げますが、先程紹介した認証しなくても処理を実行できてしまう
    ケースは防ぐことはできないので、あくまで緩和策と捉えてください。

    View Slide

  52. Cross-site
    scripting(XSS)

    View Slide

  53. XSS
    攻撃者が攻撃対象となるWebサイトに、何らかの方法で混入させた任意のJavaScriptコードをクライアン
    トのブラウザ上で実行させる攻撃手法。Webアプリケーションにおける被害の中で最も多いのが、この脆
    弱性です。(IPA2021年第4四半期調べ)
    IPA. ソフトウェア等の脆弱性関連情報に関する届出状況. https://www.ipa.go.jp/files/000095630.pdf
    この脆弱性が混入すると様々な被害が発生します。
    ● 被害者となるユーザーになりすます
    ● 被害者となるユーザーが実行できる操作、アクセスできる情報の読み取り
    ● Webサイトの改ざん
    53

    View Slide

  54. Reflected XSS
    脆弱性のあるWebサイトのリンクに悪意のあるスクリプトを含ませて、偽メールや偽サイトに設置しま
    す。その後、ユーザーがそのリンク先へアクセスすることで悪意のあるスクリプトをクライアント上で
    実行させる攻撃手法です。
    典型的な例は検索画面等が挙げられます。
    リクエストしたクライアントへスクリプトが返ってくることから「Reflected XSS」と呼ばれています。
    54

    View Slide

  55. Reflected XSSのイメージ
    55
    攻撃対象のサイト
    1. 悪意のあるユーザーが作成した罠サイトに
    正規サイトAへのリンクが埋め込まれてい
    る。(パラメータに攻撃用のスクリプトが含
    まれている)
    罠サイト
    3. 罠サイト経由でアクセス
    4. ユーザーのブラウザ上で悪意の
    あるスクリプトが実行される
    2. ユーザーが
    罠サイトで罠を閲覧

    View Slide

  56. Stored XSS
    事前に攻撃者は悪意のあるスプリクトをWebサイトのデータベース等に保存させます。
    その後、ユーザーが閲覧する度、保存されている悪意のあるスクリプトが実行されます。Reflected XSS
    と比較して、誘導する手間がかからないため攻撃難易度は低いと言えます。
    典型的な例では、掲示板やブログのコメント機能等が挙げられます。
    56

    View Slide

  57. Stored XSSのイメージ
    57
    攻撃対象のサイト
    1. 悪意のあるユーザーが事前に攻撃対象
    サイトのDB等にスクリプトを登録する。
    2. ユーザーがアクセス
    3. ユーザーのブラウザ上で悪意の
    あるスクリプトが実行される

    View Slide

  58. DOM-based XSS
    サーバ側ではなく、フロントエンド側のコード脆弱性を悪用した攻撃です。
    利用方法について注意を払うべく代表的な機能には
    ● document.write
    ● innerHTML/outerHTML
    ● location.href
    ● eval
    等が挙げられます。
    58

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  68. 解説
    68
    JavaScriptスキームの仕組みを使った攻撃です。
    エスケープ無しでURLクエリの内容を画面要素に反映させてしまっている。

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  75. XSSの必須対策
    一般的には以下のような対策が取られます。
    ● リテラルを破壊するメタ文字のエスケープ
    HTMLであれば「<」「>」「”」「&」等。Scriptであれば「\」「’」「”」等。
    ● HTTPレスポンスに文字エンコーディングのセット
    75

    View Slide

  76. XSSの緩和対策
    また、その他に緩和策として以下の方法が取られます。
    ● ユーザーからの入力値の検証
    ● Content-security Policyの設定 ※1
    ● X-XSS-Protectionの設定(レガシーブラウザのサポートが必要な場合のみ)
    ● CookieのHttpOnly属性の有効化(セッションハイジャックのみ)
    ※1 Mozilla. コンテンツセキュリティポリシー (CSP). https://developer.mozilla.org/ja/docs/Web/HTTP/CSP
    76

    View Slide

  77. SQL injection

    View Slide

  78. SQL injection
    外部から受け取ったパラメータでSQLを実行する場合に、意図しないクエリが発行され、データベースが
    不正に操作される脆弱性。
    データベースの内容を直接閲覧、改ざんされる等、非常に影響が大きい脆弱性のため絶対に混入させて
    はいけないです。

    View Slide

  79. イメージ
    メールアドレス、パスワードが一致したらログインできる。
    内部的には以下のようなクエリが発行される。
    SELECT * FROM users
    WHERE email = ‘[email protected]’ and password = ‘password’;
    // OR 1 = 1で必ずtrueが返る
    SELECT * FROM users
    WHERE email = '[email protected]' OR 1 = 1 --' and password = '';
    メールアドレスに[email protected]’ OR 1 = 1 –-と入力することで
    パスワードの認証を突破できてしまう。

    View Slide

  80. SQL injectionの原因
    パラメータ化された部分を実際の値に展開する時、リテラルとして文法的に正しく文を生成していない
    ためです。
    SQL文として意味のある文字列が適切にエスケープされていないために、パラメータに与えられた値がリ
    テラルの外にはみ出した状態になり、リテラルの後ろに続く文として解釈され、SQLインジェクションが
    発生します。
    // シングルクォートが適切にエスケープされていれば、SQLインジェクションは発生しなかった
    SELECT * FROM users WHERE email = '[email protected]\' OR 1 = 1 --' and password = 'password';

    View Slide

  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
    💡 ヒント
    ● ソースコードの内部では受け取ったパラメータからどのようにクエリを作成するのか想像してみま
    しょう。

    View Slide

  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

    View Slide

  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テーブルと結合してみてください。

    View Slide

  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

    View Slide

  85. SQL injectionの対策
    基本的な対策は、プレースホルダーを利用してSQL文を組み立てるようにすること。
    IPA. 安全なSQLの呼び出し方. https://www.ipa.go.jp/files/000017320.pdf
    その他に、SQLの詳細なエラーメッセージをユーザーに出力しない対策も有効です。エラーメッセージか
    らテーブルの構成等が漏れ、攻撃に利用されるのを防ぎます。
    // パラメータ部分に?を割り当てている
    db.query('SELECT * FROM products WHERE categories = ?', 'Gift')

    View Slide

  86. OS command injection

    View Slide

  87. OS command injection
    外部から受け取ったパラメータでOSコマンドを実行する場合に、任意のコマンドが実行されてしまう脆
    弱性。
    利用シーンは少ないはずですが、OSコマンドを利用して処理を行う場合は別の方法がないか検討し直し
    てください。利用しないことがこの脆弱性からアプリケーションを守る一番の対策になります。

    View Slide

  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系列の現在のユーザーを表示するコマンドです。
    ● リクエストのパラメータが直接シェルスクリプトに引数として渡されると想定してください。
    ● ディレクトリの中身の参照やファイルの追加、削除等も行ってみてください。

    View Slide

  89. 解説
    89
    PortSwigger. Lab: OS command injection, simple case.
    https://portswigger.net/web-security/os-command-injection/lab-simple

    View Slide

  90. OS command injectionの対策
    基本的な対策は、OSコマンドを利用しない実装を検討すること。
    やむを得ず利用しなければいけないケースは
    ● ユーザーから渡された値は検証する。
    ● OSコマンドのメタ文字をエスケープする。(ライブラリに頼るのが吉)
    等の対策が考えられます。
    90

    View Slide

  91. Directory traversal

    View Slide

  92. Directory traversal
    外部から受け取ったパラメータでファイルの内容を表示させる場合に、意図しないファイルが閲覧され
    てしまうような脆弱性。
    実装によっては、改ざん・削除等もありえるため、非常に影響が大きいです。SQLインジェクション同様
    絶対に混入しないようにすべき脆弱性です。

    View Slide

  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を選択すると変
    更後のリクエストの内容を確認できます。

    View Slide

  94. 解説
    94

    View Slide

  95. 意図しないファイルの公開
    公開する必要のないファイルが公開ディレクトリに置かれていたり、公開不要なディレクトリが公開
    ディレクトリになっている等の設定ミスが起因で意図しないファイルが公開されてしまうケースもあり
    ます。
    以下は、nginxにおける設定ミスで起きるディレクトリトラバーサルの例です。
    Qiita. @no1zy_sec(no1zy). 「nginxの設定ミスで起こるパス トラバーサル」. https://qiita.com/no1zy_sec/items/e541f1c838874ff400bb, 2018年06月
    10日

    View Slide

  96. Directory traversalの対策
    基本的な対策は、外部からファイル名を指定できる仕様を避ける。
    その他に
    ● ファイル名にディレクトリを含めないようにする。(想定しているディレクトリ以外はアクセスさ
    せない)
    ● 非公開ファイルを公開フォルダに設置しない。
    アプリケーションの範疇を超えて対策できる場合は
    ● WAF(Web Application Firewall)の設置。
    ● ディレクトリリスティングの無効化。
    等の対策が考えられます。

    View Slide

  97. Conclusion

    View Slide

  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

    View Slide

  99. End

    View Slide