NoSQLデータベースの人気はますます高まっています。特に、開発チームがアジャイルな方法論に基づいて作業している場合には、非構造化データを扱う際のスピードと容易さを否定することはできません。

開発者が新技術の脆弱性やその他の課題を解決するには時間がかかります。本番環境での使用期間が長くなって初めて、問題が表面化します。

NoSQLデータベースも同様です。アプリケーションを安全に保つために、開発者が知っておくべき重要なリスクがあります。その一つがNoSQLインジェクションです。

ここでは、NoSQLインジェクションとは何か、どのような被害をもたらすのか、そしてどのように修正するのかを見ていきましょう。

NoSQLインジェクションの理解

NoSQLインジェクションは、XMLインジェクションやSQLインジェクションなどのインジェクション脆弱性と同じものが多く存在します。

NoSQL インジェクションにより、攻撃者は NoSQL クエリに任意のコマンドを入れることができます。これにより、データを盗んだり、権限が十分に高ければデータベースに変更を加えたりすることができます。

アプリケーションがユーザが制御するデータを直接NoSQLクエリ式に配置する場合、これらの式は多くの場合、データを盗んだり変更したりするために操作可能な関数を取ったり、組み込みの演算子を持っています。そして、そのようなことが悪意を持って実行された場合、悲惨な結果になる可能性があります。

MongoDBデータベースは、この脆弱性を悪用する最も一般的な遊び場の一つです。"$ne:""'は、SQLの世界では1=1に相当する演算子なので、例を挙げると、攻撃者は"$ne:""'をUIのユーザー名とパスワードのフィールドに入れることができます。もしそのコードがNoSQLインジェクションに脆弱であれば、データベースはユーザー名とパスワードが空の文字列に等しくないすべてのレコードを検索します。言い換えれば、全部です。やべぇ。

このデータベースが暗号化されていなければ、攻撃者はデータベース内のすべてのユーザーのユーザー名とパスワードを盗むことができます。これには管理者のユーザー名とパスワードも含まれ、データベース全体にアクセスできるようになります。

攻撃者はしばしば、常に真である値をパスインしようとします。また、関数に設定されているプロパティに悪意のあるコードを注入する攻撃もよく行われます。

たとえば、MongoDB の find 関数は $where というプロパティを持つオブジェクトを受け取ります。where プロパティには、true または false に評価されるべき関数が設定されています。ユーザーの入力によってこの関数が何らかの形で変更された場合、NoSQLインジェクションが潜んでいる可能性があります。

NoSQLインジェクションの複雑な仕組みについては、InfoQの記事をご覧ください。

NoSQLインジェクションが危険な理由を知る

NoSQLへのインジェクションが危険なのは、それに見合うだけの精査がセキュリティコミュニティからまだ受けられていないからです。

NoSQLインジェクションの影響は、従来のSQLインジェクションとほぼ同じです。データが盗まれたり変更されたり、データを盗むことでアカウントが侵害されたり、おそらく最も悪質なのは、削除コマンドが正常に発行された場合、データが完全に消去されてしまうことです。

要するに、MongoDBやその他のNoSQLデータベースエンジンは攻撃されやすいということです。"
ありがたいことに、コミュニティの中には注意を促している人もいます。しかし、より多くの開発者が自分たちのアプリケーションを、悪用されると大きな頭痛の種になるような、あまり知られていない厄介なものから守れるよう、自らを教育する必要があります。

NoSQLインジェクションを倒す

NoSQLインジェクションを撃退するのは困難です。残念ながら、SQLインジェクションのようにパラメータ化されたクエリという選択肢はありません。しかし、不可能ではありません。いくつかのオプションがありますので、参考にしてみてください。

• ファザーは、脆弱性を検出するための1つの手法として利用できます。しかし、人生の多くのことがそうであるように、最もシンプルなアプローチが最も効果的であることがあります。ここでは、古き良きコードレビューが最も強い味方となります。
• コードをレビューする際には、ユーザーの入力によって式の値が設定されたり、関数が変更されたりする可能性のある場所を探します。ユーザーの入力によってクエリが変更されないようにしましょう。
• ユーザーの入力は必ず正しいクラスにキャストしてください。数字であれば数字に、文字列であれば文字列に、というように。
• WHEREや類似のeval関数をユーザー入力と一緒に使用しないでください。ほとんどの場合、データモデルやスキーマを変更することで回避することができます。
• MongoDBのドライバにMongooseを使ってみましょう。Mongoose では、NoSQL データベースのスキーマを定義することができます。Mongooseに入力が文字列であることを伝えれば、文字列にキャストされます。つまり、攻撃者から渡されたオブジェクトは、オブジェクトとしてではなく、文字列として扱われることになります。
• DBを強化しよう権限の低いユーザーアカウントを作成し、クエリの実行時間を最大化し、常に組織に適用されるセキュリティのベスト・プラクティスに従ってください。

NoSQLデータベースの使いやすさの欠点は、開発者がセキュリティを考えずに立ち上げて使い始める傾向があることです。

NoSQLデータベースを安全に立ち上げ、NoSQLインジェクションから身を守る方法を時間をかけて学ぶことが不可欠です。

例えば、MongoDB Enterprise Editionには、ドキュメントに対する高度なアクセスコントロール機能があります。最小限の特権」を行使することは、万が一、アプリケーションに脆弱性が見つかった場合に備えたDiD（Defense in Depth）戦略として有効です。

まとめますと、以下のようになります。

• NoSQLのクエリ式で使用する前に入力をサニタイズする
• マングースのように、あなたを助けてくれるドライバーを使う
• クエリの中で入力データがどのように使用されているかを具体的に調べるコードレビューの実施
• ファザーやスキャナーを使って、コードの脆弱性を見つけることができます。

NoSQLはNo Injectionsではない

NoSQL データベースは、そのスケーラブルな機能とセットアップの速さから、急速に人気を集めています。しかし、その新しさゆえに、開発者はセキュリティ対策を考えずにNoSQLデータベースを使ってしまうことがあります。

NoSQLデータベースは、SQLデータベースと同様にインジェクション攻撃に対して脆弱な場合がありますので、慎重に行動し、クエリに注意を払ってください。さらに詳しく知りたい方は、ラーニングリソースをご覧いただくか、無料デモでスキルをお試しください。

事前に準備しておけば、アプリケーションでのNoSQLインジェクションを心配する必要はありません。簡単すぎる！？

今すぐNoSQLインジェクションを見つけ、特定し、修正する準備ができていると思いますか？セキュアコードの世界に飛び込んでみませんか？

これで2018年は終わりです。これが今年最後の記事となりますが、次回のCoders Conquer Securityガイドは2019年1月10日にお届けします。それでは、またお会いしましょう

Webサイトやアプリケーションの運営者を狙った攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接、金品や認証情報を盗むことにあります。これは、サイト運営者がCSRFコードの脆弱性を無視すべきだということを意味するものではありません。純粋に金銭的な攻撃の場合、最終的に盗まれた資金の補充は、安全でないコードを持つホスティングサイトの責任となる可能性があるからです。また、標的となったユーザーが認証情報を紛失したり、知らないうちにパスワードを変更されたりした場合、特に被害者が特権的なアクセス権を持っている場合には、犯罪者は盗んだIDを使って大暴れすることができるかもしれません。

CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くの要素が攻撃者に有利に働く必要があります。しかし、CSRF攻撃は、成功すればハッカーに直接お金を渡したり、サイト内を自由に動き回れるようにしたりできるため、非常に人気の高い攻撃手段です。すべてがハッカーの思惑通りに進めば、標的となったユーザーは攻撃の被害に遭ったことにさえ気づかないかもしれません。

しかし、CSRF攻撃を成功させるためには多くの要素が必要であるため、攻撃を阻止するための優れた防御技術がいくつかあります。

そのために、CSRF攻撃の3つのポイントについて説明します。

• 仕組み
• なぜ彼らは危険なのか
• 彼らを冷遇するための防御策を講じることができます。

CSRF攻撃の仕組みは？

CSRF攻撃が成功すると、標的となるユーザーから金品や認証情報を直接盗むことができるため、その作成には多大な労力を要するにもかかわらず、人気があります。また、さまざまなプラットフォームで試行されることが多いため、長年にわたってさまざまな名前や称号が付けられてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、Hostile Linkingなどと呼ばれることもあります。マイクロソフトは、ほとんどのドキュメントでこれらをワンクリック攻撃と呼んでいます。しかし、これらはすべてCSRF攻撃であり、その対策方法も同じです。

CSRF攻撃は、ユーザーがサイトにログインしてビジネスや仕事をしているときに起こります。重要なのは、ユーザーがウェブサイトやアプリケーションにログインし、積極的に認証されていることです。この攻撃は通常、二次的なウェブサイトや電子メールから行われます。多くの場合、攻撃者はソーシャルエンジニアリング技術を使用してユーザーを騙し、攻撃スクリプトが置かれた危険なWebサイトに誘導する電子メール内のリンクをクリックさせます。

侵害されたウェブサイトには、アクティブなブラウザにコマンドを実行するよう指示するスクリプトが含まれています。通常は、ユーザーのパスワードを変更したり、攻撃者が管理する口座に送金したりするような悪質なものです。ユーザーが認証されている限り、サイトはそのコマンドが認証されたユーザーによって発行されたものであると考えます。なぜそうしないのでしょうか？ユーザーはすでに自分自身を認証し、サイトにアクセスするために必要なパスワードを提供しています。また、ジオフェンス内にいて、オフィスの端末に座っているかもしれません。パスワードの変更や送金をしたいと思ったとき、それを要求したのが本人であると信じない理由はないだろう。

この攻撃の要素を分解してみると、なぜこの攻撃が攻撃者にとって非常に難しいものであるかがわかります。まず、攻撃が行われるサイトでは、ユーザーが積極的に認証を受ける必要があります。ユーザーがブラウザのセッションを終了したり、ログオフしたりした後に、攻撃スクリプトを含むメールが届いた場合、攻撃は失敗します。

また、攻撃者は、そのサイトがどのようなスクリプトを受け入れるかを知るために、標的となるサイトで多くのリコンを行う必要があります。攻撃者は被害者の画面を見ることができず、ウェブサイトからのフィードバックは攻撃者ではなく被害者に送られます。攻撃者は、被害者の口座に突然お金が入ってくるなど、攻撃が成功した証拠を見ることができなければ、攻撃が成功したかどうかもすぐにはわかりません。

CSRF攻撃を実行するためのコードは、攻撃時にユーザーがログインしていること、標的となるサイトがどのようなスクリプトを受け入れるかを知っていることという、難しいようでいて不可能ではない条件の中で、サイト自体によって異なりますが、非常にシンプルなものになります。

例えば、銀行や金融機関のアプリケーションが、以下のようにGETリクエストを使って送金するとします。

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。

しかし、ターゲットとなったユーザーが、同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトが埋め込まれる可能性があります。

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

ターゲットとなったユーザーがソーシャルエンジニアリングリンクに引っかかり、ファイナンスアプリケーションのブラウザセッションがまだ開いている間にリンクをクリックすると、ブラウザはアプリケーションにShadyLady15の口座に10万ドルを送金するように要求します。

このスクリプトは、ユーザーには見えないが、ブラウザがリクエストを行うきっかけとなるような不可視の画像の中に隠すこともできます。

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

結果は同じです。ShadyLady15は、誰にも攻撃を検知されずに10万ドルを手に入れます。

なぜCSRFは危険なのか？

CSRF攻撃は、ランサムウェアが流行し続けているのと同じ理由で、現在人気があります。CSRF攻撃は、攻撃者と被害者の資金の間のホップが非常に少ないのです。ランサムウェア攻撃では、システムが暗号化され、ユーザーはそのデータを解読するために金銭を要求されます。CSRF攻撃では、さらに少ないステップで攻撃を行うことができます。CSRF攻撃が成功すると、被害者は知らないうちに攻撃者にお金を送ってしまいます。

CSRF攻撃が成功すると、被害者の金銭や企業の財務に対する直接的な攻撃だけでなく、有効なユーザーを使ってネットワークを侵害することができます。もし攻撃者がCSRF攻撃を利用して管理者のパスワードを変更したとしたらどうでしょう。攻撃者はすぐにそのパスワードを使用して、データの盗み出し、ネットワーク防御の穴を開け、バックドアをインストールすることができます。

CSRF攻撃を成功させるには、多大な労力とある程度の運が必要ですが、ハッカーにとっては、最終的な目的にかかわらず、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの種類の攻撃では、SIEMやサイバーセキュリティ担当者のレーダーに映らないようにしながら、何ヶ月もかけてじっくりと偵察する必要があります。これに対して、CSRF攻撃は、サイバーキルチェーンのいくつかのステップをスキップして、最終的な目標に非常に近いところからスタートさせることができます。

CSRF攻撃を防ぐにはどうすればいいですか？

一般的な脆弱性とは異なり、CSRF攻撃では、コードではなく、攻撃者が作成したエクスプロイトを利用して、ユーザーが望まない、あるいは知らないリクエストをブラウザにさせることができます。しかし、これらの攻撃は防ぐことができます。

最良の方法の1つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。このトークンは、ユニークでランダムな文字列で構成され、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバがチェックするフォームに、CSRFトークンのリクエストを隠しフィールドとして追加します。ユーザーのブラウザを介してリクエストを送信する攻撃者は、隠されたトークン・フィールドについて知ることもできず、ましてやそれが何であるかを知ることもできないので、リクエストはすべて失敗します。

さらに簡単な方法として、プログラミングをあまり必要としない方法として、パスワード変更依頼や送金依頼のような機密性の高いものにCaptchaチャレンジを追加する方法があります。これは、ユーザーに、リクエストした人がロボットではないことを確認するボタンを1回クリックしてもらうという単純なもので、この場合はCSRFスクリプトを使っています。攻撃者はチャレンジに対する応答をスクリプトで作成することはできません。また、送金依頼などの操作をしていないのに突然CAPTCHAチャレンジが表示されたユーザーは、何かが起きていることに気づくでしょう。また、スマートフォンなどのサードパーティ製のトークンを使ってワンタイムパスワードを生成する方法もありますが、組織がセキュリティの名の下にどれだけ作業を遅らせたいかによって異なります。

最後に、鉄壁ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、ローカルユーザ以外からのリクエストをブロックする同一オリジンポリシーの制限が設けられています。ユーザーにこれらのブラウザの最新バージョンを使ってサイトにアクセスしてもらうことで、開発チームに負担をかけることなく、CSRFのセキュリティをさらに強化することができます。

CSRFの扉を閉める

しかし、なぜこのような攻撃が行われるのか、また、どのようにしてネットワークから遮断すればよいのかをご理解いただけたのではないでしょうか。

さらに詳しい情報は、OWASP Cross-Site Request Forgery Prevention Cheat Sheetをご覧ください。また、セキュリティに関する知識を深めたい方は、以下のブログをご覧になり、この脅威に対抗する方法を学んでください。 Secure Code Warriorブログをご覧ください。

新しいディフェンスの知識を試す準備ができたと思いますか？Secure Code Warrior プラットフォームの無料デモで遊んでみてください。

クロスサイト・スクリプティング（XSS）は、2000年代初頭からセキュリティ専門家の悩みの種であったが、悲しいことに、数十年経った今でも、最も一般的なコードレベルの脅威の1つとして登録されている。この種のソフトウェアの脆弱性は、あまりにも長い間私たちを悩ませてきたが、CISAからの最近の警告は、彼らのSecure-by-Design運動の一環として、これをきっぱりと阻止しようとしている。開発者主導のセキュリティにスポットライトを当てることで、その針を動かし、変化をもたらすことができるのだが、それには開発者をセキュリティの成功に導く賢明な企業のコミットメントが必要だ。



ウェブブラウザは、オンライン上のあらゆる素晴らしいものへの入り口かもしれませんが、悲しいことに、良いニュースばかりではありません。ウェブブラウザ固有の動作が、セキュリティ脆弱性のきっかけになる可能性があるのです。ブラウザは当初、目にしたマークアップを信頼し、何の疑問も持たずに実行するという特徴を持っていました。そして当然のことながら、攻撃者は最終的にこの傾向を悪用し、邪悪な目的を達成する方法を見つけるのです。

クロスサイト・スクリプティングは、ブラウザの信頼とユーザーの無知を利用して、データを盗んだり、アカウントを乗っ取ったり、ウェブサイトを改ざんしたりします。これは、非常に醜く、非常に速くなり得る脆弱性です。

XSSがどのように機能するのか、どのような被害をもたらすのか、そしてどのように防ぐのかを見てみましょう：

XSSの仕組みは？

XSSは、信頼されていない入力（多くの場合、データ）がページの出力として表示されているにもかかわらず、実行可能なコードと誤認されることで発生します。攻撃者は、入力パラメータの中に悪意のある実行コード（HTMLタグやJavaScriptなど）を置くことができ、ブラウザに返されたときに、データとして表示されるのではなく実行されてしまいます。

前述のとおり、この脆弱性は、データと実行コードを区別することが難しいブラウザの中核的な機能の動作に起因しています。Webの動作モデルは次のようになっています。

1. ユーザーがWebページにアクセスする
2. ページでは、どのファイルを読み込み、何を実行するかをブラウザに伝えます
3. ブラウザは、ページに書かれていることを問答無用で実行する

この機能のおかげで、私たちがウェブで楽しんでいる最も素晴らしいインタラクティブな体験のいくつかが生まれました。

攻撃者が悪意のあるスクリプトを脆弱なサイトに追加すると、何の疑いもなく実行されてしまいます。より深い調査も、検知手段も用意されていません。

XSSには3つのタイプがあります。

• ストアドXSS
• 反射型XSS
• DOM XSS

Stored XSSは、攻撃者がアプリケーションのデータフィールド（ユーザの携帯電話番号を格納するフィールドなど）に悪意のあるスクリプトを持続的に格納できる場合に発生します。

このタイプの攻撃は、フォーラムサイトやコメントエンジンでよく見られます。攻撃者がコメントに悪意のあるスクリプトを入力すると、そのコメントを見たすべてのユーザが知らず知らずのうちにそのスクリプトを実行してしまいます。

反射型XSSは、ユーザの入力がそのままユーザのブラウザに反映されることで発生します。

ここで、検索結果を取得する際に、ユーザに「You searched for ...」と表示する検索ボックスがあったとしましょう。悪意のある攻撃者は、同じパラメータに悪意のあるスクリプトを埋め込んだリンクを被害者に送ることができますが、正直なところ、ほとんどのウェブユーザはそれに気づきません。

被害者がリンクをクリックすると、フィッシングサイトにリダイレクトされ、知らず知らずのうちにそのサイトのパスワードを入力してしまいます。

DOM XSSは、この脆弱性の中でも比較的新しいものです。

これらのテンプレートは、動的なコンテンツやリッチなUIアプリケーションを可能にします。誤った使い方をすると、XSS攻撃の実行に利用されてしまいます。

以上、XSSの範囲について説明しました。XSSの範囲を簡単にご理解いただけたと思います。それでは、XSSがどのように破壊的に使用されるのか、さらに深く掘り下げてみましょう。

なぜXSSは危険なのか？

XSSは、ユーザーを悪意のあるサイトにリダイレクトしたり、クッキーを盗んだり、セッションデータを探したりするのに使われます。基本的に、JavaScriptでできることはすべて、XSS攻撃でも可能です。

XSS攻撃の例を3つ紹介します。

1. ヤフーのメールユーザーは、2015年にXSSを使ってセッションクッキーを盗まれました。
2. Samy ワームは、MySpace の XSS 脆弱性を利用して配布されました。わずか20時間で100万人のユーザーに影響を与えたこのワームは、今でも史上最速の拡散力を誇るマルウェアです。
3. eBayでは、商品説明文に悪意のあるスクリプトが含まれることがありました。これにより、eBayのユーザーに対してXSS攻撃が行われていました。

XSS攻撃は、単純なようでいて非常に深刻です。XSS攻撃は、セッション、ユーザー認証情報、または機密データの盗難につながる可能性があります。評判の低下や収益の減少は、これらの攻撃の大きな落とし穴です。

しかし、XSSは、あなたのような経験豊富なセキュリティ戦士が打ち負かすことができます。修正方法は複雑ではありませんし、XSSが一般的に使用されるようになってから、業界は長い長い道のりを歩んできました。

XSSを倒すことができます。

XSSを撃退するには、コンテキストを理解することが重要です。具体的には、ユーザーの入力がどのような状況でクライアントに戻されるのか、どこで戻されるのかということです。HTMLコードの中か、JavaScriptのスニペットの中か。

ユーザー入力がブラウザに送り返される必要がなければ、それに越したことはありません。しかし、必要な場合は、多くの場合、HTMLエンコードされるべきです。出力をHTMLエンコードすることで、ブラウザはコンテンツをそのままレンダリングし、実行しないように指示します。

入力の検証も重要です。しかし、検証やホワイトリストは 確実な解決策ではありません 。エンコーディングはさらに数歩進んで、ブラウザが悪意のあるスクリプトを実行するのを阻止します。

多くのフレームワークが、HTML出力を自動的にエンコードするようになっています。
Angular、ASP.NET MVC、React.jsは、デフォルトのHTMLエンコードが使用されるフレームワークです。

その他のほとんどのフレームワーク（DjangoやSpring など）には、XSS 対策のための標準ライブラリが用意されており、簡単にコードに組み込むことができます。

最大の課題は、ユーザーの入力がシステムに入る方法をすべて分析し、それを見極めることができるようになることです。クエリ・パラメータは、ポスト・パラメータと同様に、攻撃の対象となる可能性があります。アプリケーション全体のデータの流れを追い、外部からのデータを信用しないようにしてください。

国境警備隊のように考えてください。すべてのデータを止めて検査し、悪意があると思われるものは入れないようにします。

これらの戦略を実行すれば、XSS による攻撃からユーザーを守ることができます。OWASP Cheat Sheetには、データを管理するためのさらなるヒントが掲載されていますので、ぜひご覧ください。

XSSを阻止し、セキュリティスキルをレベルアップさせる。

XSSは、OWASP Top 10 2017のWebセキュリティリスクのリストの7位に存在しています。

トレーニングは、開発者がコードを作成する際に、セキュリティを第一に考えた考え方を構築する上で非常に重要です。そして、そのトレーニングは、開発者が実際に使用している言語で、実際のアプリケーションをシミュレートすることで、常に最も効果的なものとなります。この点を踏まえて、XSSについての詳細を学ぶために、ラーニングリソースをチェックしてみてはいかがでしょうか。その後、トレーニングと実践を重ねて、マスターを目指しましょう。

XSSの脆弱性を見つけて修正する準備が今すぐできたと思いますか？ 挑戦してみませんか？ Secure Code Warrior プラットフォームで。

簡単に言うと、SQL（Structured Query Language）とは、リレーショナルデータベースと通信するための言語で、開発者やデータベース管理者、アプリケーションが日々生成される膨大なデータを管理するために使用する問い合わせ言語のことです。

私たちのデータは、世界で最も価値のある商品の一つになりつつあります。価値のあるものは、悪人が自分の利益のためにそれを手に入れようとします。

攻撃者は、世界中の何百万ものデータベースに存在する機密情報を盗んだり変更したりするために、最も古く（1998年以降）、最も厄介なデータ脆弱性の1つであるSQLインジェクションを使用しています。データを安全に保つためには、開発者はSQLインジェクションについて理解する必要があります（また、その防御方法についても）。

そのために、SQLインジェクションの3つのポイントについて説明します。

• その仕組み
• なぜ危険なのか
• どうやって防御するか

SQLインジェクションの理解

SQLインジェクションは、「コンテキスト」という言葉で理解することができます。

アプリケーションの中には、データ用とコード用の2つのコンテキストが存在します。コードのコンテキストは、何を実行するかをコンピュータに伝え、処理されるべきデータから分離します。

SQLインジェクションは、攻撃者が入力したデータが、SQLインタープリターによって誤ってコードとして処理されることで発生します。

一例として、ウェブサイトの入力フィールドに攻撃者が「'' OR 1=1」と入力すると、それがSQLクエリの最後に付加されます。このクエリが実行されると、データベースのすべての行に対して「true」が返されます。これは、クエリを実行したテーブルのすべてのレコードが返されることを意味します。

SQLインジェクションの影響は、壊滅的なものになる可能性があります。ログインページで発生した場合、ユーザー名やパスワードを含むすべてのユーザー記録が返される可能性があります。データを取り出すための単純なクエリが成功すれば、データを変更するためのクエリも成功するでしょう。

SQLインジェクションの脆弱性がどのようなものかを実際に確認するために、脆弱なコードを見てみましょう。

このコードをチェックしてください。

String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
   Statement statement = connection.createStatement( ... );
   ResultSet results = statement.executeQuery( query );
}

ここでのコードは、検証を行わずに、クライアントからのパラメータ情報をSQLクエリの最後に追加するだけのものです。このような場合、攻撃者は入力フィールドやURLのパラメータにコードを入力すると、それが実行されてしまいます。

重要なのは、攻撃者が各SELECTクエリに「''OR 1=1」を追加することしかできないということではなく、攻撃者はあらゆるタイプのSQLクエリ（INSERT、UPDATE、DELETE、DROPなど）を操作し、データベースがサポートするあらゆるもので拡張することができるということです。どのようなことが可能なのかを示す素晴らしいリソースやツールが公開されています。

この問題を解決するための方法をすぐに学びます。まず、どのくらいのダメージがあるのかを理解しましょう。

SQLインジェクションが危険な理由

ここでは、SQLインジェクションが原因で発生した侵害の例を3つだけ紹介します。

• イリノイ州選挙管理委員会のウェブサイトが、SQLインジェクションの脆弱性により侵害されました。攻撃者は、20万人の米国市民の個人データを盗みました。見つかった脆弱性の性質上、攻撃者はデータを変更することも可能でしたが、そうはしませんでした。
• 南アフリカのウェブサイトホスティング会社であるHetzner社は、4万件の顧客記録が侵害されました。SQLインジェクションの脆弱性により、同社のデータベースに登録されているすべての顧客記録が盗まれた可能性があります。
• 米国ミネソタ州にあるカトリック系の金融サービス会社が、SQLインジェクションを利用した不正アクセスを受けました。約13万人の顧客の口座番号を含む口座情報が盗まれました。

機密データは、アカウントの乗っ取り、パスワードのリセット、金銭の窃盗、詐欺などに利用される可能性があります。

機密情報や個人を特定できない情報であっても、別の攻撃に利用される可能性があります。住所情報や政府機関の識別番号の下4桁は、お客様になりすまして企業に連絡したり、パスワードをリセットしたりするのに使われます。

攻撃が成功すると、顧客は企業に対する信頼を失うことになります。システムへのダメージや規制による罰金からの回復には、数百万ドルの費用がかかります。

しかし、あなたがそのように終わる必要はありません。

SQLインジェクションの撲滅

SQLインジェクションを防ぐには、アプリケーションの一部を明確にラベル付けすることで、ある部分がデータなのか実行されるコードなのかをコンピュータに認識させる必要があります。これには、パラメータ化されたクエリを使用します。

SQLクエリがパラメータを使用する場合、SQLインタープリタはパラメータをデータとしてのみ使用します。コードとしては実行されません。

例えば、「''OR 1=1」のような攻撃は機能しません。データベースは「OR 1=1」という文字列を検索しますが、データベース内には見つかりません。単に肩をすくめて、"Sorry, I can't find that for you. "と言うだけです。

Javaでのパラメータ化されたクエリの例は次のようになります。

ほとんどの開発フレームワークには、SQLインジェクションに対する防御機能が組み込まれています。

.NETファミリーのEntity Frameworkのようなオブジェクトリレーショナルマッパー（ORM）は、デフォルトでクエリをパラメータ化します。これにより、SQLインジェクションの対策が何もしなくてもできるようになります。

しかし、特定のORMがどのように機能するかを知っておく必要があります。例えば、Javaの世界では人気の高いORMであるHibernate も、使い方を誤るとSQLインジェクションの危険性があります。

クエリのパラメータ化は最初で最良の防御策ですが、他にもあります。ストアドプロシージャもSQLパラメータをサポートしており、SQLインジェクションを防ぐために使用することができます。ただし、ストアドプロシージャも正しく構築されていなければなりませんのでご注意ください。

// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );

常に入力を検証し、サニタイズしてください。OR 1=1 "のような文字は、アプリケーションの正当なユーザーが入力することはないので、許可する必要はありません。ユーザーにエラーメッセージを表示したり、入力を処理する前にそれらの文字を取り除くことができます。

とはいえ、バリデーションやサニタイズだけに頼っていてはいけません。賢い人間はそれを回避する方法を見つけています。それらは深層部への防御(DiD)として有効ですが、パラメータ化は、すべてのベースをカバーする確実な方法です。

もうひとつの優れたDiD戦略は、データベース内で「最小特権」を使用し、入力をホワイトリスト化することです。最小限の特権を行使するということは、アプリケーションがデータベース内で無限の権限を持たないことを意味します。仮に攻撃者がアクセスしたとしても、その被害は限定的です。

OWASPでは、いくつかの言語やプラットフォームでこの脆弱性をどのように処理するかを示した素晴らしいSQLインジェクション・チートシートを用意していますが、さらに上を目指したい方は、今すぐ私たちのプラットフォームで、お好きな言語でSQLインジェクション・チャレンジをプレイすることができます。

C#でのSQLインジェクション

Node.jsにおけるSQLインジェクション

Python DjangoでのSQLインジェクション

Java SpringにおけるSQLインジェクション

旅の始まり

SQLインジェクションを理解し、それを修正するために必要なステップを理解する上で、あなたは大きな進歩を遂げました。すばらしいですね。

これまで、SQLインジェクションがどのように起こるかを説明してきました。通常、攻撃者は入力を使用してデータベースのクエリを制御し、悪意のある目的を達成します。

また、SQLインジェクションの脆弱性が悪用されることによる被害も目にしてきました。アカウントが侵害され、何百万ドルものお金が失われる......悪夢のような、そして高価なものです。

SQLインジェクションを防ぐ方法を見てきました。

• クエリのパラメータ化
• オブジェクトリレーショナルマッパーとストアドプロシージャの使用
• ユーザー入力の検証とホワイトリスト化

あとは、あなた次第です。練習は、学習と習得を続けるための最良の方法です。だからこそ、私たちの ラーニングリソースSQLインジェクションの学習資料をご覧になり、無料体験版をお試しください。 無料デモプラットフォームの無料デモを試してみませんか？そうすれば、Secure Code Warrior に近づくことができるでしょう。

2020年にはリモートワークが急増し、さらに大規模なデータ流出が続き、オンライン上でのプライバシー侵害の影響に注目が集まっていることから、サイバーセキュリティに対する社会の注目度はかつてないほど高まっています。その結果、世界各国の政府は、私たちの最も貴重なデジタルリソースを取り扱う際に企業が遵守すべき戦略や規制を含む、サイバーセキュリティの計画やインフラの再構築と更新に乗り出しています。

サイバーセキュリティの戦略的保護ガイドラインは新しい概念ではなく、NISTのような組織が長年にわたって世界の政府部門の方針を伝えてきました。しかし、デジタル化が急速に進むにつれ、多くの人々にとって、変化し続ける状況の中で、数多くの脅威、考えられる攻撃経路、コンプライアンス要件に対応することは困難になっています。

最近発生したニューサウスウェールズ州の運転免許証54,000件の漏えい事件は、サードパーティのサーバに設置されたS3バケットに簡単にアクセスして設定を間違えたことが原因で、数千人の個人情報が漏えいしたもので、この事件を報告したセキュリティ研究者は、データがすでにダークウェブで販売されている可能性があることを認めています。悲しいことに、この問題は簡単に解決できるものであり、キャッシュの設定者がセキュリティを最優先に考えていたならば、このような事態は全く起こらなかったでしょう。

オーストラリア政府は先日、「オーストラリア・サイバーセキュリティ戦略2020」を発表しました。これは、「オーストラリア人とそのビジネス、そして私たち全員が依存している重要なサービスのために、より安全なオンライン世界を構築する」というビジョンを達成するために、新たな取り組みと今後10年間で使用される16億7,000万ドルの資金増強を強調したものです。特に、主な目的の一つが以下の通りであることから、これは非常に歓迎すべき見直しであり、更新された計画です。

"企業が自社の製品やサービスの安全性を確保し、既知のサイバー脆弱性から顧客を守るための行動"

政府機関は、国の重要なインフラ（壊滅的な組織的攻撃を受けやすい分野）に関するセキュリティ対策を重視する傾向にありますが（当然のことですが）、これまでは、私たちのデータを日々収集・利用している企業に対するガイドラインが不足していました。

さて、このような公式の戦略となると、ビールとスキットルばかりではありません。解釈がやや難しく、詳細が曖昧なため、組織のセキュリティチームが具体的でないガイドラインに基づいて計画を組み立てることになってしまうのです。この問題は、オーストラリア政府に限ったことではありませんが、オーストラリア政府の新しいリリースを分析してみましょう。

予防ではなく、反応に焦点を当てています。

更新されたオーストラリアのサイバーセキュリティ戦略は、2016年に発表された前回のものよりも関連性がアップしており、企業、特に中小企業向けにかなり包括的な計画が盛り込まれています。戦略の概要は以下の通りです。

"政府と大企業は、中小企業がサイバーセキュリティに対する意識と能力を高め、成長できるように支援する。オーストラリア政府は、大企業やサービスプロバイダーと協力して、中小企業にサイバーセキュリティの情報やツールを、安全なサービス（脅威の遮断、ウイルス対策、サイバーセキュリティ意識向上トレーニングなど）の「バンドル」の一部として提供する」としている。

これにより、中小企業はサイバー脅威から自社のビジネスを守るための基本的な基盤を整えることができます。しかし、これは主に後付けのアプローチであり、サイバーセキュリティの中でも比較的小さな部分である検知ツールに焦点が当てられています。

また、大企業がどのように自らを守り、攻撃のベクトルを減らすことができるのかについての情報は驚くほど少ない。重要インフラ（通信、輸送など）を保護する計画の一部であることは確かだが、金融サービス、小売、その他多くの業種は、サイバー攻撃が成功した場合、失うものが大きい。しかし、企業レベルでのサイバーセキュリティのベストプラクティスの重要性を強調することは、大きな変化をもたらし、漏洩したデータやサイバー犯罪を減少させるための基本です。

今回の戦略は、全体的に見て、リアクティブなアプローチを中心に構築されています。サイバー攻撃に対抗し、活動中のサイバー犯罪者を混乱させて確実に処罰し、国際的な同盟国と情報を共有することは、いずれも重要な要素ですが、もし国全体の保護の基準が予防に集中していたらと想像してみてください。重要インフラの保護対策とともに、すべての企業でセキュリティが最優先され、デジタル世界を創造するコードに触れるすべての人が、攻撃を未然に防ぐための適切な装備を備えていたとしたら、時間、お金、そして被害者の心労を減らすことは計り知れません。

レジリアンスは可能ですが、計画的に行わなければなりません。

オーストラリア政府がサイバーセキュリティに本腰を入れて取り組んでいることからもわかるように、サイバーセキュリティは国家レベルで重要なリスク領域として認識されています。私たちの生活を破壊する可能性のある他の悪意のある攻撃と同様に、そのような試みに耐えるだけでなく、そのようなことが全く起こらないように抑止するためにも、レジリエンスは絶対に重要です。結局のところ、脅威となる人物は怠け者であり、成功を阻む障害が多ければ、目的を達成するためにもっと簡単なターゲットに移ってしまうのです。

現在、私たちは世界的なサイバーセキュリティのスキル不足に直面しており、これは世界中のCISOを夜も眠れない状態にしています。何十億行ものコード、絶え間ない大規模なデータ侵害、そしてかつてないほどのペナルティのリスク（マリオットだけでも、2018年のデータ侵害でGDPRによる1億2,300万米ドルの罰金を受けており、さらに今年も侵害が発生しています）により、セキュリティの専門家に対する需要の溝は、現実的には埋められそうにありません。コードがあまりにも多く、それをあらゆる角度から防御するためのリソースがあまりにも不足しているのです。

では、私たちは、サイバー脅威に直面したときに、真の意味で立ち向かえるようになることを諦めるべきなのでしょうか？そんなことはありません。レジリエンスを高めるためには、利用可能なすべてのリソースを活用し、一歩先を見据えて行動する必要があります。多くの企業では、開発者がコードを書いている最中に、強力な防御方法を解き放つことができます。企業全体で目に見える積極的なセキュリティ文化と組み合わせれば、多くの攻撃者が揺さぶりをかけて壊すことのできない安全な基盤ができあがります。しかし、この方法は、オーストラリアのサイバーセキュリティ戦略の提案を例にとり、ビジネスに適した効果的な変化をサポートするために、どのようにカスタマイズできるかを深く掘り下げる必要があります。

そのためには、いくつかのヒントを分解することが重要です。

• セキュリティ意識向上のためのトレーニング。これは特に中小企業を対象としたもので、報告書全体の文脈からすると、主にすべてのスタッフに基本的なセキュリティ衛生を教えることを目的としています（例：フィッシングメールの見分け方、知らないリンクをクリックしないなど）。現実的には、それよりもはるかに進んで、特に開発者のようにコードを触る人たちのために、役割に応じたトレーニングを行う必要があります。セキュリティ意識の向上のためのトレーニングは、予防措置と回復力の構築のための要素であることが不可欠です。
• 教育です。新たな試みとして、初等・中等教育から高等教育に至るまで、サイバーセキュリティのトレーニングを重視することで、今後10年間のサイバーセキュリティのスキル不足に対処するための綿密な計画が立てられています。将来のセキュリティ・スーパースターを育成するためには、このようなトレーニングが必要です。しかし、現在のビジネス・ニーズに対応するという観点からは、一般的な脆弱性を減らしていくためには、開発者向けのセキュア・コーディングの実践的なトレーニングが絶対に必要であり、機能的なセキュリティ・プログラムの一部でなければなりません。

私たちはセキュリティの専門家として、世界中の企業が、単純な基礎的認識にとどまらず、社内のセキュリティプログラムを構築することの重要性を理解するために、もっと努力する必要があります。開発者のスキルアップに時間をかけることで、過重労働を強いられているAppSecの専門家のプレッシャーを軽減し、組織全体がそれぞれの役割に応じて可能な限りセキュリティを意識するようにすることが、ソフトウェアにおける脅威表面の攻撃領域を減らすために不可欠です。

開発者のスキルアップは時間を有効に使うことができますが、なぜ多くの企業がそれを無視しているのでしょうか？

DDLSが最近実施した調査によると、オーストラリアの組織では、サイバーセキュリティのトレーニングに関して、優先順位がほとんど意識されていないことがわかりました。実際、回答者の77%がサイバーセキュリティに対する意識を「非常に重要」または「非常に重要」としているにもかかわらず、トレーニングの優先順位のトップ3にも入っていませんでした。

そのため、オーストラリアが拡大するスキル格差の解消に苦戦しているのも不思議ではありません。また、基本的なサービスから小売店、そしてその間にあるすべてのものに至るまで、より回復力のあるインフラを構築するためには、いくつかの課題があります。

政府がセキュリティスキルのベースライン認証や規制を設ける機会は非常に多く、戦略では、有限の資源で取り組む方法として、このことを示唆しています。しかし、繰り返しになりますが、これは未来状態の提案であり、影響力の大きい分野を最初にターゲットにすれば、もっと早く始めることができるツールがあるのです。私にとっては、希望の光は各組織内の開発チームにあり、成功するためのツールと知識を与えられれば、一般的な脆弱性を峠で断ち切り、組織内のデータ侵害のリスクを大幅に減らすことができる。

2019年には、データ漏洩全体の24％が人為的なミス、つまりセキュリティの設定ミスが原因となっていますが、これらは通常、比較的簡単なコードレベルの修正です。ここで、全社的なセキュリティ意識の醸成と合わせてトレーニングが優先されれば、侵害された何千人もの顧客への侵害通知に署名するCISOは少なくなるに違いないと思います。

6月23日は、ギークカレンダーの中でも特別な日で、「International Women in Engineering Day」にあたります。年間を通じて仲間やチームの功績を称えるべきですが、この日は、ソフトウェア開発全般に対する女性の貢献度だけでなく、Secure Code Warrior における女性のポジティブな影響にも光を当てるチャンスです。幸運なことに、私たちの組織では男性と女性の比率がほぼ同じで、その中でエンジニアリングチームには優秀な女性がいます。

また、女性の開発者にとっては、技術的な環境が厳しいものであったり、主に無意識の偏見によって女性が不当に不利になることがあることを身をもって知っています。私にとって重要だったのは、誰もが公平に扱われ、多様性が支持され、チームがさまざまな意見や経験、考え方によって豊かになるようにすることでした。結局のところ、エコーチェンバー（反響室）の中に存在する企業が繁栄するはずがありません。聞かれていない声を増幅させることで、信じられないようなことが起こる可能性があるのです。

今週は、私たちのエンジニアリングに多大な貢献をし、本当に素晴らしい仕事で常に模範となっている女性たちの貢献にスポットライトを当てたいと思います。ここでは、当社の技術系スーパースターの一部をご紹介します。

Julia Semeniuk, スクラムマスター

ソフトウェア開発プロセスのどのような点が好きですか？
結果が好きです。一日の終わりに、ソフトウェア開発はすべてのアイデア、フィードバック、デザインをまとめて、ビジネスの他の部分やお客様のために利用できるようにします。

あなたは自分の役割においてどのような課題に直面していますか？
最大の課題は、コミュニケーションと調整だと思います 。常に最も重要な部分に取り組んでいるかどうかを確認する必要があります。そのためには、製品やサポート、その他のチームとの連携が非常に重要です。

自分の役割について最も好きなことは何ですか？
精神とチームワークが好きです。私たちが行うあらゆる仕事は、同期作業やコラボレーションによって達成されています。そして、私たちの仕事の進展や人々の成長を目の当たりにすると、毎日幸せな気分になります。

チーム内の女性をサポートするためにどのような取り組みをしていますか？
Secure Code Warrior では、私たちは幸運にも平等に扱われています。女性だけを対象とした取り組みはないと思いますが、私たちは性別に関係なくお互いをサポートし、尊重し合っています。とはいえ、育児休暇や柔軟な勤務体制などの会社の取り組みは、私たち全員にとって大きな違いをもたらします。

Noemi Alvarez, シニアソフトウェアデベロッパー

Secure Code Warrior での役割。
シニア・ソフトウェア・エンジニア

好きな言語／フレームワーク
Typescript /Javascript - Angular/Node これらは最も経験があり、より快適に感じられるからです。

苦手な言語／フレームワーク
Java / PHP これらの言語を使う機会がなかったので。

どのようにしてソフトウェア開発の世界に入ったのですか？
トレンドのキャリアについて調べたところ、ITもその一つで、大好きな数学の先生が私を素晴らしいエンジニアになると言っていました。

自分の役割において、どのような課題がありますか？
新しい技術やトレンドを常に把握することです。

自分の役割で最も好きなことは何ですか？
一般的には、何かを作って、それが人々に使われるのを見ることです。SCWでは、自分ができる限り安全なものを作るというチャレンジができること。

Laura Verheyde, シニア・ソフトウェア・エンジニア

Secure Code Warrior での役割。
ACEチームの開発者です。基本的には、プラットフォームに新しい課題を提供することを手伝っています。

好きな言語／フレームワーク
C#、.NET。

苦手な言語／フレームワーク
おそらくPHPだと思いますが、それは主に経験不足のためです。

ソフトウェア開発の世界に入ったきっかけは何ですか？
何年も前に、私の親友がみんなITを勉強していて、それがきっかけで興味を持ちました。

自分の役割において、どのような課題がありますか？
自分のコードを追加するために、他人のコードをナビゲートして理解することは、かなり難しい作業です。また、ITの分野ではまだまだ学ぶべきことがたくさんあるという考えから、時には脅かされることもありますが、ある課題を克服したときにはとてもやりがいを感じます。

自分の役割で最も好きなことは何ですか？
私の役割の一部として、コードを構文レベルで掘り下げることがありますが、これはとても興味深いことです。また、自分が貢献したアプリケーションが成果を上げ、SCWのプラットフォームに新しいコンテンツを生み出しているのを見ると、とても満足感があります。

同じようなキャリアを考えている若い女性に何かアドバイスはありますか？
男性中心の職場で働かなければならないという考えに怯える必要はありません。私の場合、最初の数日で不安は解消されました。誰もが望むような、親切で歓迎してくれる同僚たちに出会えたからです。ほとんどの職場でそうだと思いますが。

当社の技術担当副社長であるジョシュ・グラハムは、より多くの女性を当社のエンジニアコホートに迎え入れるためのメンターシッププログラムを開発しています。私たちの目標は、ソフトウェア開発、サイバーセキュリティ、技術分野で何が可能かを示すロールモデルに導かれながら、女性たちにキャリアアップの機会と道筋を与えることです。若い女性にとっては、自分の夢が重要であるだけでなく、手の届くところにあることを実感できるような、共感できる人物が憧れの役割を担っていることが重要です。

業界としても企業としても、テクノロジー分野における女性の真の平等を実現するためには、まだまだやるべきことがあります。私たちは、より多くの女性にオープンな役割を担ってもらうために努力しています。彼女たちの貢献は、私たちを前進させ、私たちが模範となることにつながります。今こそ、偏見や特権、ガラスの天井を認め、現状を変えるための努力を本格的に行う時です。

私たちは、あらゆるバックグラウンドを持つギークたちにとって、安全で協力的な環境づくりに努めています。また、技術系の女性を支援し、グローバルな環境の中で、柔軟な働き方や寛大な育児・家族政策を提供しています。私たちの仲間になりませんか？次のチャンスのために、採用情報ページとLinkedInをブックマークしておいてください。自分らしく働ける職場で活躍したいと考えている熱心な技術者のために、常にエンジニアリングの仕事を用意しています。

この記事の一部分は DevOps Digest.この記事は更新され、ここでシンジケートされています。

この時点で、私たちは皆、「この未曾有の時代に」という言葉に少し飽き飽きしていることでしょう。しかし、今は本当に未曾有の時代です。昨年末には、今年は世界的に破壊的なパンデミックの撲滅に向けて、可能な限りの努力をしていると誰が想像できたでしょうか。世界的な現実というよりは、Netflixの新しいSFシリーズのような、笑い話のような話だったでしょう。COVID-19は、政治的な優先順位は言うまでもなく、私たちの社会生活、経済、雇用の安定性を完全に変えてしまいました。

COVID-19に対する反撃の一つはテクノロジーで、多くの国が連絡先を追跡するアプリを導入しています。オーストラリアでは、シンガポールの「TraceTogether」をモデルにした「COVIDSafe」があります。また、香港、台湾、中国、韓国、イスラエル、ドイツでも、接触者追跡技術が導入されているか、導入が予定されています。英国は、ヨーロッパで最も被害が大きい地域で、ウイルスによる死亡者が数万人にのぼり、感染率も高い。彼らのアプリのリリースが間近に迫っています。同じく被害が大きく、多くの人々が悲劇的に命を落としている米国でも技術が導入されていますが、連絡先の追跡は州ごとに行われているため、状況は非常に複雑です。

中国や台湾のような国家統制の強い国を除いては、これらのアプリの使用は任意であり、市民が自らの意思で技術をダウンロードして使用することが求められています。また、導入率によっては、シンガポールの「TraceTogether」の導入率は25％で、本来の目的を達成することができませんでした。

連絡先を追跡するアプリのアイデアは確かなものです。この技術がうまく機能すれば、ホットスポットを迅速に発見し、総合的な検査を行うことができます。これは、伝染性ウイルスの蔓延に対抗するための重要な要素です。しかし、「政府」や「追跡」という言葉にはあまり魅力を感じませんし、このようなものをダウンロードすることが実際にどのような意味を持つのか、人々が慎重になるのは当然のことです。

では、ユーザーはどのような点に不安を感じているのでしょうか。ネット上のコメントを見ると、以下のような不安があるようです。

• 収集したデータを責任を持って使用するという政府への信頼感の欠如
• サイバー攻撃から個人情報がどの程度保護されるのかという不安感
• どのようなデータが実際に収集されているのか、どこに保存されているのか、そして誰と一緒にいるのかが明確でないこと
• そして、私たち開発者やマニアにとっては、アプリがどれだけしっかりと作られているか。

このような連絡先追跡アプリは、記録的な速さで展開しなければなりません。開発者、セキュリティ担当者、政府機関にとっては悪夢のような話です。

では、不信感は有効な反応なのでしょうか？そして、COVID-19の連絡先追跡アプリとエンドユーザーの安全性について、assessment 、何を優先的に考えるべきなのでしょうか？セキュリティの専門家としての私の直感は、もちろん、プログラムのサイバーセキュリティの要素、つまり、私たちが（善意で）インストールするように強制されているアプリのコードベースがどれだけ安全であるかを掘り下げたいと思います。

多くのアプリはお互いにコピーである（同じ問題を継承する）。

オーストラリアの COVIDSafe アプリは、シンガポールの TraceTogether ソフトウェアと同様、基本的にOpenTrace をベースにしています。しかし問題は、TraceTogetherには様々な問題が報告されていることと、導入率が低いことです。また、特にiOSにおいては、バッテリーの消耗が激しいなど、一般的な性能に関する不満もありました。COVIDSAFEのiOSバージョンには、すべてのデータを適切に記録するために、携帯電話のロックを解除し、アプリをフォアグラウンドで実行する必要があるという、UX上の潜在的な欠陥があります。

上記の問題は煩わしいものですが、より差し迫った懸念は、Bluetoothの脆弱性が蔓延しており、TraceTogetherもオーストラリアのCOVIDSafeもその影響を受けていないということです。5月14日、NISTは、COVIDSafeにサービス拒否の脆弱性があり、攻撃者がBluetoothハンドシェイクの距離にいる場合、遠隔操作でアプリをクラッシュさせることができると報告しました。これにより、組織的な攻撃を受けた場合、人口密度の高い地域でのコンタクトトレースを妨害することができます。この問題は、COVIDSafe、TraceTogether、ポーランドのProteGO、カナダのABTraceTogetherに影響することが知られており、これらはすべて、OpenTraceの欠陥のあるmanuData.subdata呼び出しから問題を継承しています。

Bluetooth機能には、他にもプライバシーやセキュリティの問題があります。この技術が、固有のID（TempID）によって人間の動きを追跡し、意味のあるデータを収集するために使用されているという事実は、弱点を探る攻撃者の関心が高まることを必然的に意味しており、何が収集されているのか、どこに保存されているのか、どのくらいの期間保存されているのかを正確に調べる必要があります。

すでにいくつかのアプリでは、単純なエラーが複雑な弱点を引き起こす兆候が見られます。

オーストラリアのソフトウェアエンジニアであるGeoffrey Huntley氏は、COVIDSafeのソースコードを研究してきましたが、悲しいことに、エンドユーザーである私たちには必ずしも強調されていない問題があります。

致命的な例としては、プライバシーを侵害するロジックエラーがあり、攻撃者がデバイスの長期的な追跡を行うことができてしまいます。これは、アプリ自体のプライバシーポリシーに反するだけでなく、脆弱なユーザーにとっても非常に大きなリスクとなります。

これらのロジックの脆弱性は、5月14日時点でパッチが適用されていますが、より緊急性の高い問題は、ハントリー氏が報告してから17日間、パッチが適用されずに放置されていたことです。ハントリー氏をはじめとする素晴らしいセキュリティコミュニティのメンバーは、COVIDSafeアプリに関連するCVEを追跡しています。

パッチ適用後にHuntley氏が指摘したのは、この修正にも「無能さ」が見られるということです。公開されたログによると、パッチは単に欠陥のあるキャッシュを削除するのではなく、ロジックを追加することで行われており、後者の方がはるかに強固な対処法であると述べています。どちらも機能しますが、生の解決策は繊細さに欠けます-このような重要なアプリケーションでは心配です。

せっかく真面目な社会人が自分の時間と専門知識を使ってソースコードを調べ、問題点を指摘してくれているのに、コードがオープンソースである場合に比べて、彼らの仕事は格段に難しくなっています。現状では、28個のアプリがセキュリティ研究者から閉ざされたままになっています。

セキュアコーディングは、ゴールで躓くことが多いです。

パンデミックの最中に人命救助のためのアプリを作らなければならないという非常に珍しい状況もあり、過労の開発者に同情することはできますが、基本的に共同体のコードベースにいくつかの単純な脆弱性があると、何百万人ものユーザーに重大な問題をもたらす可能性があることを強調しておく必要があります。

ほとんどの人は、善良な市民としてアプリをサポートし、この恐ろしいウイルスの発生を追跡して制御するための最良のチャンスを皆に与えたいと思っていると思います。私も、これを実現するための技術を支持していますが、多くの点で、今回の件は、世界中の開発者に内在する安全なコーディング原則の一般的な欠如を明らかにしました。

ソフトウェアを迅速に作成しなければならない状況では、ミスが発生することは決して想定外ではありません。しかし、論理的欠陥、設定ミス、コードインジェクションエラーなどの一般的なセキュリティ脆弱性は、ボランティアのホワイトハットがコードベースをバラバラにした後ではなく、コードを書いている段階で防ぐことができるものでなければなりません。

ところで、これは開発者のせいではありません。彼らは高等教育を終えた後、セキュアコーディングのスキルをほとんど身につけておらず、キャリアの中でのKPIはほとんどの場合、機能性と納品スピードに関連しており、セキュリティの部分は完成後に他の人が対処することになっています。私たちは、安全なコーディングを迅速に行うという最終状態に到達する必要があります。今は、これらのアプリケーションを構築する部門の文化を劇的に変化させる時ではありませんが、私たちのデジタルリスク領域が拡大しており、セキュリティのベストプラクティスに対する責任を共有するためのツールと知識を与えられれば、彼らは変化をもたらすことができる立場にあるということを、時宜を得て思い起こさせてくれます。

このアプリをダウンロードしても大丈夫ですか？

セキュリティの専門家である私にとっては、このアプリの利点は問題点を上回るという結論に達しました。このソフトウェアに上記のような脆弱性が存在することは理想的ではありませんが、これらが武器になった場合の影響は最悪のシナリオです。現時点では、連絡先の追跡は、世界中の医療関係者が感染の拡大を防ぎ、入院の流れを止め、お互いの安全を確保するための重要な要素となっています。

今回の発表は、ソフトウェアのビルド時にデフォルトでセキュリティのベストプラクティスを導入することに関しては、まだまだ道のりが 長いことを強調するものであり、一般の人々が十分な情報を得た上で意思決定を行うために必要な情報を提供することが重要です。

私たち家族は、今後もこの製品を使い続けますが、皆がすべきこととして、Androidのパッチを最新の状態に保つことには注意を払っています。

この記事の一部分は サイバーディフェンスマガジン.この記事はCyber Defense Magazineに掲載されたものを、ここでシンジケーション用に更新したものです。

昨今、サイバー攻撃は生活の一部となっています。銀行や航空会社、あるいはスマートフォンや信号機など、あらゆる機器に影響を及ぼす新たな脆弱性や侵害に関するニュースが、人々の耳目を集めています。私たちの家でさえ、もはや完全に安全ではありません。都市や町全体が毎日のように犯罪者に襲われ、攻撃者は侵害された重要なサービスを回復するために数百万ドルの身代金を要求しています。

しかし、私たちが安心していられる場所は、医師の診察室、あるいは病院です。人は医療従事者に相談するとき、最も無防備になります。人としての良識があれば、地域の臨床医が平穏にその尊い仕事をすることが許されるはずです。しかし、残念ながらそれは実現していません。今日のサイバー犯罪者たちの間には、名誉もなければ、自暴自棄もないように思われます。実際、医療問題を診断し、治療を行い、生命を維持するための機械を犯罪者が攻撃することで、医療は次の「偉大な」サイバーセキュリティの戦場となる可能性があります。私たちの目の前で持続的な世界的健康危機が展開されている今、この問題には多方面から取り組むことが重要です。

脅威はこれまで以上に個人的なものになっています。

ヘルスケア業界への攻撃は新しいものではありません。サイバー犯罪者たちは、患者の情報、個人情報、財務記録が裏社会やダークウェブで持つ価値をすでに知っています。これらの情報は、患者から直接お金を盗んだり、フィッシングやその他の詐欺などの二次的な攻撃の起点として利用されます。最近、最も被害の大きい攻撃の多くが医療機関を狙ったものであることも不思議ではありません。AnthemHealthcareでは、8,000万件の患者記録が盗まれました。Premeraでは1,100万人分の個人情報が失われました。CareFirst社では110万件の記録が盗まれましたが、その他にも様々な被害が発生しています。

現在のところ、医療機器を直接狙う攻撃は珍しいと思われています。しかし、ある報告書によると、病院が侵入を報告しなかったり、サイバーセキュリティの訓練を受けていない従業員が、目の前で攻撃が行われていることに気づかなかったりするなど、問題ははるかに広がっている可能性があるとのことです。マルウェアを使ってCATスキャンやMRIの結果に偽の腫瘍を追加するなど、恐ろしい方法で医療機器を危険にさらすことができることは、セキュリティ研究者によって決定的に証明されています。現実の世界でも、攻撃者が医療機器に対して同様のことを行っている可能性があると考えるのは、それほど大きな飛躍ではありません。

医療分野では、インターネットに接続され、膨大な量の情報を生成する小型センサーであるIoT（Internet of Things）機器への依存度が高まっていることもあり、サイバー攻撃に対して独特の脆弱性を持っています。しかし、これらのセンサーから得られる情報や、センサーの通信経路、さらにはセンサー自体のセキュリティを確保することは、ほとんどの場合、後回しにされてきました。このようなIoTネットワークに潜む潜在的な脆弱性を攻撃者が悪用する可能性は、ほぼ無限にあります。

ヘルスケアにおけるIoTは重大なリスクをもたらします。

患者の治療に欠かせないサービスは、20年前には想像もできなかったものもあり、IoTベースの脆弱性だけでなく、その他の伝統的な脆弱性の温床にもなっています。電子カルテ、遠隔医療、モバイルヘルスなどは、IoTが提供する情報の増加を待っていたかのようです。ヘルスケア分野でのIoTへの取り組みが驚異的であることも不思議ではありません。MarketResearch.comは、来年までにヘルスケア分野のIoT市場は1,170億ドルに達し、その後も毎年15％の割合で拡大していくと予測しています。

そのような環境では、熟練した攻撃者は、医療機器を悪用するための脆弱性をたくさん見つけることができます。医療機器に組み込まれたIoTセンサーは、通常、2つの方法のいずれかで通信し、データを生成します。あるものは、データを収集し、その結果をすべてインターネットに直接送信して分析します。また、フォグコンピューティングと呼ばれる分散型ネットワークを利用するものもあります。フォグコンピューティングでは、センサー自体がミニネットワークのようなものを形成し、どのデータを中央のリポジトリやプラットフォームと共有するかを集団で決定します。これらのデータは、医療従事者がさらに処理したり、直接アクセスしたりすることができます。

ヘルスケア業界におけるサイバーセキュリティ問題をさらに複雑にしているのは、この業界がデータ処理の標準、方法、保護について受け入れたり、合意したりしたことがないという事実です。歴史的に見て、ヘルスケア業界は、医療機器に独自の技術を提供するメーカーによって支えられてきました。現在では、埋め込まれたIoTセンサー、機器が使用する通信チャネル、収集したデータを分析するためのプラットフォームなどが含まれます。そのため、ほとんどの病院のネットワークはハッカーにとって夢のような場所であり、少なくとも、セキュリティの設定ミスからトランスポート層の保護機能の不備まで、あらゆるものを悪用できる格好の実験場となっています。また、クロスサイト・リクエスト・フォージェリから古典的なXMLインジェクション攻撃まで、あらゆる攻撃が可能です。

必要なカウンターパンチは目の前にあります。

これらの脆弱性が悪用された場合、大惨事になる可能性があるにもかかわらず、楽観的でいられることがあります：これらのセキュリティバグは、犯罪の黒幕が開いた強力なバックドアで、新しいものではありません。これらのセキュリティ・バグは、犯罪の黒幕が開いた強力な裏口というわけではなく、あまりにもありふれたものなので、何度も目にするとイライラしてきます。これらのバグが頭をもたげる理由の一つは、修正プログラムがあるにもかかわらずパッチが適用されていないレガシーシステムの使用によるものですが、もう一つは、再び人的要因に関係しています。開発者は、ものすごい速さでコードを書き、洗練された機能的な最終製品を作ることに集中しています。

あまりにも多くのソフトウェアが開発されているため、AppSecの専門家がそれに追いつくことはできませんし、このように繰り返し発生する脆弱性を常に解決してくれるとは期待できません。つまり、セキュリティチームと開発者は、強固なエンドツーエンドのセキュリティ文化を構築するために、さらなる努力をしなければならないということです。

優れたセキュリティ文化とは、具体的にはどのようなものでしょうか。いくつかの重要な要素をご紹介します。

• 開発者は、一般的なバグを潰すために必要なツールやトレーニングを受けることができる（また、なぜそうすることが重要なのかを理解することができる）。
• トレーニングは包括的で、消化しやすく、開発者の強みを生かすことができます。
• 研修の成果は、評価基準と報告書によって適切に測定される（単なるチェックリストではなく）。
• AppSecと開発者は、同じ言葉で会話するようになります。結局、ポジティブなセキュリティ文化の中では、同じような目標を達成するために働いているのです。

患者さんの医療記録が盗まれるだけではなく、災害の可能性はまだまだ大きいです。スキャンに偽の腫瘍を注入すれば、がんかどうかの判定を心待ちにしている患者さんはショックを受けるでしょう。また、薬を変えたり、治療計画を変更したりすれば、実際に命を落とすことにもなりかねません。しかし、利益のためにその一線を越えようとするサイバー犯罪者が1人いれば、必ず起こることです。次のランサムウェア詐欺は、病院のデータを暗号化するのではなく、何千人もの患者の診断を台無しにするかもしれない。あるいは、お金を払わないと薬を変えてしまうと脅して、文字通り命の身代金を要求する攻撃者が現れるかもしれません。

医療におけるサイバーセキュリティに関しては、もはや「business as usual」アプローチに従うことができないことは明らかです。すべての問題を解決するために、医療機関の1人か2人の専門家に頼ることはできないのです。その代わりに、医療用アプリやデバイスの開発に携わるセキュリティ意識の高い開発者が、潜在的な問題を認識し、施設に配備される前に修正する必要があります。また、医療従事者であっても、基本的なサイバーセキュリティのトレーニングが必要でしょう。

健康に勝るものはないと言っても過言ではありません。医療業界では、将来的にサイバーセキュリティに適した状態を維持するためには、今日、全体的なセキュリティ意識を高めることが重要です。真剣に取り組まなければ、この問題は悪化する一方です。

この記事の一部分は、「Dark Reading」に掲載されています。 ダークリーディング.この記事は、Dark Readingに掲載されたものを、シンジケーション用に更新したものです。

私たちの業界では、多くのセキュリティ専門家が来年の話題の問題を予測することを習慣にしていますが（私も例外ではありません）、2019年に50億件以上の機密データ記録が盗まれたことを受けて、2020年、あるいは予見可能な未来にサイバーセキュリティで何が起きないかを予測する方が正確だと考えました。

このリストは、共同設立者であるマティアス・マドゥと一緒に、笑いながら作成しました。軽い気持ちで書いたつもりですが、悪意のあるサイバー攻撃からすべての組織を守るための長い道のりを考えさせられます。

それでは、私たちの水晶玉を見て、私たちの予測を明らかにしましょう。私たちは見ることができません。

すべてのソフトウェアからSQLインジェクションを根絶する

地球上のすべてのセキュリティ専門家は、SQLインジェクションのバグを特定するために脱線しなくなる日を待ち望んでいたと思います。

悲しいことに、私たちはこの日を20年以上も待ち続けており、少なくともあと1回は待ち続けることになるでしょう。それは、ゴキブリのように、永久に根絶やしにしようとするこれまでのあらゆる戦術に耐えてきた脆弱性です。

しかし、ソフトウェア開発の各段階（特に最初の段階）におけるセキュリティのベストプラクティスの優先順位は依然として低く、SQLインジェクションが発見されて以来、コード生産量が大幅に増加していることを考えると、明らかに不十分です。しかし、ソフトウェア開発の各段階（特に最初から）におけるセキュリティのベストプラクティスの優先順位は依然として低く、SQLインジェクションが発見されて以来、コード生産量が大幅に増加していることを考えると、確かに不十分です。

(SQLインジェクションを引き起こす可能性のあるコーディングパターンについてもっと理解したいですか？ここでチャレンジしてみてください)。

開発者とAppSecが親友に

ああ、開発者とAppSecチーム。彼らが仲良くなることはあるのでしょうか、それともロッキーとアポロのようにライバル関係になる運命なのでしょうか。簡単に言えば、「仲良くできる」ということですが、現在、彼らの優先順位はしばしば非常に異なっています。

この2人がプロジェクトの現場で出会うと、意見が食い違い、最後のハードルで衝突することになります。開発者は、美しく機能的な機能を構築していますが（これが彼らの最優先事項です）、セキュリティの脆弱性が発見されると、その機能はバラバラになってしまいます。ソフトウェア・セキュリティの専門家は、事実上、彼らの作ったものを醜いと言い、開発者に戻ってバグを修正することを強要し、しばしばデプロイメントを遅らせることになります。

現在の状態では、開発者とAppSecチームが、安全なソフトウェアの作成という共通の目標に向かって取り組むまで、この問題は解決しません。2020年（多くの企業ではその数年後）にデフォルトのプロセスとして実現するわけではありませんが、DevSecOpsムーブメントの出現以降、開発者はセキュリティに関するスキルアップの必要性を認識し、最初からセキュリティ目標を含むより高い基準で作業するようになっています。

セキュリティ専門家の供給過剰

2020年、2025年、2030年......世界的に見ても、セキュリティの専門家が不足していることはほぼ確実です。

ISC(2)の報告書によると、現在、約293万人のサイバーセキュリティ分野の人材が不足しているとのことです。この状況は改善される前に悪化することは確実であり、今後数年のうちに私たちを救ってくれる隠れたセキュリティ軍団は存在しません。

当面、このスキル不足に対処するための最大のチャンスは、セキュリティを組織の優先事項とし、既存の従業員をスキルアップさせることです。これは、開発者に安全にコーディングするためのトレーニングとツールを提供し、会社全体のセキュリティ文化を構築することを意味します。現在のAppSecチームのほとんどは、よく知られた古いセキュリティ・バグと戦っていることでしょう（上記のポイント1を参照）。このような一般的な問題を解決するために貴重な時間や労力を費やす必要がないようにすれば、難しいセキュリティ問題（現時点では、APIに関する問題や開発パイプラインに適合するツールの構築などが考えられます）に集中するための帯域が確保されます。

生成されるコードが少ない

世界は驚異的な速さでデジタル化されており、社会的な需要は揺らぐことはありません。

コードの量が増えれば、必然的に潜在的なセキュリティの脆弱性も増えるため、2020年がソフトウェアの生産や侵害にとって低調な年になると考えるのは、グランドナショナルでユニコーンレースが開催されるのと同じくらい現実的です。

データ記録が盗まれることが減った

先に述べたように、コードが増えれば脆弱性が増え、攻撃者がデータを盗む方法を見つける機会が増えることになります。

2019年には少なくとも53億件の記録が世界中で盗まれ、攻撃者に対する防御は、いまだに必死になって反応しているスクランブル状態です。この数字は、今後1年間で2倍にはならないかもしれませんが、それに近い数字になると思います。

一例として、米国で報告された盗難データの前年比の推移を見てみましょう。

2005年から2010年の間を見てみると、年によって多少の波はあるものの、着実に増加しています。これは興味深いことですが、注目すべき重要な要因は、2009年に報告された侵害の数が2008年に比べて急激に減少したことです。しかし、侵害件数が少ないにもかかわらず、盗まれた記録の数は明らかに増加しています。

データレコードは新たな金塊であり、攻撃者にとって価値のあるものです。このグラフは、侵害と盗まれた記録の数が全般的に増加傾向にあることを反映しており、2017年に大きなピークがありました。2018年は、セキュリティ対策が強化されたためか、攻撃件数は減少傾向にありましたが、入手した記録数は過去最高となりました。サイバー攻撃は今後ますます高度化、大量化し、すぐにはなくならないでしょう。また、世界的に見ても、企業がこれまで以上に多くのソフトウェアを急速に生産していることから、2020年に景気が悪化するとは考えられません。企業は、私たちのデータの門番であり、私たちのプライバシーを守るために、よりスマートに仕事をする必要があります。

ビデオベースのセキュリティトレーニングをより長く、より頻繁に行うことを求めるデベロッパー

開発者が大好きなものといえば、何時間ものコンピュータ・ベースド・トレーニング（CBT）ビデオを見ることです。実際、この魅力的なコンテンツへの需要は非常に高く、Netflixはセキュリティトレーニングビデオ専用の新しいサブカテゴリーを発表する予定です。

えー、ダメです。今も、2020年も、絶対にありません。

開発者がセキュリティを知るきっかけとなるのは、職場でのコンプライアンス研修であることが多い。セキュア・コーディングが高等教育の一環として行われることはほとんどなく、職場でのトレーニングがソフトウェア・セキュリティとの最初の出会いとなります。そして、当然のことながら、彼らはそれを好まないことが多いのです。

開発者がセキュリティに真剣に取り組むためには、そしてトレーニングが役に立つためには、開発者の仕事に関連し、魅力的で、文脈に沿ったものでなければなりません。単発のコンプライアンス・トレーニングや、延々と続く退屈なビデオでは、開発者の心をつかむことはできませんし、脆弱性を減らすこともできません。

開発者集団が一般的な脆弱性に対してセキュリティを意識した防御力を持つようになることを望むならば、彼らが日々の仕事の中で遭遇するような実際のコード例を使って作業をしてもらいましょう。また、学習内容を一口サイズにして、簡単に組み立てることができるようにし、遊び心を持って学習意欲を高めるようにします。セキュリティ文化を発展させるためには、ポジティブで魅力的であり、組織全体で実際のスキルとソリューションを開発する必要があります。

誰にもわかりません。適切なトレーニングを受ければ、開発者は自分の中のセキュリティチャンピオンを認識し、安全なコーディングの利点を広く伝えることができるかもしれません。

サイバーセキュリティ関連の事故による死亡者数ゼロ

さて、これは明らかに笑い事ではありません。私は何度も言ってきましたが、サイバー攻撃に関連した事件で人々が死に始めるまでは、世界はサイバーセキュリティに関心を持たないでしょう。

問題は、このようなことがすでに起こっているのに、ほとんど気づかれていないことです。

米国の病院に対するサイバー攻撃が、2019年の心臓発作による死亡者数の増加と関連していることがわかりました。もちろん、攻撃者が患者に致死的な心臓イベントを起こしたわけではありませんが、病院のシステムや機器をランサムウェアで攻撃したことで、重要な治療のための治療時間が遅くなってしまったのです。

セントラルフロリダ大学が行ったこの研究では、3000の病院を分析し、そのうち311の病院がデータ漏洩を経験しました。セキュリティ事故の影響を受けた病院では、心臓発作が疑われる患者に心電図を実施するのに平均2.7分長くかかっていました。これは、手順の変更、新たに導入されたセキュリティ対策、ITサポートの問題などにより、以前よりも多くの時間を要したためと考えられます。心臓発作の発見と治療は時間との戦いであり、これらの病院では、年間平均で心臓発作1万件あたり36人の死者が出ています。

これは衝撃的なことであり、残念ながら、改善される前にさらに悪化すると思います。ソフトウェアセキュリティを向上させ、すべてのビジネスにおいて最優先事項とするために、私たち全員がもっと努力する必要があることを、今回の結果ははっきりと認識させてくれるでしょう。

"フード付きハッカー "のストックイメージの減少

画像検索で「ハッカー」と入力すると、フードを被った顔のない人物がノートパソコンをタイプしている画像や、ガイ・フォークスのマスクを被った似たような人物の画像が、必然的に何千枚も出てきます。

このようなステレオタイプのハッカー像はもう飽きられていますし、誰もが悪者のように見えてしまいます。セキュリティ業界には良い人も悪い人もたくさんいますが、「ハッカー」というイメージにまつわるネガティブな意味合いは、すべての人に不利益をもたらします。
この状況がすぐに変わると思いますか？おそらく変わらないと思いますが、夢を見るのはいいことです。今のところ、セキュリティは決して怖いものではないということを覚えておくことが大切です。