Cybozu Inside Out | サイボウズエンジニアのブログ

 

マージボタン1つで本番適用するための仕組み

こんにちは、Yakumoチーム兼コネクト支援チームの@ueokandeです。

本日はYakumoチームで構築した、デプロイパイプラインとその工夫について紹介します。 Yakumoプロジェクトはグローバル市場向けに、kintone.comをAWSから提供することを目指すプロジェクトです。 これまで日本のデータセンターから提供していたkintone.comを、現在AWS上に移行しています。 プロジェクトのもう1つのゴールとして、開発・運用体制を見直してクラウドネイティブなリリースプロセスを確立するというのがあります。

このプロジェクトは、国内向けのcybozu.comと完全に切り離されて開発がスタートしました。 ゼロからリリースフローを作るということで、これまでのインフラの経験や反省点を活かしつつ、チームの理想的なデプロイパイプラインの構築を目指しました。 そして最終的には、マージボタン1つで本番適用できるデプロイパイプラインを構築しました。 この記事ではYakumoチームのデプロイパイプラインと、それに至るまでの経緯を紹介します。

kintone.comのインフラ構成

kintone.comは異なる責務を持ったいくつかのサービスから構成されます。 たとえば、マルチテナントを実現するサービスや、非同期ジョブを処理するサービスなどです。 各サービスはKubernetes (Amazon EKS) を使ってデプロイされます。 それぞれのサービスが利用するデータベースやストレージは、AWSのマネージドサービスを利用します。

kintone.comのインフラ構成
kintone.com on AWSのインフラ構成

理想のデプロイパイプライン

インフラ構成の更新や本番オペレーションでは、運用するチームにとって負担が少ないことが理想です。 これまでの国内インフラの運用経験で、オペレーションを自動化するだけでは管理者の負担が減らないというのがわかっていました。 Yakumoプロジェクトでは、KubernetesやTerraformで採用された宣言的モデルという考えに基づいて、デプロイパイプラインを構築しました。

ソースコードは構築したいインフラの構成を表し、常に本番環境の設定はソースコードを見ればよいという状態を維持します。 そしてインフラの構成やアラートの閾値調整も、ソースコードを変更してマージするというフローにして、本番オペレーションを最小限に抑えました。

kintone.comのデプロイパイプラインの図
kintone.comのデプロイパイプライン
宣言的モデルをインフラに適用するのに必要なのが、差分検知と差分を埋めるオペレーションです。

差分検知とオペレーション

宣言的モデルでは、管理者が定義した状態を元に、実際のインフラを定義された状態に収束させます。 システムは、実際のインフラの状態と定義された状態との差分を検知し、その差分を埋めるオペレーションを実行します。

AWS CloudFormationやKubernetesは、この仕組を備えています。 ユーザーが定義したマニフェストファイルをCloudFormationやKubernetesに与えると、その定義ファイルに基づいたインフラの構築やコンテナをデプロイします。 またマニフェストファイルで何らかのパラメータを変更すると、対象リソースや関連するリソースに新しい設定を反映します。

一方でインフラレイヤーだけでなく、Yakumoチームが開発しているサービス群のデプロイもあります。 こちらもソースコードと本番環境の状態を常に一致させたいです。 サービスのソースコードを更新すると、新しいバージョンのイメージをKubernetes上にデプロイしたいです。 サービスの更新を検知するために、コンテナのイメージタグにソースコードのハッシュ値を採用しました。

ソースコードからイメージタグを生成

それぞれのサービスのイメージタグは、バージョン番号vX.Y.Zなどではなく、ソースコードから計算したハッシュ値を使います。 このソースコードには、サービス本体のコードだけでなく、コンテナに同梱するスクリプトやDockerfileも含みます。 ソースコードやDockerfileが更新されると、新しいイメージタグでコンテナレジストリに登録されます。

Kubernetesに適用するマニフェストは、レポジトリに含まれるソースコードからハッシュ値を計算して、イメージタグを埋め込みます。 ソースコードに更新があったサービスは新しいイメージタグが割り当てられ、 Kubernetesマニフェストの適用 (kubectl apply) でサービスのコンテナが更新されます。 開発者は、現在サービスのどのバージョンがデプロイされているかを考える必要がなくなり、本番環境は常にレポジトリにあるソースコードがデプロイされる事になります。

spec:
  containers:
    - name: my-service-a
      # 575C70E78FE448BC973EB46A46F4AE8Bなどのイメージタグが適用される
      image: quay.io/cybozu/my-service-a:{{ tag "my-service-a" }}

ケーススタディ: コンテナのベースイメージ更新

このしくみにより本番適用の自動化が容易になり、マージボタン1つで本番適用できるしくみができました。 ここで1つ例として、コンテナのベースイメージの更新を考えます。

例えばJVM用にビルドされたサービスの、Javaのバージョンの更新を考えます。 Yakumoチームでは管理の容易化のために、JVMサービスでは同じベースイメージを利用します。 セキュリティパッチなどで新しいJavaのバージョンがリリースされると、そのたびに本番環境のサービスを更新する必要があります。

一般的なベースイメージの更新作業は以下のとおりです。

  1. べースイメージのDockerfileを更新
  2. ベースイメージのリビルド (docker build)
  3. ベースイメージをコンテナレジストリに登録 (docker push)
  4. 各種サービスをリビルド (docker build)
  5. 各種サービスをコンテナレジストリに登録 (docker push)
  6. 各種サービスを本番環境に適用 (kubectl apply)

Yakumoチームのリリースフローでは、手順1.のDockerfileを更新してマージするだけです。

ベースイメージもまた、ハッシュ値のイメージタグを持ちます。 各サービスはベースイメージのタグを参照するため、ベースイメージが更新されると、それを利用するサービスも更新されます。 そして新しいイメージタグを持つサービスが本番環境に適用され、作業は完了です。

コンテナのベースイメージの更新と本番適用
コンテナのベースイメージの更新と本番適用

まとめ

以上がYakumoプロジェクトで取り組んだ、リリースフローとデプロイパイプラインの紹介でした。 宣言的モデルにより、「インフラやサービスの状態を確認し、影響範囲を考慮しながら、適用手順を作成する」という難しいフローも発生しません。 このリリースフローを確立したことで、本番環境への適用オペレーションというのがほぼなくなりました。 masterマージと本番適用が同義となり、切り戻しもgit revertするだけ、というフローです。

この理想のデプロイパイプラインも、一朝一夕で構築できたわけではありません。 これまでのcybozu.comの知見や、チーム内で積み重ねてきた改善活動によって現在の形に至りました。 このリリースフローで退屈な適用オペレーションを省けるだけでなく、製品の価値をより早くユーザーに届けることにも繋がります。

みなさんも、同じオペレーションを繰り返してるなと感じた時は、理想のリリースフローを探求してみてはいかがでしょうか?

 

kintone開発チームに聞いてみた ── Cybozu Tech Meetup #1 の質疑応答編

こんにちは、Yakumoチーム兼コネクト支援チームの@ueokandeです。 先日5月12日に、Cybozu Tech Meetup 『kintone開発チーム』を開催しました。

cybozu.connpass.com

当日はYouTube Liveで配信しました。 connpassでは300名近くの方にお申し込み頂き、当日の最大視聴者数も200人を超えました。 配信の録画は以下から観ることができます。

www.youtube.com

質疑応答の時間も、運営が想定してたよりも多くの質問が寄せられて、とても盛り上がりました。 時間の都合上、当日にすべての質疑に答えられなかったので、この記事ではそれらの質問への回答を紹介したいと思います。

「kintone × リモートモブプログラミング」 by 西 大樹

Q: モブプロに選ぶタスクの基準、タイミングが知りたいです。

基本的にタスクはモブで実施します。一方で、誰がやっても同じ結果になるタスクはモブでしません。 たとえば定形作業などです。

Q: チーム構成はどうやって決められますか? 気を付けていることはありますか?

それぞれのチームに、ベテラン1名が割り振られるようにします。 それ以外のメンバーも知識が偏らないようにバランス良くチーム分けします。

Q: ソースの書き方・フォーマットについては、なにかルール化していますか?またはツールを使ってる?

チーム内でEclipse Formatterの設定ファイルで共有しています。 またspotlessというツールを使って、CI (Continuous Delivery) 上でフォーマットエラーを検知します。

Q: 共有VMの詳細を差し支えない範囲でお聞きしたいです

社内にUbuntuのサーバーを立てています。

Q: モブプロを教育の手段とする場合どれくらいモブプロは活用されていますか?

チームに人が入ったら、とりあえずモブに入ってもらいます。 モブでキャッチアップやオンボーディングを実施します。

Q: ドライバーとナビゲーターの交代時間ってどのくらいの間隔で交代してますか?

チームによりますが、25分の作業時間と5分休憩のサイクルを繰り返しています。 作業時間や残り時間を測るために、Cuckooというモブプロタイマーを使っています。

Q: モブプロしてる時の休憩ってどういう風に取っていますか?みんなで一緒に休憩する?適宜抜けたり入ったりする?

休憩時間も接続を維持したままにしていますが、メンバーは全員、音声・映像をオフにします。

「ひよっこ kintone 開発プログラマーの冒険譚」 by 中川 遼太郎

Q: フルリモートになったのはコロナの影響もありますか?

はい、そうです!

Q: 自動テスト、進んでますか?

試験設計をQAエンジニアが担当して、プログラマがそれを自動化しています。

「IT業界未経験者が kintone QA として1年間がんばった話」 by 川畑 ひとみ

Q: 回帰試験は自動化されていないんでしょうか?

自動化が技術的に難しい、不安定である等の理由がなければ、基本的には自動化しています。

Q: QAエンジニアは全て内製ですか??ニアショアオフショア等を利用されていますか??

kintone開発チームとしては社外に依頼することはほとんどありません。 セキュリティチームなどは外部監査を依頼することがあります。

Q: 海外の拠点からQAをしてもらうことはありますでしょうか?また、その際のコミュニケーションは何を使うのでしょうか?

上海とベトナムにも開発拠点があるので、海外拠点のQAがいるチームもあります。 今はいませんが、長い間kintoneチームにも上海のQAがいました。

コミュニケーションツールは拠点関係なくkintoneが主で、必要に応じてテレビ会議やチャットも使っています。 またその際の言語は、上海メンバーは全員日本語ができるので日本語で、ベトナムメンバーは英語でやり取りしています。 ベトナムにはコミュニケーターさんがいるので、テレビ会議の通訳やテキストの翻訳をお願いすることも可能です。

Q: 上司がいなくてどのようなことに困りましたか?
Q: メンターはいるが上司はいない、の具体的な苦労点が気になります

自分の進むべき方向や相談などができる人が、明確に決まっていない点です。

Q: 上流工程でQAが関与する具体例等をお聞かせ頂けますか??

要件定義からQAも交えて議論しています。 PMからの「こういう機能の追加・改善をしたい」という相談に対し PG・QAで「他の機能へ影響しそうだが問題ないか」「どういう挙動になる想定なのか」等のフィードバックを返しています。 また製品仕様書の作成・修正も、PGとQAで一緒に行っています。

Q: QAエンジニアはシステムテストや受入テスト、開発エンジニアはユニットテストや統合テストを担当、等の担当分けをされていますでしょうか??

各テストの定義が異なるかもしれませんが、以下kintoneチーム内の用語で回答します。 自動化しているテスト(受け入れ試験)については、テストケースをQAとPGで一緒に考えてPGが自動化しています。 ユニットテストについては、一部管理しているもの以外は、PGの裁量で作成してもらっています。 機能試験や自動化されていない受け入れ試験等、手動で実施するテストについてはQAがすべて担当します。

Q: バグなのか仕様なのかで、プログラマと喧嘩になりませんか?

喧嘩にはならず、PGとQAエンジニアが納得するまで議論を続けます。

Q: 実際に今の業務でイメージと違ったことや苦労していることはなんですか?

想像よりもミーティングが多いと感じました。 また自分の知識の無さに苦労しています。

Q: QAエンジニアに未経験で実際なってみて、ギャップ等はありますでしょうか??

思ってたよりも、Webアプリケーションの知識が必要だと感じました。

Q: 今後どの様なスキルがQAエンジニアに必要と考えてらっしゃいますか??

WebアプリケーションのQAエンジニアとしては、Web技術の知識が必要だと考えています。

Q: QAをやっていて楽しいことはありますか?

仕様検討のときに、QAエンジニアの立場として、考慮漏れなどを指摘できたときにやりがいを感じます。

Q: 現在、転職活動中なので、参考にさせて頂きたいのですが、現在のQAエンジニアを通して、最終的にこういうエンジニアになりたい、といったようなビジョンがもしありましたら、教えて頂けますでしょうか。

「kintoneの仕様は私に聞けばOK」という人になりたいです。

Q: これからkintoneをどうしていきたいですか?

もっと多くの人に使ってもらえるようなサービスを目指したいです。

おわりに

初めてのオンライン開催のMeetupでしたが、当日は質疑応答や実況が盛り上がりました。 ご参加いただいた皆様、本当にありがとうございました。 今後もCybozu Tech Meetupを定期的に開催します。

次回は6月中旬ごろに、『Garoon開発チーム』にフォーカスをあてたテーマで開催する予定です。 近いうちに改めてconnpassで告知するので、お楽しみください!

 

2019年 報奨金制度を振り返って

こんにちは。Cy-PSIRT(Cybozu Product Security Incident Response Team)の福永です。

本エントリでは

  • 2019年に実施した報奨金制度の結果
  • 参加者からのご要望

について、ご紹介いたします。

2019年に実施した報奨金制度の結果

定量情報

2019年の定量情報は、次の通りです。*1

着信数認定数(暫定)報奨金支払金額(暫定)
489件193件15,348,000円

2015年から2019年の着信数、認定数、報奨金支払金額

着信数が増加した要因

着信数は前年度と比較して、40%増えています。

2019年4月20日(土)、21日(日)に2年ぶりのバグハン合宿2019を開催し、そのイベントで多数報告いただいたことが、着信数の増加に繋がりました。 489件中196件がバグハン合宿でのご報告です。

認定数が増加した要因

認定数は前年度と比較して、26%増えています。

複数製品で発生する脆弱性をバグハンターの方から多数報告いただいたことが、認定数の増加に繋がりました。

一方、1件あたりの支払金額が大きい脆弱性が少なかったことで、報奨金支払金額は前年度比73%におさまっています。

2019年度報奨金獲得ランキング

総額ランキング

獲得した報奨金額の合計が最も多かったのは、米山 俊嗣(三井物産セキュアディレクション) 様でした。上位5名中4名が2018年度にもランクインされた方々です。他にもたくさんの方からご報告をいただいています。皆様ありがとうございました。

順位掲載名
1位 米山 俊嗣(三井物産セキュアディレクション) 様
2位西谷完太(イエラエセキュリティ) 様
3位東内裕二(三井物産セキュアディレクション) 様
4位馬場 将次(イエラエセキュリティ) 様
5位Tanghaifeng 様


脆弱性1件あたりの高額ランキング

報告いただいた脆弱性1件あたりの報奨金額が高額だった方のランキングです。総額ランキングに続き、米山 俊嗣(三井物産セキュアディレクション) 様に報告いただいた脆弱性が1位でした。おめでとうございます。

順位掲載名
1位 米山 俊嗣(三井物産セキュアディレクション) 様
2位西谷完太(イエラエセキュリティ) 様
3位馬場 将次(イエラエセキュリティ) 様
4位米山 俊嗣(三井物産セキュアディレクション) 様
5位Sunshine Hui(@bttthuan) 様

2019年度ポイントランキング

総獲得ポイントランキング

2019年度から、報奨金とは別にポイントを付与する施策を開始しました。ご報告いただいたもので「認定の有無にかかわらず有益な情報だった」「レポートの内容が的確であった」など、様々な視点でポイントを付与します。累計獲得ポイントに応じて感謝の気持ちとしてオリジナルTシャツなどの特典をお贈りしています。 獲得したポイントの合計が最も多かったのは、米山 俊嗣(三井物産セキュアディレクション) 様でした。

順位掲載名
1位 米山 俊嗣(三井物産セキュアディレクション) 様
2位東内裕二(三井物産セキュアディレクション) 様
3位西谷完太(イエラエセキュリティ) 様
4位Tanghaifeng 様
5位馬場 将次(イエラエセキュリティ) 様

2019年のトレンド

「CWE-79:XSS」「CWE-200:情報漏えい」「CWE-264:認可・権限・アクセス制御」が同率1位です。 例年と比べると、「CWE-200:情報漏えい」の報告が多いという結果でした。

2019年度、CWEタイプに「CWE-94:コード・インジェクション」を新たに追加しました。今まで「CWE-20:不適切な入力確認」などに分類していたコードインジェクションの脆弱性を、「CWE-94:コード・インジェクション」に分類できるようにしました。

認定された脆弱性(脆弱性タイプ別)
認定された脆弱性(脆弱性タイプ別の件数)

参加者からのご要望

報奨金制度をより良くしていくために、 制度に参加いただいたバグハンターの方にアンケートを実施しました。皆様よりお寄せいただきましたご要望を一部ご紹介します。

運営に対するご要望

脆弱性の評価にかかる期間がまだ長い

報告が集中したり、報告いただいた内容が複雑だったりする場合には通常よりお時間をいただくケースもございます。ご了承ください。

評価大変かと思いますが頑張って下さい

あたたかいお言葉恐れ入ります。

報告用サイトに対するご要望

2019年12月に脆弱性報奨金制度の参加者向けに開設した報告用サイトに対するご要望です。

レポート記入欄にリッチエディターを利用できるようにしてほしい

早速設定しましたので、活用ください。

複数の報告事項を並列でやりとりしていたので事項ごとのステータスが把握しづらかった
報告した物の対応ステータスが分かるようになるといい

報告用サイトでは、ご自身の報告のステータスを一覧で確認できるようになっています。

メールアドレスを他の参加者に公開したくない

申し訳ございませんが、他の参加者から閲覧できても問題ないメールアドレスをお使いください。 報告用サイトにおいて、メールアドレスが他の参加者からも閲覧できるのは仕様です。

開示請求ボタンや修正ステータス欄も用意してほしい

対応予定はありません。 第三者への開示が可能かどうかは、報告用サイトのコメントにて都度ご確認いただく必要があります。 報告いただいた脆弱性を改修した際には、不具合情報公開サイトで公開していますので確認ください。

HackerOneなどの既存のプラットフォームを参考にしてほしい

他社のシステムも参考にしながら、使いやすいシステムを目指してまいります。

メールではなくてkintoneを使えばいいのにとずっと思っていた。報告用サイトには期待しかない

以前から要望いただいていた本件、ようやく実現しました。今後ともご報告お待ちしています。

2020年の取り組み

脆弱性報奨金制度 2020 始まります - Cybozu Inside Out | サイボウズエンジニアのブログ でご紹介しています。

さいごに

サイボウズでは、2020年も継続して報奨金制度を運営しています。

バグハンターの方にとって、魅力的な制度であり続けたいという思いで日々対応しておりますので、「サイボウズにこのような企画や施策を実施してほしい」というご要望がありましたら、 報告用サイトやメールでproductsecurity@cybozu.co.jpまでお気軽にご連絡いただければ幸いです。

今後とも、よろしくお願いいたします。

*1:2020年5月現在の暫定値であるため、評価の変動により増減する可能性があります。

 

Cookie の SameSite 属性について

こんにちは、フロントエンドエキスパートチームの小林(@koba04)です。

フロントエンドエキスパートチームでは、日々の業務としてブラウザやライブラリの更新情報をキャッチアップして社内で共有しています。

例えば先日、CSSのプロパティである image-orientation のデフォルト値が none から from-image に変わったため、画像の Exif 情報の扱いが変更されました。

https://www.fxsitecompat.dev/ja/docs/2020/jpeg-images-are-now-rotated-by-default-according-to-exif-data/

注: Firefox では COVID-19 の影響により、この変更は延期されました。(Chrome は予定通り 81 で リリースしています)

https://blog.chromium.org/2020/02/chrome-81-near-field-communications.html

このような変更はプロダクトに影響があるため、フロントエンドエキスパートチームでは社内の kintone に専用のスレッドを作成し、変更点などを整理して伝えています。

f:id:cybozuinsideout:20200430182958p:plain
Browser backward compatiblity / ブラウザ後方互換性情報

上記は実際の投稿の一部であり、以降に変更の詳細などを記載して取るべき対応について記載しています。 これらの情報の多くは社外にも公開可能なため、今回は Cookie の SameSite 属性について書きます。

今回確認するために使用したブラウザのバージョンはそれぞれ下記の通りです。

  • Chrome 81
  • Firefox 75
  • Safari 13.1

SameSite 属性とは

Cookie に指定可能な新しい属性です。 Chrome, Firefox, Safari の全ブラウザですでに実装されています。仕様は現在 Internet Draft の状態です。

https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-06

SameSite 属性には、次の値が指定できます。

None

これまでの Cookie の挙動通り、全ての cross-site なリクエストに対して Cookie が付与されます。

Strict

same-site に対するリクエストにのみ Cookie が付与されます。Cookie を使いログイン認証をしているサイトに対して cross-site なサイトに設置されたリンクから遷移した場合、リクエストに Cookie が付与されないため未ログイン状態になります。これは CSRF の攻撃に対しても有効ですが、ユーザーは cross-site なサイトからログインした状態で遷移できないため、ユーザーは再度ログイン処理や再読み込みが必要となります。

Lax

NoneStrict の間に位置するような指定です。cross-site を含むページ遷移のようなトップレベルのナビゲーションと、same-site のスクリプトや画像などのサブリソースに対するアクセスに対してのみ Cookie が付与されます。したがって cross-site のサブリソースに対するリクエストには Cookie が付与されません。ただし Lax の場合には、Strict と異なり cross-site なトップレベルのナビゲーションに対しては Cookie が付与されるため、ログインした状態で遷移できます。ただし、POST メソッドのような unsafe な HTTP メソッドによる cross-site なトップレベルのナビゲーションに対して Cookie が付与されません。したがって、POST メソッドなどを使ったフォームのサブミットに対する CSRF の攻撃に対しても有効です。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies

上記で言及した same-site や cross-site については、下記の記事がとてもわかりやすいのでオススメです。

https://web.dev/same-site-same-origin/

SameSite 属性のデフォルト値を Lax にする流れ

Chrome や Firefox では、この SameSite 属性のデフォルト値を None ではなく Lax に変更することを計画しています。 Chrome ではすでに SameSite 属性のデフォルト値を Lax にする変更を Chrome 80 から段階的にロールアウトしていました。 ただ、COVID-19 の影響を鑑みてロールアウトを一旦中止することを発表しています。

https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

Chrome の最新の状況については下記ページで確認できます。

https://www.chromium.org/updates/same-site

また、Firefox でも同様に Lax をするデフォルト値にするための作業が進められています。

https://bugzilla.mozilla.org/show_bug.cgi?id=1617609

Safari での SameSite 属性が None である Cookie の扱い

一方 Safari は、2020 年 3 月に 3rd Party Cookie を完全にブロックするとアナウンスしています。

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

3rd Party Cookieとは、cross-site なリクエストに対する Cookie を指します。

この挙動は SameSite 属性に None を指定した時の挙動と矛盾するため、Safari だとどうなるのだろうと思い調べてみたのが今回のきっかけです。

Safari 13.0 及び 13.1 で動作確認しましたが、3rd Party Cookie をブロックするケースとしないケースがあることがわかりました。 さらに挙動を調べてみたところ、Website tracking の設定である Prevent cross-site tracking の設定によって挙動が変わることがわかりました。

f:id:cybozuinsideout:20200430175409p:plain
SafariのWebsite Trackingの設定

この設定が有効になっている場合、SameSite 属性に None を指定しても 3rd Party Cookie は付与されません。 この変更がいつから適用されているのかは不明ですが、現在ではこの設定がデフォルトで有効になっているため、Safari ではデフォルトで 3rd Party Cookie が付与されない状態になっています。

ただし、Storage Access API を利用することで 3rd Party Cookie を利用可能にする方法が用意されています。

https://webkit.org/blog/8124/introducing-storage-access-api/

SameSite 属性を DevTools で確認する

今回この検証を行っている際、SameSite 属性が None の場合の各ブラウザの DevTools での表示が異なっていることがわかりました。 下記は、それぞれのブラウザ毎に取得したスクリーンショットです。

  • Chrome

    f:id:cybozuinsideout:20200430175439p:plain
    Chrome 81でのCookieの表示

  • Firefox

    f:id:cybozuinsideout:20200430175501p:plain
    Firefox 75でのCookieの表示

  • Safari

    f:id:cybozuinsideout:20200430175516p:plain
    Safari 13.1でのCookieの表示

Chrome は未指定と None が区別されています。したがって、現状だとデフォルト値が None なのか Lax なのかを理解する必要がありそうです。 Firefox はデフォルト値も含めて全て None と表示されています。 Safari は None の表示は — で表示されます。バグかと思い確認してみましたが意図した挙動のようです。

参考:

まとめ

今回は、Cookie に新しく追加された SameSite 属性について調べた内容を共有しました。

このようにブラウザの変更をキャッチアップして、プロダクト開発チームにフィードバックするのもフロントエンドエキスパートチームの仕事です。 サイボウズでは、ブラウザの更新情報をチェックするのが趣味というエンジニアを募集しています。

https://cybozu.co.jp/company/job/recruitment/list/front_end_expert.html

 

脆弱性報奨金制度にチャレンジしてみよう

こんにちは、Cy-PSIRTの長友です。 今回は、「脆弱性報奨金制度に参加したいけれど一歩が踏み出せない」という皆さんに向けて、制度への参加方法と報告時のポイントをお伝えしようと思います。
この記事はあくまで弊社の考える始め方やポイントであって、他社の制度に報告される際はそれぞれのルールや報告方法を熟読したうえで報告されることをお勧めいたします。

脆弱性報奨金制度とは

セキュリティ上問題があると思われる挙動を見つけて報告をしていただき、脆弱性として認められるとその深刻度に応じて報奨金をお支払いする制度のことです。弊社では2016年度から毎年少しずつルールを変更し、実施しています。
この制度は、バグバウンティと呼ばれていることもあります。
ちなみに、バグを見つけてたくさんの報奨金を稼いでいるかたもいらっしゃるようです。(参考:サイボウズが自社製品のバグに懸賞金を出す理由って?──バグハンター合宿に密着取材してきた

脆弱性報奨金制度に参加するには

まずは、脆弱性報奨金制度を実施している企業や団体を探しましょう。
弊社は、こちらのページでご案内をしています。
以下のプラットフォームで探してみると、弊社以外にも様々な分野の企業・団体が脆弱性に報奨金を支払っていることが分かるかと思います。

興味を持った制度が見つかったらルールや注意事項、手続きのフロー、セキュリティに関連する法令などをよく読んで理解しておきましょう。
たとえば、弊社の脆弱性報奨金制度では、本番環境に影響を与えずに脆弱性を探していただくために検証環境提供制度を実施しています。こちらの環境を利用していただくことで、安心して脆弱性を探すことが可能となっています。

脆弱性を探してみよう

やってみたい報奨金制度を見つけ、ルールや注意事項の確認や必要な手続きが済んだらさっそく脆弱性を探してみましょう。
たとえば、実際にサービスを触ってみながら、挙動や通信の内容をじっくり観察してみると、なにか違和感や気になることが出てくるかもしれません。その気になる箇所に対してさまざまな攻撃手法を試してみるともしかしたら脆弱性が見つかるかもしれません。地道な作業ではありますが、ハマるととても楽しかったりもします(私も業務で弊社の製品に対して脆弱性検証をしていますが、リクエストを観察したり気になるところをつついていると時間を忘れて没頭してしまうことがよくあります)。
OWASP Cheat Sheet SeriesHackerOneで公開されている脆弱性のレポート、PortSwigger Researchなども参考になるかもしれません。また、過去に報告した脆弱性を公開している方々のブログなどもとても参考になるでしょう。

脆弱性を報告しよう

いざ脆弱性と思しき挙動が見つかったら、報告をしましょう。
ここでは、サイボウズにご報告いただく際のフォーマットについてご説明します。ある程度このフォーマットに沿ってご報告いただきますと、弊社としては迅速な対応が行いやすくなります(いただいているお問い合わせの件数にも左右されますので、必ずしもすぐに返答できるわけではないですが……)し、報告者の方も脆弱性の整理がしやすくなるかもしれません。また、報告者・受付側で脆弱性に対する認識の齟齬が出にくくなり、適切な評価にも繋がるのでは、と考えています。

1. 脆弱性が再現する手順と環境を整理しましょう

まずは発見した脆弱性を再現させるための手順と、再現できた環境をまとめましょう。
環境に関しては、使用したブラウザ、OSは最低限あるとよいですが、もしそれ以外に何かソフトウェアを使ったのであればそれらも列挙してください。
また、脆弱性を確認した製品名と動作環境(クラウド版/Windowsオンプレミス版/Linuxオンプレミス版)、製品のバージョン(分かる場合は)も記載してください。
手順は1つの操作を1つのステップにまとめて記載するとよいでしょう(読みづらい場合はいくつかの操作をひとまとめにしてもよいかもしれません)。

例:
ブラウザ:Internet Explorer
OS:Windows 10
製品名:ガルーン(クラウド版) 4/1 時点の最新版
① スケジュールの登録画面を開く
② タイトル欄に以下の文字列を入力する

'><script>alert(1);</script>

③「保存」ボタンをクリックする
④ 保存されたスケジュールを開くと、JavaScriptが動作する

また、リクエスト内の値を変更する必要がある場合は、変更後のリクエストとレスポンスそのものや、値を変更するパラメータ名を記載するとさらに分かりやすくなります。
「いやいやそんな細かく書かなくてもわかるでしょう」と思われるかもしれませんが、詳細に書いていただくと、受付側で問題点の把握がスムーズに行なわれたり、そのあとのコミュニケーションコストがぐっと下がったりする可能性が出てくるので、ぜひ詳細に書いていただけるとうれしいです。

2. なぜ脆弱性と判断したのか簡単にまとめましょう

操作だけでも十分といえば十分なのですが、これになぜ脆弱性と判断したかの理由を記載いただくとより分かりやすい報告になるのではと考えています。先ほどの例であれば「開発者の意図しないJavaScriptが挿入されるため、脆弱性と判断した」といったところでしょうか。これを記載することで、報告側・受付側で「何が問題になるか」の齟齬が発生しなくなることにより、納得感のある評価につながりやすくなると考えているからです。その挙動の何が問題なのかを端的に表現していただけるととてもありがたいです。手順などが込み入った報告になればなるほど、この説明が重要になってきます。

3. 報告フォームに記入しましょう

ここまでできれば記入に必要な内容はほぼ完成です。報告フォームに沿って必要事項の記入をお願いします。

おわりに

今回は、脆弱性報奨金制度を運用する側から見た脆弱性報奨金制度の参加方法とちょっとしたコツをお伝えしました。
制度に参加したいと思っていらっしゃるみなさんにご活用いただければ幸いです。