PHPのJSONのエスケープ

PHPのJSONのエスケープ

追記:最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。

JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。

PHPにJSON形式のデータに変換するjson_encode関数json_decode関数をサポートしています。

JSON関数がサポートされている話は簡単!となれば良いのですが、 いろいろ考慮しなければならない事があります。

TL;DR; PHPのjson_encode()を安全に利用する方法

json_encode()を利用する場合

$json = json_encode($data, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT);

と利用します。これでもまだ最適なエンコード方式とは言えませんが、デフォルトとして最低限必要なオプションが

JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT

です。

JSONデータの文字エンコーディングは基本UTF-8です。UTF-8文字データは”予めバリデーションしておく”必要があります

もっと読む

SSBlocker – 攻撃元のIPアドレスをブロック

SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。

SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマージされる可能性の低いです。

Fail2banはPythonで作られていてメンテナンスも比較的容易です。しかし、削除された機能を使用しておりメンテナンス状態も良くないです。今のPythonで動くようにしても良いのですが、Fail2banは無駄に大きいです。そしてPythonはあまり速くもないです。

Webアプリも放置していれば攻撃できるか試し放題です。OWASP TOP 10 A09:2021-Security Logging and Monitoring Failures に準拠するにも「ほぼリアルタイム」のIPアドレスブロッカーが欠かせません。 A9:2021に対応するにはブロックツール以前に、Webアプリ攻撃ツールなどが生成するリクエスト(入力)を検知し記録しなければなりません。このためWebアプリの入力を厳格にバリデーションする必要があります。

参考:

(注意: A9:2021はWAFを導入するという基準ではないです。Webアプリが攻撃(≒無効な入力)を検知・記録・対応する機能がないと脆弱なWebアプリだとする基準です、念の為)

という事で簡単に拡張(どんなログでもパースしてブロック)できて、300行ほどの一つのスクリプトでそこそこ速く、簡単にカスタマイズできるIPアドレスブロッカーを書いたのでgithubに入れておきました。

https://github.com/yohgaki/ssblocker

もっと読む

shellスクリプト文字列のエスケープ

大抵のシェルスクリプトはセキュリティ対策を考慮する必要がないので与えられたパラメーターはそのまま利用されています。シェルスクリプトを利用して権限の無いユーザーが勝手なコマンドを実行できないようにするにはエスケープが必要になります。

  • setuid/setgidをしたシェルスクリプト
  • 信頼できない入力を処理するシェルスクリプト

このようなスクリプトで

  • sshなどでリモートコマンドを実行するスクリプト
  • 処理を書き出して実行するスクリプト

この場合はエスケープ(やバリデーション)が必要になります。

もっと読む

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

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

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

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

もっと読む

CSSのエスケープ方法

プログラムからCSSファイルにデータを書き込む場合、エスケープしないと不正なCSSになってしまう場合があります。現在のブラウザはCSSでプログラムを実行する仕様が削除されているのでコード実行脆弱性の問題になりませんが、不正なCSSはセキュリティ問題(クリックジャック等)になる場合もあります。

HTML内のCSSの場合、エスケープしないとJavaScriptの実行を許してしまいます。HTMLエスケープでJavaScript実行は防げますが、不正なCSSのインジェクションを防ぐにはCSSエスケープが必要です。適切に処理しないとCSSキーロガーを仕込まれて情報を盗まれたりします。

もっと読む

SELinuxを有効化したままDockerコンテナから/var/run/docker.sockを使用する

必要になる度に調べているのでメモ。少なくともRHEL系はこれで動くようになるはずです。出来れば/var/run/docker.sockにアクセスが必要なコンテナだけにアクセス許可を与えたいのですが良い方法を思い付きません。それでもSELinuxを無効化するより/var/run/docker.sockだけアクセス可能のする方がホストの安全性は高くなります。そもそもボリューム(ファイル)にアクセスできないとアクセスできないので、ほとんどの環境※では、リスクは大きく増えないでしょう。

※ Dockerコンテナを作る人を信用できない場合、無視できないリスクがあります。コンテナ好き勝手に弄られる可能性があります。古いDockerがloopbackでコマンドを受け付けていた時に外部ユーザーから好き勝手にコンテナを弄られる脆弱性がありました。これと同じです。

もっと読む

LibXMLのエンティティ変換とXXEと…

今のlibxmlは意図しないエンティティ変換により意図しない情報漏洩などを防ぐ為にエンティティ変換をしない仕様になっています。libxml関数にLIBXML_NOENT(エンティティ変換を行わせる為のフラグ)を渡して処理しないとエンティティ変換が行われません。しかし、例外があります。

もっと読む

Alpine Linux Dockerコンテナ ー initスクリプト(OpenRC)によるプロセス管理

Alpine Linuxは軽量Linuxディストリビューションの一つでカスタムDockerコンテナのベースイメージに使っている人も多いと思います。Dockerコンテナで複数サービスを起動したい場合、プロセススーパーバイザーを使うのが常道です。DJBのdaemontoolsなら小さく軽量で良いのですが、Pythonで実装されたSupervisordは軽量コンテナにする意味を台無しにするくらいに色々インストールする必要があります。

インストールするパッケージ/プログラム数と管理項目を最小限にしたいミニマリストなら、Alpine Linuxの起動プロセス管理ツールのOpenRC(昔ながらのSysV Initスタイル)を使いたいと思うハズです。私もその一人でしたが、検索してもどう構成すれば良いのかズバリ説明しているページを見つけられませんでした。

ということで、Alpine Linuxなどに付属するOpenRCを使ったDockerの起動プロセス管理の基本を紹介します。

もっと読む

Fedora/LinuxでZFS on Linuxを使う

Fedora(Linux)でボリューム管理、スナップショット、圧縮、RAID5以上の性能と可能性を持つファイルシステムで”安定しているファイルシステム”となるとZFSしかありません。

機能的にはBtrfsも同等の機能を持っています。しかし、少なくともこのブログを書いている時点では、RAID56はカーネルがクラッシュした場合などにファイルシステムが壊れてしまう問題があります。2017年8月に修正パッチが提案されていますが、12月現在でも運用環境では使用しないように、と注意書きがあります。

ZFS, Btrfsは両方ともデータの整合性のチェックが可能です。一般にログファイルシステムと呼ばれているファイルシステム(NTFS, XFS2, Ext4など)はディレクトリ情報などのメタデータの整合性をログで維持しています。ZFS、Btrfsはメタデータの整合性に加え、データ自体の整合性もハッシュでチェックしています。冗長性を持たせていない場合でも、HDDのセクタ不良でどのファイルが壊れたのか確実に判ります。

HDDは普通一気に使えない状態になりません。RAID1で冗長性を持たせていても、どちらかのHDDのセクタ不良の場合はどちらのデータが正しいのか?判断できません。ZFSやBtrfsなら、どちらのデータが正しいのか判断できます。

データ整合性の保証はZFS、Btrfsの大きなメリットです。

※ Fedora用に記載していますが、UbuntuやCentOSなど、他のLinuxでZFSを使う場合も基本は同じです。

もっと読む

マグネット式のスマホホルダーは大丈夫/十分なのか?

車用にスマホホルダーを購入するにあたり、最近はマグネット式が多いと分かりました。そこで気になるのが「マグネット式のスマホホルダーは大丈夫なのか?」です。

  • 磁力が電子機器の塊であるスマホに悪影響を与えないか?
  • マグネットでしっかり固定できるか?

このあたりが気になるはずです。

もっと読む

入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説

標準的な入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説があります。そのような入力バリデーションを定義した標準的なセキュリティガイドライン/規格は見た事がありません。標準的な入力バリデーションでは何をすべし、とされているのか紹介します。

もっと読む