Skip to main content

セキュアコーディング評価サービス

 

Service Block Builder
  • 多くのWEBアプリは、入口でセキュリティ
    チェックを行わず、不正データの侵入を
    許可する設計になっている。
    エラーが起きてから対応する仕組みで大丈夫ですか?
    侵入を阻止して、「エラー」「バグ」[サイバー攻撃」を引き起こさせない。
    入口で入場拒否をすれば 動作不良、機能不全、不正操作、データ搾取、
    改ざんはかなり防げます。
    驚かれるかもしれませんが
  • WEBアプリの「入力データバリデーション(検証)」
    の状態を評価
    侵入して徘徊し「いつ」「どこ」に「どんな」悪さをするか分からない侵入者や、
    特定の目的のある悪意ある侵入者を入場させない・攻撃させない仕組みが
    どこまでできているか検査します。
    入口の安全対策はできていますか?
  • 未然に防げる問題が沢山あります
    スペシャリストによる「手動」と「自動」の
    ダブルチェックで検査精度を追求
    セキュアコーディングで1番重要とされている「入力データバリデーション」
    実装できていますか? アプリが正しく動き続けるために、深刻な障害・攻撃から
    システムを守るために入口でセキュリティ対策。

「入力データバリデーション」の実装状態をチェック

セキュアコーディング評価サービス

 

ESIの『セキュアコーディング評価サービス』は外部からWebサイト/サービスに
アクセスし、「入力データバリデーション(検証)」の実装状態を確認。
「入力データバリデーション」はセキュアコーディングの第1原則。
スペシャリストの目視による「手動チェック」とツールによる「自動チェック」の
ダブルチェックで検査精度を追求 ! 

不正データの侵入を未然に防ぐ!

運営サイトのセキュリティ向上をしよう

 

まず、サイトの入口で不正な侵入を拒否する・侵入させないことが重要です。

しかし、実は多くのサイトで入口のセキュリティ対策が取られていません。

(「入力データバリデーション」が実装されていない状態)

本サービスで実装状態の確認をして、「侵入させない」対策を始めましょう!

知る!サイト侵入口のセキュリティ状況の確認
知る!サイト侵入口のセキュリティ状況の確認

「エラー」「バグ」「攻撃」の原因となり得る、不正データの侵入を拒否する作りになっているか、本サービスで「入力データバリデーション(検証)」の実装状態をチェックします。

報告書をもとにプログラムを修正する
報告書をもとにプログラムを修正する

本サービスの報告書を基に、「入力データバリデーション」がしっかりと実装できている、より安全なプログラムに改修を。運営者様が開発会社様へご依頼しやすい「報告書」をご提供します。

修正が困難な場合は、ワンストップで修正方法のご相談も可能
修正が困難な場合は、ワンストップで修正方法のご相談も可能

追加でソースコード検査をご依頼いただきますと、明確な修正箇所、詳しいプログラム修正方法のご提案が可能です。(3ヶ月間無償テクニカルサポート付き)

深刻な障害につながるものも含めた「エラー」「バグ」「攻撃」へ対策の大きな一歩

「入力データバリデーション」がしっかりと機能するプログラムに改修することにより、

以下の対策が可能です

不正アクセス対策

サービス妨害(DoS)

全インジェクション攻撃対策

 データ漏洩対策

データ改ざん対策

システムの信頼性・安定性の向上、など

※インジェクション攻撃とは、Sqlインジェクション、Javascriptインジェクション、コマンドインジェクション、etc

「初めてかも」「聞いたことはあるけど・・・」という方へ

「入力データバリデーション」について少しご紹介

「不正なデータは侵入しない設計にしてあるはず」と思われていますが、入口で入力データを検証する機構「入力データバリデーション」を実装していないWebシステムが大半です。まずは「侵入させない設計」にすれば多くの問題が未然に防げる!セキュアプログラミングの第一原則である入力バリデーションが不十分である場合は早急にアプリケーションの改修が必要です。

1.『入力データバリデーション』とは?

入力データが、ソフトウェアが想定しているデータ形式であるかどうかを「検証」することです。すなわち、データの「妥当性」を明確に確認して、「安全性」を向上させること。

 

想定外のデータ形式の入力データ(不正データ)の場合は、プログラム内へ入れない仕組み。プログラムが正しく動作する為に「妥当な入力データ」だけ入場を許可します。Webクライアントからは整数しか送信できないデータが文字列であるのは不正です。このような不正なデータは「アーリーイグジット/フェイルファースト原則」(失敗する場合は可能な限り早く失敗させるプログラミング原則)に従って拒否する必要があります。

 

玄関ドアを設置する、カギをかける、建物の入口のガードマンのような働きや、IDがないと建物内に入れないなどと同様、入口のセキュリティ対策です。安全なプログラムである為に、一番重要な機構です。

3.『入力データバリデーション』が機能していないと何が起きる?

想定外のデータがプログラム内部に侵入し、アプリケーションが正しく動かなくなります。そして、「どんな」誤作動が「いつ」「どこで」起きるのかわからない状態にー。

 

誤作動には、サービスが提供できなくなったり、不正アクセスをされデータがなくなったり、改ざんされたり、データが盗まれたりすることも含まれます。「 エラー」、「バグ」、そして「攻撃」による甚大な被害を与える動作を許してしまいます。

5.どんな組織が「入力データバリデーション」をセキュリティ対策として要求しているのか?

以下の組織が、「入力データバリデーション」を要求しています。

 

  • ISO (実質1995年から)ISO17799、ISO27001
  • IPA(2017年から)セキュアプログラミング講座
  • MITRE(日本のIPAに相当する米国の政府外郭機関)CWE TOP 25 など
  • CERT(1989年から)セキュアコーディング原則
  • OWASP(2005年から)OWASP TOP 10など
7.セキュアコーディング/プログラミングで最も重要な原則は『入力データバリデーション』

「セキュアコーディング」は、安全なプログラム構築する為のプログラミング技術です。安全なプログラムとは開発者が意図した通りに動作するプログラム。セキュリティ問題はたった一文字の間違いでも致命的問題になります。細かいコーディング技術から大きな基本原則まで全てが重要ですが、まず原則が実装されていなければ始まりません。その原則の一番目が『入力データバリデーション』です。

2.『入力データバリデーション』は何をチェックする?

セキュリティ対策として「入力データバリデーション機構」を使い、すべての入力に対して、以下のチェックをする設計になっていることが重要です。

 

  • 長さ
  • 入力タイプ
  • 文法/形式
  • 入力の過不足
  • 入力値の整合性
  • ビジネスルール

 

これらをチェックし、必要としている値以外はプログラムの内部に入れさせない、プログラムに設計した以外の動作をさせないようにします。

 

4.例えば、どんな攻撃がある?

「エラー」「バグ」どちらも「不正な値」のデータが侵入してプログラムが想定した動作ができない状態です。そして、悪意ある攻撃者もまたアプリケーションに対して「不正な値のデータを送って攻撃」します。 「不正な値」を排除しないとサンドバック状態、攻撃され放題です。(OWASP TOP 10:2017 A10に脆弱なアプリになる対策をしてないアプリは)

 

例えば、攻撃者はよくあるセキュリティ問題があるかどうか「一度に沢山のパラメーターを送って確認」します。これらには、URL/HTTPヘッダー/POSTデータにありとあらゆるデバッグフラグとなる引数を大量載せて確認します。

 

2019 CWE TOP25 CWE-20 は、深刻な脆弱性につながる最も広く知られている重大なソフトウェアの弱点の実証リストです。

 

6.多くのWEBサイトで実装されていない現状

あなたのサイトは大丈夫ですか?

実は、外部から何が送りつけられてくるのか分からないのに、多くのサイトで入口でセキュリティ対策していない(「入力データバリデーション」を実装していない)サイトが多いのが現状です。

 

つまり、安全なプログラムではない状態です。

 

例えるなら、自宅に想定外の見知らぬ人がいつでも自由に出入りする可能性がある状態です。悪意がある・なしに関わらず盗んだり、壊したり、傷つけられるかもしれません。徘徊されるだけでも嫌ですよね。

 

プログラムの場合、エラーや被害が露見するまで、侵入してしまえばその姿に気が付かないのも特徴です。

 

できる限り、まずは悪さをする可能性がある「不正データ」は拒否して、内部に入れないことが重要です。

 

セキュアコーディング評価サービスでは、「入力データバリデーション」の実装状態を評価します

 

「入力データバリデーション」を正しく実装すれば、

 

▶ 内部で徘徊し「いつ」「どこ」に「どんな」悪さをするか分からない

「信頼できない」データの侵入を防げます。

▶ 特定の目的のある「悪意のある侵入者」も、入口で拒否をすれば防げる

問題、深刻な障害もかなりあります。

 

本来プログラムは設計通りに動作すること。

それを妨害する入力値の侵入は「入力データバリデーション」でかなり対策が可能です。

対策してサイトを守る!

「セキュアコーディング評価サービス」の特長

セキュアコーディング/セキュアプログラミング技術の導入は国際情報セキュリティ標準でも要求されている基本的なセキュリティ対策です。

1.  安価でスピーディ

最短でご発注の翌日対応可能です。

価格は以下のプランでご確認を!

2. 報告書は開発会社様へ

運営者様が開発会社様へサイト改修の依頼がしやすい「報告書」をご提供します。

3.  修正方法もご提案可能

追加でソースコード検査ご依頼で、明確な修正箇所・方法のご提案可能(3ヶ月無償テクニカルサポート付)

 

「入力データバリデーション」で向上する!

セキュリティ対策の効果

セキュアコーディングで最重要とされている、入力データバリデーションが適切に実装されているかどうかを確認して、入口のセキュリティ対策状況を知り、向上に向けて開発会社様に明確な依頼ができます。そして、必要なアプリケーションの改修をすることで、以下のような効果が期待できます。

攻撃を受けにくいサイトに!

悪意のある不正データの侵入を防ぎ、プログラムをより安全な状態で動かすことができます。

 

トラブルが減る

システムがクラッシュしたり、メモリやCPUを過度に消費するなどのトラブルが減ります。

 

深刻な障害から守る!

 不正アクセス、データ漏洩、データ改ざんなど、顧客に損害を与え、ビジネスに大きな損失をもたらす障害から守ります。

 

ライブラリやフレームワークも!

 ライブラリやフレームワークにセキュリティ上の問題があっても、その影響を受けない可能性が高くなる。

サービスを滞りなく提供できる!

トラブル・障害が減ることでビジネスコストを大幅に削減。安定的な運営でサービスへの信頼度もアップ!

OWASP TOP 10 A10:2017の対応にも必須

 

OWASP TOP 10 A10:2017 不十分なロギングとモニタリング を実装するには、厳格な「入力バリデーション」が必須です。

「入力データバリデーション」は OWASP標準への対応にも欠かせないアプリケーション機能です。

 

※ OWSAP TOP 10 A10:2017 不十分なロギングとモニタリング に対応したアプリケーションの場合は事前にご相談下さい。 

3つのプランをご用意しました

各プラン毎に検査時間を設定し、ベストエフォート型でお約束した時間の限り検査を行います。

検査時間に調査時間は含みません。

ベーシックプラン
8万円(+税)

ご注文から評価完了まで: 1~2週間

評価対象となる2箇所を弊社が設定

標準プラン
24万円(+税)

ご注文から評価完了まで: 1~2週間

評価対象となる2箇所をお客様が設定

2箇所を弊社が設定

カスタムプラン
お見積

ご注文から検査完了まで:1~2ヶ月

評価対象をお客様が指定しお見積

 

「セキュアコーディング評価サービス」に関する

お申し込み・お問い合わせ

 

ご相談・ご質問等がございましたら、まずはお気軽にお問い合わせください!

各種ご相談・ご質問・お見積り依頼はこちらで受け付けております。

お急ぎの方は、お電話でも承ります。

 

お問い合わせ・お見積りのご用命は

 

お見積りのご依頼を頂きましたら、3営業日以内にお見積りをお送りいたします。

参考資料:

解説: 「標準入力バリデーション(Starndard Validation)」について(2011 CWE/SANS Top25  Monster Mitigation 引用 )

<訳文>

不適切な入力バリデーションは健全なソフトウェアにとって一番の殺し屋である。言うなれば、入力が期待どおりであることを保証できないなら問題を起こしてくれ、と頼んでいるようなものである。例えば、数値であることが期待されるIDは文字を含んではならないし、新車の価格として1ドルは今日の経済状況ではあり得ない。勿論、そんなシンプルな例よりもっと複雑なバリデーション仕様を持つアプリケーションが一般的である。攻撃者が予想外の方法で入力データを改ざんした場合は、不適切な入力バリデーションよって脆弱性が引き起こされかねない。適切な入力バリデーションを利用すれば、現在一般的である脆弱性の多くを排除すること、または少なくとも削減することが可能である。

「標準入力バリデーション機構」を使って、すべての入力に対して以下のチェックをしなければならない:

 

  • 長さ
  • 入力タイプ
  • 文法/形式
  • 入力の過不足
  • 入力値の整合性
  • ビジネスルール

 

ビジネスルールの例として、"boat"は英数字文字のみ含むので文法的に妥当であるかも知れない。しかし、”red"と"blue"といった色名を期待している場合は不正である。

可能な箇所では、文字列のホワイトリストを用いてリクエストに含まれる文字セットを制限すること。この対策は、例えば製品の何処かに含まれる弱点を排除または軽減するなど、間接的に役立つ可能性がある。

これらのルールを破る如何なる入力も受け入れてはならないし、入力を安全な値に変換してもならない。

パラメーターまたは引数、クッキー、ネットワークから読み取られる全ての値、環境変数、DNS逆引き、クエリ結果、リクエストヘッダー、URLの構成要素、メール、ファイル、データベース、そしてアプリケーションにデータを提供するあらゆる外部システム、こういったものにより信頼できない入力が侵入するのだが、その可能性のある箇所が自分のソフトウェアの「どこ」なのか、をすべて把握しておかなくてはならない。

これらの入力はAPI呼び出し等により間接的に得られる事も忘れてはならない。

エンコードされた入力は適切にデコードされるよう注意し、バリデーションを実施する前に内部の表現形式に変換しなければならない。

 

 

具体的には「標準入力データバリデーション」を全ての信頼できない外部入力に対して適用します。「標準入力データバリデーション(Standard Input Validation)」は  CWE/SANS Top25:2011  Monster Mitigation #1で解説されています。