Secure Coding – ページ 4

Computer, Development, Programming, Secure Coding

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

8月 5, 2018 #アンチプラクティス, #セキュアコーディング, #ベストプラクティス投稿者 yohgaki

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

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

Computer, Database, PHP Security, Programming, Secure Coding

「フェイルセーフ」とは何なのか？

8月 3, 2018 #MySQL, #PHP, #PostgreSQL, #セキュアコーディング論理, #フェイルセーフ, #ベストプラクティス, #出力対策投稿者 yohgaki

「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」¹と言われることもありますが、基本概念は同じです。よく聞く言葉＆簡単な概念ですが、割と広く誤解されている概念の１つに見えます。

フェイルセーフを一言で言うと

何かに失敗しても致命的な問題に至らないよう安全に失敗させる

これがフェイルセーフです。可能ならば「失敗／故障しても、失敗／故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。

Wikipediaの定義では

フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。

となっています。

こんな単純な概念は間違いようがないでしょ？

と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。

Computer, Development, PHP Security, Programming, Secure Coding, Security

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

8月 2, 2018 #アンチプラクティス, #セキュアコーディング論理, #セキュリティ構造, #信頼境界, #入力バリデーション投稿者 yohgaki

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

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

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

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

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

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

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

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

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

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

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

Computer, Development, Other, Secure Coding, Security

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

7月 27, 2018 #セキュアコーディング, #ソースコード検査投稿者 yohgaki

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

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

Computer, PHP Security, Programming, Secure Coding

何故こうなった？プログラムの動作原理を無視したセキュリティ対策

7月 25, 2018 #アンチプラクティス, #セキュアコーディング論理投稿者 yohgaki

正しく動作するプログラムには

正しい／妥当なデータ
正しいコード

の両方が必要です。

仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。

当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう？

参考：プログラム動作の構造、原理と原則

セキュアコーディングの構造／原理／原則

Computer, Development, PHP Security, Programming, Secure Coding

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

7月 22, 2018 #PHP, #セキュアコーディング技術, #暗号投稿者 yohgaki

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

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

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

Computer, Development, PHP Security, Programming, Secure Coding