カテゴリー: Development

gitlab-ci.ymlチェックスクリプト

gitlabのCI/CDは他の今時のCI/CDシステムと同じくYAMLファイルで記述します。リポジトリにCI/CD定義を書けるのは便利なのですが、コミット前に定義が正しいかチェックししたい場合がほとんとです。

少なくともgitlab-ci.ymlをコミット前に文法をチェック/テストしたい!

この場合に使えるスクリプトをたまたま見つけて、便利だったので紹介します。

もっと読む

攻撃可能面(アタックサーフェス)の管理 – セキュリティの基本

Attack Surface (攻撃可能面=攻撃可能な箇所)の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。

攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析(=リスク分析)します。その上でできる限り攻撃可能な箇所を削減(=リスク削減)します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。

Attack Surface (攻撃可能面)

The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attacker”) can try to enter data to or extract data from an environment.[1][2] Keeping the attack surface as small as possible is a basic security measure.

出典:Wikipedia

日本語訳すると以下のようになります。

ソフトウェア環境における攻撃可能面は不正なユーザー(攻撃者)がデータを攻撃対象に入力または取り出し可能な様々箇所(アタックベクター)の集合である。攻撃可能面を可能な限り小さくするのは基本的なセキュリティ対策である

もっと読む

開発者の自由を許容するセキュリティ、自由を束縛するセキュリティ

アプリケーション開発におけるセキュリティ対策は大きく別けて、自由を制限するセキュリティ対策と自由を許容するセキュリティ対策の2種類に分けられると思います。

「セキュリティ対策の為に自由を制限する対策”だけ”でなければならない」とする意見を時々見かけます。しかし、これでは必要な仕様を満すソフトウェアが作れなかったり、不必要なコストが要るソフトウェアになったりします。

もっと読む

セキュリティに拘ってもセキュアにならない – 開発環境セキュリティ

いくらセキュリティに拘っても安全にならない場合があります。その代表例はソフトウェアの開発環境です。そもそもセキュアにすることが無理な場合、別の対策を取る必要があります。

細かいセキュリティ対策を実施するより、本質を捉えて全体対策を行う方がより安全になる場合があります。開発環境はその代表例です。

もっと読む

データのコンテクスト – セキュリティの基礎

コンテクストを知る、はデータを安全に扱う為に必須の基礎知識です。

よくある致命的な脆弱性を作る考え方は

  • コンテクストなんてどうでもよい。このAPIを使えば良い。

です。セキュリティ対策ではコンテクストが何であるのか?を正しく理解することが重要です。ここではコンテクストについて紹介します。

もっと読む

プログラミングを覚えたら先ず知るべきコーディングプラクティス

プログラミングを覚えたら先ず知るべきコーディングガイドラインを紹介します。このブログではこれらのガイドラインを時々紹介していましたが、まとめて紹介するのは初めてだと思います。これから紹介するガイドラインはセキュアプログラミング/防御的プログラミング/セキュアコーディングと呼ばれる考え方に基づいたガイドラインです。

ここで紹介する考え方や基本はコンピューターサイエンティストらによって原理/論理から導き出された概念/考え方です。

論理的に出鱈目なセキュリティの考え方が当たり前かのように啓蒙され、脆弱なアプリケーションの作成を助長しています。最後にアンチプラクティスの例として紹介します。

もっと読む

NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ

NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。

ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。

  • Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
  • セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
  • 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。

要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、

▽セキュリティー対策ソフトを入れる。

などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。

NHKが紹介した対策ページではスクリーンショット等も交えながら

▽アプリは公式アプリストアからのみダウンロードする。

としているのに、「提供元不明のアプリ」(Android 8ではアプリごとの「不明なアプリ」)のチェックボックスをオフにする、を説明しないのは何事だ!という事です。

確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。

このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」(公開していません)の導入部分に追加したスライドを紹介します。

もっと読む

SQLインジェクション対策保証付きソースコード検査はじめました

Webシステムに限らず、SQLインジェクション脆弱性は絶対に作りたくない脆弱性の1つです。裁判でSQLインジェクション対策漏れよる損害賠償が契約金額を上回った事例もあります。

ソースコード検査ならSQLインジェクションが行えないことを保証することが可能です。私の会社ではソースコード検査サービスを提供していますが、これまでに検査証を発行したアプリケーションでSQLインジェクションが問題になった事はありません。 もっと読む

PHPのserialize()/unserialize()を安全に利用する方法

serialize()でシリアライズしたデータを外部に送信/保存1し、それをunserialize()すると危険です。

アンシリアライズは複雑なメモリ操作が必要で、PHPに限らず、何度もメモリ破壊攻撃の脆弱性が見つかっています。このため、外部入力データのアンシリアライズは行うべきではありません。現在のPHPプロジェクトでは、RubyやPythonと同じく、アンシリアライズのメモリ問題を”脆弱性として取り扱わないことになっています。

しかし、外部データでもunserialize()を安全に利用する方法はあります。

もっと読む

ドイツ人と入力バリデーションについて議論した話

メールアドレスから恐らくドイツ人だと思われる開発者とWebアプリ(サーバー側)の入力バリデーションについて議論した内容を簡単に紹介します。

どこかでした議論と同じでデジャブー感ですが、これから書くような感じの内容でした。議論相手のドイツ人の言葉がくだけた感じに書いていますが、「自分の考え方は完璧、私の考え方はとんでもない非常識」と思っていたらしく、お世辞にも丁寧な書き方のメールではありませんでした。この為、くだけた感じで書いています。

とんでもない勘違いをしているのに自信満々の人は手に負えない、と感じる人が多いと思います。私の場合、こういう人でもどういう論理とポイントで議論すれば良いのか?参考になるので楽しんで議論しています。

もっと読む

忘れられた入力処理と出力処理の責任

入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。

入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介します。

脆弱性がないプログラムを作るには、コードからの視点、データからの視点、両方が必要です。ソフトウェアセキュリティの専門家は両方の視点からのセキュリティ対策を啓蒙しているのですが、上手く伝わっていないです。

このエントリはデータからの視点で見たデータセキュリティの話です。

もっと読む