はてなブックマーク

VAddyの事業責任者の市川です。 VAddyは、誰でも手軽に使えて自動化もできるクラウド型の脆弱性診断ツールとして開発をし、5年間運用してきました。様々なWebアプリケーションの検査に対応できるようにチューニングし続け、加えてプライベートネット版対応、シングルサインオン認証アプリ対応、SPA向けの複数FQDN対応などを行なってきました。今までは、よりうまく検査を行う方向での改善を続けてきていて、今後もこの方向は変わりません。 この1年ぐらいで世の中の流れが少し変わってきたかなと感じるようになりました。組織内のアカウント管理でしっかりした運用をしている企業では、VAddyのチーム機能では不十分なケースや、検査項目をもう少し増やして欲しいという要望が目立ってきました。今回のエンタープライズプランは、そのような組織向けに最適なプランになっています。 検査項目の増強 VAddyの既存プラン（Pr

本日、複数のFQDNをまたぐアプリケーションの脆弱性検査機能をリリースいたしました！ これまでのVAddyでは検査対象として登録できるのは単一のFQDNで構成されたWebアプリケーションだけでしたが、本日リリースした機能によって複数のFQDNから構成されているWebアプリケーションの脆弱性検査が実現されます。 中規模以上のWebアプリケーションでは機能ごとにFQDNが分かれているケースが多くあります。 例えばECサイトなどで見られる以下のようなケースです。 ログイン機能：login.example.com 会員ページ：mypage.example.com これまでのVAddyではこのようなアプリケーションの脆弱性検査を行うには、それぞれのFQDNで個別に検査を実行する必要があったため、別FQDNで提供されているログイン機能を経由しないと動作しないアプリケーションの検査はできませんでした。

先日このようなブログ記事が公開されました。 クラウドサービスを脆弱性診断する時のお作法 とある企業において脆弱性診断をされている「とある診断員」さんのブログで、クラウドサービス（IaaS）の利用者が脆弱性診断をする際の注意点がまとめられています。 この記事の中に 脆弱性診断を実施する際には、ご自身の利用しているプラットフォームの事業者にちゃんと確認をした方が良いと考えます。 という言及があります。 VAddyはサーバー上のWebアプリケーションに対する脆弱性診断（ブラックボックステスト）を行うサービスですので、これに当てはまります。 上記のブログ記事ではAWS、Microsoft Azure、Google Cloud Platformのポリシーをまとめていただいているので、便乗して日本国内のクラウド事業者のポリシーについてまとめてみました。 主要クラウド事業者の脆弱性診断に関するポリシー

VAddyは手軽にWebの脆弱性検査が実施でき、CI連携など自動化も可能なSaaSです。 既存のVAddyは、VAddyサーバからインターネット経由でWebサーバに検査リクエストを送る仕組みのため、検査対象のWebサーバはグローバルIPを持つ環境が必要でした。 ユーザからの要望として多く挙がっていたのが、イントラネット環境しかテストサーバがない、手元の開発マシンしかない、Travis, CircleCIのようなCI as a Serviceの環境でも検査したい、といったものでした。 これらを解決するために、今回PrivateNet版VAddyをリリースしました。 https://vaddy.net/ja/docs/private-index.html 本機能を開発してテストしている段階で、私の手元のMac上で動いているアプリケーション、VMwareのLinux環境で動いているアプリケーショ

VAddy Adventカレンダー18日目の記事です。 @vaddynet の中の人、西野です。 VAddyは開発者フレンドリーなWebアプリケーション脆弱性検査サービスです。 セキュリティの知識がなくても簡単にWebアプリケーションの脆弱性検査ができます。 いつもは開発者向けの内容ですが、今日は開発者以外の方向けの記事を投稿しようと思います。 まず初めに質問です。 皆さんの中で脆弱性検査を実施した／実施を指示した（された）ことがある方はどれくらいいらっしゃるでしょうか？ このブログに辿り着いた皆さんはセキュリティ意識の高い方々だと思うので、実施したことがあると答えられる方はそれなりにいらっしゃるでしょう。そういう方々にとっては今日の記事は退屈な内容になるかもしれません。 今日は「脆弱性検査」に馴染みのないスタートアップ経営者、マネージャー、サイトオーナー、Webディレクター、プログラマー

VAddy Adventカレンダー11日目の記事です。 昨日に引き続き@vaddynetの中の人、西野と申します。 バンド（ドラム）とバイクが趣味ですw 先週末のカレンダーで弊社のことが書かれていたので、それに関連して会社のことを少々。 特に結論のない自分語りですがお付き合いいただければと思います。 受託開発から自社サービスへのシフト 先週市川が書いていたとおり、ビットフォレストという会社はWeb制作会社としてスタートしました。 Webシステムの開発のみならず、インフラ、デザイン、コンテンツ開発など、いわゆる「Webサイト」の立ち上げに関わる作業をワンストップでこなせるというのが強みの一つでした。 当時は（も）ビットフォレストは小さな会社だったので、協力会社さんやフリーランスの皆さんの力を借りながら、個人商店のような小さな「ホームページ」から一部上場企業のバックエンドシステムの開発まで一通

早いもので2016年も半分が過ぎてしまいました。 前回、前々回に引き続き、2016年6月29日（水）にコワーキングスペース茅場町 Co-EdoにてVAddyユーザーミートアップ Vol.3を開催しました。 今回のゲストは株式会社マネーフォワードで社内のセキュリティを担当している鈴木研吾様をお迎えしました。 セッションの様子 「VAddyの仕組み2016」 株式会社ビットフォレスト VAddy プロダクトマネージャー　市川 今回はミートアップ初参加の方も多くいらっしゃったので、あらためてVAddyの機能やコンセプトをご説明させていただくとともに、最近お客様から多く問い合わせを頂いている詳細な脆弱性検査内容についてお話させて頂きました。 【発表資料】 ・VAddyとは http://www.slideshare.net/ichikaway/vaaddy-vaddyvol320160629 ・V

本記事はDevOps.comに掲載された記事を許可を得て日本語訳したものです。 “This post was originally published on the DevOps.com.” DevOpsを採用する組織はもっとセキュリティに注意を払うべきであると、Threat Inteligenceの創設者Ty Millerは提案しています。 「ここ5年ぐらいのAnonymousやLulzSecのようなハッカー集団の活動をきっかけに、ITセキュリティに対する主要なアプローチは変化してきており、アプリケーションのライフサイクルへの統合が強くなってきました。」Ty Miller氏 開発の初期段階でセキュリティに注意が払われなければ、リリースまでに設計や開発の手戻りがおこる可能性が高くなります。それは最初からセキュリティが考慮された場合に比べて100倍ものコストがかかることもあります。 そもそも

本記事はGoCDブログに掲載された記事を日本語訳したものです。 “This post was originally published on the GoCD blog.” この記事は「 It’s not Continuous Delivery if you can’t deploy right now」というシリーズの第二弾です。 今回はセキュリティテストのパイプラインでより一般的なツールをいくつか取り上げようと思います。 私の経験では、自動化されたセキュリティテストがCD（Continuous Delivery）パイプライン上に組み込まれているのをほとんど見たことがありません。 開発者が自信を持って製品をリリースできるようにすることがパイプラインの役割だとするならば、製品のセキュリティについても自信を持てるようなるべきです。全てを取り上げることはできませんが、セキュリティテストの自動化

VAddyでは脆弱性検査を行う際に、ユーザが作成したクロールデータを使います。 クロールデータとは、検査対象のURLやパラメータを記録したもので、VAddyではクロールデータを元に機械学習を使ったスキャナーがサイトの構成を把握し検査を行います。 これまでWeb画面からのスキャン開始操作に限り、過去のクロールデータを選択し検査できるようにしていました。 「過去のクロールデータを使った脆弱性検査が可能になりました」 今回、WebAPI経由での過去クロールデータの指定をした検査が可能になりました。同時に、Jenkinsプラグインもアップデートし、Jenkins経由からでも過去のクロールデータを指定したスキャンが可能になっています。 例えば、全てのパターンを網羅したクロールデータを作成しつつ、一部の画面だけの検査のクロールを作成し、JenkinsなどのCI経由では全てのパターンの検査を、Web画面

VAddyの海外プロモーションの一環として、2015/11/16からワシントンD.C.で開催されたphp[world]2015にスポンサーとして参加してきました。サービスのプロモーションで海外カンファレンスへの参加を検討している方もいると思うので、この記事が参考になれば幸いです。 なぜphp[world]を選んだのか？ VAddyは全世界のWebアプリケーション開発者をターゲットにしています。 日本国内ではミートアップやカンファレンスなどでVAddyを直接説明して意見を伺う機会がありますが、海外だとなかなかそうもいきません。ソーシャル・ネットワークやメール等で拾える声はたかがしれています。 VAddyを始めてから痛感したのは、サービスの開始直後は足を使わないとどうにもならないこと、直接会って話をする／聞くことが一番の近道ということです。 そういう意味でアメリカのWebアプリケーション開発者

※2017年9月12日追記 2017年9月12日に価格変更を行いました。 料金プラン改定のお知らせ 本記事に掲載されているFreeプランおよびStandardプランの新規申し込みは終了しております。 昨日、VAddy有料プランをリリースしました。 「クラウド型Web脆弱性検査ツール「VAddy」がチーム機能や検査項目を追加した2つの有料プランを開始」 これまで1年間は無料プランのみで運用しており、そのフィードバックや運用結果を元に有料プランを設計しました。 この記事では、有料プランに込めた思いや悩みを書いていきたいと思います。 無料プランはSQLインジェクションとXSSの検査が何度でも無料で実施でき、CI連携も可能です。 有料プランと無料プランの違いは大きく分けると、 ・検査項目の追加 ・長時間の検査時間にも対応 ・チーム機能 ・過去の検査結果の参照期間 になります。詳細はプレスリリース記

新しい機能を考えるときに、こうしたいとか、ユーザの事を考えてこうすべき、ということを全て出し切らないといけない。出し切った後にどうするかを議論して取捨選択すれば良いのだけど、出し切る前に実装する自分が出てきて、それはどうかなーみたいに思考を止めに入ってくる。そんな悩みをブログ記事にしました。 現在、継続的WebセキュリティテストサービスVAddyを開発運営しています。 VAddyチームは主に、セキュリティ検査のエンジンを作ってるセキュリティエキスパートの佐藤（金床）と、契約などの事務処理やPR、サポートをしている西野とプロジェクトリーダーの私(市川)の3人構成です。 私は全体の方針を決めて設計、Web画面周りの実装、サーバ運用、技術サポート、エバンジェリスト活動(勉強会などで発表)をしています。 現在のVAddyは無料プランのみを提供しており、2015年9月に予定している有料プランのリリー

VAddyでは、テスト対象のサーバの登録とクロールデータの生成を行った後に脆弱性検査を開始します。 クロールデータとは、スキャン対象のURLやパラメータを記録した物で、これを元にVAddyのスキャナーがサイトの構成を学んで検査を行います。 クロールデータの生成方法は、ブラウザのプロキシ設定でIPとポートをVAddyの指定のものに変更して、その後、検査対象のWebサイトをユーザが操作していきます。 VAddyを本格的に使うために、このようなクロールデータの生成が必要なのですが、まずは簡単にスキャンを試してみたいというユーザからすると手間がかかるイメージがありました。 そこで、プロキシ設定の変更も不要で、VAddyの画面からURLを入れてクロールデータを生成する簡易クロール機能をリリースしました。 これにより、本格的にVAddyを使う前にまずはVAddyの検査がどういったものかということが簡単

VAddyは開発者向けツールという位置づけですが、今回は少し趣向を変えて「非エンジニア系WebディレクターのVAddy活用法」をお話したいと思います。 http://vaddy.net/ja 「Webディレクター」の肩書を持っている方の出身は、営業、Webデザイナー、フロントエンドエンジニア、プログラマー、新卒でそのまま（！）などさまざまだと思います。今回のお話は「非エンジニア系Webディレクターさん」に向けたものですので、技術系Webディレクターの方はそっとタブを閉じてください（笑） さて、非エンジニア系Webディレクターの皆様のうち、「SQLインジェクション」「クロスサイトスクリプティング」などの用語はどれくらいご存知でしょうか。また、Webアプリケーションの受け入れテスト（動作確認）を行う際、アプリケーションの脆弱性まで意識されている方はどれくらいいらっしゃいますでしょうか？ 私の印

VAddyはCIツールと連携し、継続的なセキュリティテストを実現するクラウド型Web脆弱性診断サービスです。 http://vaddy.net/ja/ VAddyではHTTP/HTTPSのWebアプリケーションに対して脆弱性検査が可能となっていますが、ポート番号は80番と443番のみとなっていました。 VAddyのスキャンはテストサーバに対して行うため、80番、443番以外を使っているケースがあり、今回任意のポート番号へのスキャンに対応しました。 サーバ登録時に、オプション項目でPort Numberという項目があるので、そこに任意のポート番号（例えば8443など）を指定してサーバ登録します。 サーバの登録が完了すると、Server Nameの欄に登録したサーバ名:ポート番号という形で表示されます。 後はそのポート番号を含んだURLをクロール情報として登録すれば、そのポートに対してスキャン

VAddyはCIツールと連携し、継続的なセキュリティテストを実現するクラウド型Web脆弱性検査ツールです。 最近のモバイルアプリケーションやシングルページアプリケーションのような構成ですと、APIサーバに対してPOST/PUTリクエストを送信する際に、パラメータはJSON形式というのも多くなりました。 今回、このJSON形式の場合でも、JSONデータに含まれるパラメータに対してSQLインジェクションの検査ができるようになりました。 これにて、Angular.jsやBackbone.js、iOSやAndroidアプリケーションと通信するAPIサーバ側の検査が可能となりました。 実はAPIサーバのJSONデータの検査対応はそれほど優先度が高くなかったのですが、VAddyミートアップを通してユーザからの要望を頂いた結果、優先すべき項目となり、すぐに実装してリリースとなりました。 このようにVAd

VAddyの管理画面では、脆弱性が1件以上あれば、脆弱性のあるURLと問題となっているパラメータ名、問題(SQLインジェクション or XSS)が表示されます。 この情報があれば開発者は問題となっている箇所のソースコードが特定でき、修正が可能です。 しかし、実際にどのような検査リクエストを送ったのか公開していなかったため、ユーザが手軽にローカル環境で再現することが困難でした。 今回、VAddyのスキャンサーバから送った検査リクエストのデータを公開することで、同じようなリクエストを手元で再現して確認に使えるようになりました。 VAddyのスキャンを終えて問題点が1件以上存在する場合、下記のような検査結果の詳細画面が表示されます。 画面下のテーブル表示の箇所で、4件の脆弱性情報が表示されており、その一番右に「Show」ボタンがありますので、それをクリックすると、下記のようなVAddyサーバから

Jenkinsユーザカンファレンス2015に参加・発表してきました。 参加者も700人ぐらいいたようで非常に活気があり、各セッションもJenkinsを中心としたシステムの話から、何故CIなのかなど、多岐に渡る発表があり刺激的でした。 我々は5分のLTで発表させて頂きました。短い時間なので色々と説明を省略した箇所がありましたが、アップロードしたスライドではある程度補足しています。 継続的セキュリティテストのコンセプトでVAddyを開発・運用していますが、世界でも同じコンセプトでGoogleが社内ツールとして開発していたり、カーネギーメロン大のブログで提唱されていたりと、あと数年もすると大きなトレンドになるのは確実です。 継続的セキュリティテストが普及するためには、専門知識不要で簡単に使えて、検査精度が高く、CIのフローに乗るように短時間で終わる必要があります。これらのハードルを乗り越えるため

VAddyコア部分を開発している金床です。 2014年もそろそろ終わりに近づきました。今年のはじめには1行のコードすらも存在していなかったVAddyですが、春頃から市川氏と私がノリノリになったこともあり、現在は無事にJenkinsプラグインまで完成し、当時イメージしていたCIへの自然な統合が可能な状態となっています。実案件に組み込む例も出てきており、振り返ってみれば2014年は非常に手応えを感じた年にすることができました。 CIは広く普及し始めています。基本的にはビルドやユニットテストを頻繁に実行することで、デプロイ時の心理的、または実際の負荷を下げるために利用されていると思います。 VAddyはCIのサイクルの中でSQLインジェクションやクロスサイトスクリプティングのような、いわゆるウェブアプリケーションの脆弱性診断を行うためのサービスです。 私がVAddyのアイデア(CIに組み込むため

継続的セキュリティテストサービスVAddyのスキャンエンジンをアップデートしました。 本アップデートにより、今まで対応していなかったURLパスに含まれるパラメータの検査が可能になりました。 今までは、 /item.php?id=99のようにクエリストリングを対象にSQLインジェクションやXSSの検査を行っていました。 最近のWebアプリケーションフレームワークを使ったサイトでは、/item/99のようなセマンティックURLのパターンが多くなったこともあり、URLパスに含まれるパラメータも検査対象とすることにしました。 URLパスの検査を追加すると、検査パターン数が大幅に増えるため検査時間が延びることが多いです。したがってOWASP ZAPのような検査ツールではオプション項目の扱いとなっています。 VAddyでは、セマンティックURLのパターンを自動判別し、効率的な検査を実現することで、実行

VAddyとCircleCIを組み合わせると、簡単に継続的セキュリティテスト環境が実現できます。 git pushするとCircleCIのジョブが起動し、テストサーバにコードをデプロイ、そのテストサーバに向けてVAddyからWebの脆弱性検査を実施します。 今回は、 git push -> Unit test -> Deploy(Staging) -> VAddy test -> Deploy(Production) という流れで解説します。 Unit testが失敗した場合は後続の処理は行われませんし、VAddy testが失敗した場合も本番にコードがデプロイされません。 こうして、ユニットテストとWeb脆弱性検査を定期的に実施して問題のないコードのみを本番環境にデプロイできます。 前提 この記事では、CircleCIインスタンス内に立てたWebサーバに対しての脆弱性検査ではなく、Cir

2014/11/18に、Googleがセキュリティスキャンのテスト用のWebアプリケーション Firing Range を公開したようです。 http://googleonlinesecurity.blogspot.jp/2014/11/ready-aim-fire-open-source-tool-to-test.html Webアプリケーションのリポジトリはこちら。 Googleは内部で自動セキュリティテストツール（コードネーム Inquisition）を作っていて、開発サイクルの中でそれを実行してセキュリティテストを自動化しているとのこと。 その内部用のセキュリティスキャンツールの評価のために、XSSを中心とした脆弱性のパターンを多く含むセキュリティテスト用Webアプリケーションを作ってオープンソースとして公開したようです。 VAddyと同じように、Googleも内部では自動セキュリ

継続的セキュリティテストサービスVAddyはJenkinsプラグインを提供しているため、Hipchat Jenkinsプラグインを入れれば、CIの中でWebアプリケーションに対して脆弱性検査を自動実行して、その結果をHipchatに通知できます。 Jenkinsには、ビルド後の処理にEmail通知というものが標準であるため、ビルド結果はメールで受け取りできます。ただし、これはビルド失敗のみメール通知されます。 Hipchatプラグインを入れると、ビルド後の処理にHipchat通知が追加でき、下記画像のようにビルドの成功、失敗がHipchatに通知され、ビルド結果へのリンクもメッセージの中に入るため便利です。 設定は簡単で、JenkinsプラグインをインストールしてAPI情報を入れるのみです。手順を説明します。 ステップ1 プラグインのインストール Hipchatプラグインは、「Jenkin

VAddyとは? VAddyは我々が開発している、「CIで脆弱性検査（セキュリティテスト）を」というコンセプトのサービスです。 Jenkins等のCIサーバを使い、JUnitやPHPUnitなどユニットテストや、Seleniumを使ったブラウザテストを行うというテスト（開発）手法は、一度慣れてしまうと元に戻れない安心感を与えてくれるものです。 しかし、テストの中でもまだ広く一般的にはCIに組み込まれていないのが、セキュリティテスト（脆弱性検査）とパフォーマンステストだと思います。 「CIで脆弱性検査（セキュリティテスト）を実施しよう」というアイデアは自然なものであり、特に英語圏では、ブログやカンファレンスの発表資料などでよく目にします。 それらのうち多くはOWASP ZAPとJekninsを組み合わせるというものですが、元々ZAPはGUIのツールとして開発されたこともあり、CIに組み込むの