はてなブックマーク

セキュリティを守る3つの脆弱性対策手法と、大きな工数削減を実現したyamoryの導入についてお伺いしました。

SBOM の必要性が増している背景や国内外の状況、具体的な SBOM の仕様、SBOM 対応の方法についてお伝えしました。

特にゼロデイ攻撃を抑えて 6 位にランクインしている「脆弱性対策情報の公開に伴う悪用増加」とは、まさに既知の脆弱性を利用した攻撃のことを指摘しており、SBOM を利用して現在利用されているソフトウェアやそのバージョンが管理できていれば、事前に被害を抑えられたものであると言えるでしょう。 SBOM を取り巻く国内外の状況米国大統領令における SBOM の位置付けこれまでに説明してきたような既知の脆弱性に対する攻撃に対処するため、米国では 2021 年 5 月に SBOM に関する大統領令が発令されました。この中には、米国国立標準技術研究所（NIST）と米国商務省電気通信情報局（NTIA）が協力して SBOM の最小構成要素を定めること、NIST がソフトウェアサプライチェーンを明確にするためのガイドラインを策定すること、また製品購入者への SBOM 提供に関する項目も含まれています。 さらに

DevSecOpsを成功させるためのポイントと共に「アジャイル開発におけるセキュリティ | パターン・ランゲージ」を解説します。

Amazon Translateでも利用されている機械翻訳フレームワークSockeyeとPythonのマイクロサービスフレームワークnamekoの任意のコード実行に繋がる脆弱性を発見し、報告を行い、CVEを2件(CVE-2021-43811, CVE-2021-41078)取得しました。 オープンソースソフトウェア(OSS)の脆弱性を発見、報告、CVEを取得までどのような過程を経たのか、OSSの脆弱性を見つける場合にはどのようにすると良いのか、報告方法はどうすればいいのか、今回の経験をもとにポイントを紹介します。 脆弱性報告の経緯 そもそもOSSの脆弱性を発見した経緯としては、前回の「TensorFlowだけじゃない！安全でないデシリアライゼーション in Python」の記事を書く中で、GitHubでyaml.unsafe_loadやyaml.UnsafeLoaderで検索すると脆弱な実

node-tar で発見された任意のファイルの書き込み・上書きの脆弱性(CVE-2021-32804)について調査を行いました。 node-tar 3.2.2, 4.4.14, 5.0.6, 6.1.1以前のバージョンを利用している場合、この脆弱性の影響を受けることがあります。 加えて、node-tarを間接的に利用している場合にも影響を受けることがあります。具体的には、npmもtarファイルを扱う処理にnode-tarを使っているため、脆弱なバージョンのnpmを使って、信頼できないtarファイルを処理することで影響を受ける場合があります。 今回は、CVE-2021-32804の修正コミットを確認してどのような脆弱性だったのか確認し、実際に脆弱性が再現できるのかDockerで環境を用意して検証を行いました。 また、npmにも影響があるかの検証も行い、こちらもDockerの環境にて確認を行い

XXE（XML 外部エンティティ参照）は、アプリケーションが XML を解析した際に XML の特殊構文を悪用されて発生する脆弱性です。本記事では XXE の仕組みから対策方法までを解説していきます。

CSRF（Cross-site Request Forgery：クロスサイトリクエストフォージェリ） は Web アプリケーションのユーザー（利用者）に意図しない通信リクエストを送信させ、利用者の意図しない処理をサービスに実行させることが可能となる脆弱性、またはその脆弱性を利用した攻撃手法を指します。 昨今のサイバーセキュリティにおける代表的な攻撃手法です。 本記事では CSRF の仕組みから対策方法までそれぞれ解説していきます。 CSRF の概要CSRF（クロスサイトリクエストフォージェリ）は、Web アプリケーションが偽装された（本来送信されるべきではない）リクエストを正規のものとして受信してしまう脆弱性、または攻撃手法を意味します。 CSRF には呼び名がいくつか存在し、以下のような名称で呼ばれることもあります。 シーサーフ XSRF リクエスト強要 セッションライディング ※名前の

Apache ライセンス （アパッチライセンス、Apache License）とは、オープンソースソフトウェアを開発・配布する際に用いられる代表的なオープンソースライセンスのひとつで、利用許諾のための条件などを定めているものです。 本記事では Apache ライセンスの概要から Apache License 2.0 の内容、適用方法、掲載例について解説していきます。 Apache ライセンスの概要 Apache ライセンスは、Apache ソフトウェア財団（ASF）によって作成されたソフトウェア向けライセンス規定です。 バージョン 1.1 以前は Apache Software License（ASL）と呼ばれていました。 世界中のソフトウェアで Apache ライセンスは利用されており、2020 年に GitHub で公開されているプロジェクトの 18% が Apache License

yamoryを導入するまでは、担当者が定期的に脆弱性情報のサイトを見に行き、情報を確認する形で実施していました。 ただし、このやり方だと月に2〜3日分のエンジニアの工数がかかってしまうし、担当者によって参照するサイトが異なる等やり方もばらばらであり、情報のばらつきや検知スピードの担保が困難な面もありました。 また、お客様から「脆弱性のニュースが出ているが、対応は大丈夫か」といったお問い合わせがあった際もその都度担当者が調査しており、やはり工数がかかっていました。 当時、お客様からオープンソースのライブラリの脆弱性についてお問い合わせを受けることが多く、その対応に追われている時にちょうど展示会で yamoryを知りました。 早速試してみたところ、お客様からお問い合わせを頂いていたライブラリの脆弱性がまさに検知されたので、詳しい説明を聞きたいとyamoryに連絡をしました。 エンジニアが上記の

OWASP Top 10 Proactive Controls（OPC）とは、ソフトウェア開発者向けに作成された設計や実装時のセキュリティのベストプラクティスをまとめたものです。 本記事では、本記事作成時点での最新版の OWASP Top 10 Proactive Controls 2018 についての概要と 2016 との比較について解説していきます。 OWASP Top 10 Proactive Controls 2018 の概要OWASP Top 10 Proactive Controls は、OWASP Top 10 などで有名な OWASP（Open Web Application Security Project）という Web アプリケーションセキュリティの情報共有、啓発を目的としたコミュニティが提供するドキュメントのひとつです。 OWASP Top 10 では、重要な We

ソフトウェアを開発されている方は、オープンソース・ソフトウェア（OSS）を利用して開発することが多いと思います。 OSS の導入時には最新のバージョンのものを利用するため脆弱性が含まれていなかったとしても、時間が経つにつれ脆弱性が新たに公開され、セキュリティリスクが高まることがあります。 自分たちが使っている全てのライブラリとそのバージョンを常に把握して、新たに公開された脆弱性がないかどうかを人手で監視することは非常に労力のかかる作業でしょう。 開発チームの規模が大きく、複数のプロジェクトを管理する場合にはより多くの工数がかかることが予想されます。 脆弱性管理ツール「yamory」 では、これらの作業を自動化し、自分たちに影響がある脆弱性情報だけを通知することができます。 また、脆弱性の対応優先度を自動で分類し、脆弱性への対策を提示することもできるので調査工数を削減することもできます。 本

CVE は脆弱性という言葉とともに出てくることが多い単語です。今回は CVE の概要から活用方法までをご紹介します。

本記事では、実際のコードを交えて Java における安全ではないデシリアライゼーションの解説を行い、この脆弱性を見つけた場合にどのように扱えばよいのか、どのような対策を行えばよいのかを解説します。

GPL ライセンス （ジーピーエルライセンス、GPL License、GNU General Public License）とは、オープンソースソフトウェアを開発・配布する際に用いられる代表的なオープンソースライセンスのひとつで、利用許諾のための条件などを定めているものです。 本記事では GPL ライセンスの概要から掲載例について解説していきます。 GPL ライセンスの概要 GPL は GNU General Public License の略で、GNU プロジェクトのためにリチャード・ストールマンによって作成されたライセンスです。 フリーソフトウェア財団（FSF; Free Software Foundation）によって公開・管理されています。 GPL ライセンスは、コピーレフト性を持つライセンスとして有名です。 WordPress を始め、さまざまなソースコードなどへ付与されているこ

2020 年 12 月 8 日に Apache Struts 2 の脆弱性 S2-061（CVE-2020-17530）が公開されました。 影響としては、Struts 2.5.25 までのバージョンで OGNL 式の二重評価によってリモートコード実行（RCE）が引き起こされる恐れがあります。 また、既に PoC（攻撃）コードが公開されていますので、Apache Struts 2 を利用されている方は 2.5.26 へアップデートを行うことをお勧めします。 Security Bulletins S2-061 https://cwiki.apache.org/confluence/display/WW/S2-061 yamory では、PoC コードの検証を行い悪用可能であることも確認しました。 脆弱性を悪用した攻撃の仕組み 検証環境今回は以下のような環境で検証を行いました。 ベースイメージ

MIT ライセンス （エムアイティーライセンス、MIT License）とは、オープンソースソフトウェアを開発・配布する際に用いられる代表的なオープンソースライセンスのひとつで、利用許諾のための条件などを定めているものです。 本記事では MIT ライセンスの概要から掲載例、各種ライセンスの比較について解説していきます。 MIT ライセンスの概要MIT ライセンスは、マサチューセッツ工科大学で作成された代表的な寛容型オープンソースライセンスのひとつです。 MIT ライセンスの規定はシンプルで、ソフトウェアを自由に扱ってよいこと、再頒布時に著作権表示とライセンス表示を含めること、作者や著作権者はいかなる責任も負わないことを定めています。 MIT ライセンスの大きな特徴は、MIT ライセンスを用いて公開されたプログラムを改変したり、自らのプログラムに組み込んだ派生的な著作物は、ソースコードを公開

HTTP リクエストスマグリング（Http Request Smuggling, HRS）は、フロントエンドの Web サーバー（リバースプロキシー、ロードバランサーなど）とバックエンドの Web サーバーで、 HTTP リクエストに対し異なる解釈をしてしまうことで発生する脆弱性です。 この脆弱性が悪用されると、攻撃者によって作成されたリクエストを別のユーザーのリクエストに追加し、フィッシング、クロスサイトスクリプティング（XSS）、キャッシュ汚染、セキュリティ制御のバイパスなどの影響を受ける可能性があります。 本記事では HTTP リクエストスマグリングについての概要から対策方法についての解説と、実際に公開されているライブラリの脆弱性について少し掘り下げて解説します。 HTTP リクエストスマグリングの概要 HTTP リクエストスマグリングが発生する仕組み HTTP リクエストスマグリン

オープンリダイレクト（Open Redirect）攻撃は、リダイレクト処理の実装不備を悪用し、被害者となるユーザを意図しない URL に誘導をする攻撃手法・脆弱性です。 意図しないリダイレクトを発生させるだけですと、大きな問題は起こせないと思われるかもしれませんが、正規ドメインから悪性ドメインへ意図しない誘導を行える場合、フィッシング詐欺などに悪用される可能性があります。 フィッシング詐欺に悪用された際のオープンリダイレクトは、危険度が高まります。​ 本記事では、オープンリダイレクトの原因と対策について触れたあと、対策方法や、開発者としてこのオープンリダイレクトを見つける方法についてご紹介します。 また、オープンリダイレクトを使った高度な攻撃手法（OAuth2 を狙ったオープンリダイレクト）の例について解説します。 オープンリダイレクトの概要 オープンリダイレクトは、「正規サービスのドメイ

ビジネススピードを確保しつつ、脆弱性のリスクを抑えるにすれば良いのでしょうか。本記事では、Clean Architecture を用いて脆弱性への対応力「レジリエンス」を高めるアプローチを解説します。

バッファオーバーフローはメモリ上のバッファを超えて書き込みが行われる攻撃手法です。アプリ開発者の視点から解説しました。

パストラバーサルは、本来アクセスできないディレクトリに存在するファイルに対して、脆弱性を悪用してアクセスする攻撃手法です。本記事では、パストラバーサルの脆弱性について概要説明・対策方法・実例までをご紹介します。

リバースブルートフォース攻撃（逆総当たり攻撃、リバースブルートフォースアタック）とは、不正ログインを目的とする攻撃手法で、パスワードなどを固定して、ID 部分を変えながら総当たり的にログイン認証を繰り返していく攻撃です。 「ブルートフォース攻撃（総当たり攻撃）」という攻撃も存在していますが、リバースブルートフォース攻撃はその逆に当たる手法（パスワード部分ではなく ID などの部分の変更）を用いた攻撃になります。 総当たり攻撃の対策として、パスワードを一定回数間違えた場合に、対象アカウントをロックする手法が一般的には知られています。そうすることで「一定回数までしか攻撃者はログインを試せないため安全」という前提が作れるためです。 しかしリバースブルートフォース攻撃では、パスワードではなくユーザー ID 側を変更しながら攻撃を行うため、特定アカウントへの大量の認証施行は行われず、アカウントロック

クリックジャッキング （クリックジャック攻撃）とは、被害者にクリックさせたい URL やサービスの機能を、他のサイトの表示で覆い隠すことにより、視覚的に騙してクリックを行わせる攻撃手法です。 この攻撃により、悪意のあるサイトを訪問したユーザーがページ上をクリックしてしまうと、他のサイト上にある個人情報の流出や、データの破壊などの不利益を被ってしまう恐れがあります。 この脆弱性が 2002 年に報告されて以来、 Twitter や Facebook などの SNS を含むさまざまなサービスでクリックジャッキングの悪用が報告されています。 また、パソコンだけではなく、スマートフォンを使っていてもクリックジャッキングに出くわす可能性はあります。 このような被害者のアクションをトリガーとして攻撃が実施される脆弱性は、受動的攻撃と呼ばれています。 本記事ではクリックジャッキングの概要から、攻撃の仕組

yamory は、2020 年 8 月 27 日をもちましてリリースから 1 周年を迎えました。 ここまでご愛顧いただいているのは、yamory をご利用いただいている企業さま・ユーザーさまをはじめ、yamory に関わってくださっている皆さまのご支援のおかげです。心より感謝申し上げます。 yamory は 2019 年 8 月 27 日に、「すべてのエンジニアにセキュアな開発を。」を掲げ、アプリケーション・ライブラリの脆弱性管理に特化したサービスとしてリリースしました。 1 年が経ち、より多くの方々にご利用いただきやすいサービスを目指して機能拡充を進めてまいりました。また、ご利用いただいております企業さまも増えてきております。 今回は yamory の 1 周年を記念して、この 1 年間の取り組みを時系列でご紹介させてください。 リリース1周年を記念して、ステッカーを配布します yamo

書き起こしメディア「ログミーTech」に、yamory 主催 DevSecOps 勉強会 #1 の登壇レポートを掲載いただきました。

2020 年も半ばを過ぎましたがみなさまいかがお過ごしでしょうか。 yamory は 2019 年 8 月 27 日にサービスをリリースし、まもなく 1 年が経とうとしています。 この 1 年を振り返ると、Go 言語のサポートやIPA のセキュリティ製品の有効性検証の試行において対象製品に選ばれたり、オートトリアージ機能の特許取得、イエラエセキュリティ様との業務提携など多くの取り組みを行なってきました。 最近では、Jira Cloud 連携やライブラリの依存関係のツリー形式での表示、シングルサインオン（SSO）連携機能もリリースしました。 機能拡充と並行し、私が所属するセキュリティチームでは、日々新たに発見されるさまざまな言語のフレームワークやライブラリの脆弱性の調査・分析に力を入れております。 今回は 2020 年脆弱性管理レポートと題して、yamory 利用者様からのアンケート結果を交

HTTP ヘッダインジェクションは、データを適切にチェックせずに HTTP レスポンスヘッダに反映させてしまうことで発生する脆弱性・攻撃手法です。本記事では HTTP ヘッダインジェクションの概要・対策方法について解説します。