DockerコンテナのXアプリを利用する方法
なんだかやけに長い説明ばかり検索に引っかかったので書きました。
Linuxのローカル環境でDockerコンテナ内のXアプリ(GUIアプリ)を利用するには
$ xhost localhost +
を実行した後に
$ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path
とすれば良いです。
もっと読むなんだかやけに長い説明ばかり検索に引っかかったので書きました。
Linuxのローカル環境でDockerコンテナ内のXアプリ(GUIアプリ)を利用するには
$ xhost localhost +
を実行した後に
$ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path
とすれば良いです。
もっと読む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
もっと読むAlpine Linuxは軽量Linuxディストリビューションの一つでカスタムDockerコンテナのベースイメージに使っている人も多いと思います。Dockerコンテナで複数サービスを起動したい場合、プロセススーパーバイザーを使うのが常道です。DJBのdaemontoolsなら小さく軽量で良いのですが、Pythonで実装されたSupervisordは軽量コンテナにする意味を台無しにするくらいに色々インストールする必要があります。
インストールするパッケージ/プログラム数と管理項目を最小限にしたいミニマリストなら、Alpine Linuxの起動プロセス管理ツールのOpenRC(昔ながらのSysV Initスタイル)を使いたいと思うハズです。私もその一人でしたが、検索してもどう構成すれば良いのかズバリ説明しているページを見つけられませんでした。
ということで、Alpine Linuxなどに付属するOpenRCを使ったDockerの起動プロセス管理の基本を紹介します。
もっと読む今のlibxmlは意図しないエンティティ変換により意図しない情報漏洩などを防ぐ為にエンティティ変換をしない仕様になっています。libxml関数にLIBXML_NOENT(エンティティ変換を行わせる為のフラグ)を渡して処理しないとエンティティ変換が行われません。しかし、例外があります。
もっと読む大抵のシェルスクリプトはセキュリティ対策を考慮する必要がないので与えられたパラメーターはそのまま利用されています。シェルスクリプトを利用して権限の無いユーザーが勝手なコマンドを実行できないようにするにはエスケープが必要になります。
このようなスクリプトで
この場合はエスケープ(やバリデーション)が必要になります。
もっと読むGigagineで比較的珍しいバグが見つかったことを記事にしています。
「%p%s%s%s%s%n」というSSIDのネットワークに接続すると、iPhoneのすべてのWi-Fi関連機能が無効になってしまう
https://gigazine.net/news/20210620-specific-network-name-disable-wi-fi-iphone/
「セキュリティって難しいんだな」と感じるニュースではなく「大手でも基本が出来てないんだな」と思えれば、似たような問題で困ることが無くなります。
もっと読むプログラムのコードを書く場合1文字でも間違えると致命的な問題になる事がよくあります。=< であるべき所を < で条件分岐すると困った事になります。何を当たり前の事を言っているのだ?と思うでしょう。プログラマには常識です。プログラマーは1文字も間違いがないコードを書くために懸命にコードを書いています。
しかし、プログラムでデータを処理する場合1文字でも正しく取り扱うことができないモノが含まれると正しく動作できない、これは常識でしょうか?それとも非常識でしょうか?プログラマは自分が書いたコードに正しく処理可能なデータであることを保証するコードに(データを検証するコードを記述)しているでしょうか?入力データの検証はアプリケーションでは必須ですが検証できているでしょうか?
もっと読む非エンジニアのユーザーに現在のほぼ全てのWebサーバーは送信されてくるデータが妥当かどうか確認していない、と説明すると驚きます、「そんな仕組みでマトモに動くソフトウェアが作れるのか?」と。当然の疑問でしょう。
実際、コンピュータサイエンス・システムエンジニアリングの世界では一貫して入力データの妥当性検証を重要なセキュリティ対策として実装するように求めています。
現在のISO 27000ではセキュアプログラミング技術の採用を要求しています。セキュアプログラミングで最も重要な事は入力データバリデーションです。2013年にISO 27000が改定されるまで、入力データバリデーションだけは具体的な仕様が解説されていました。2013年の改定で普及したので「セキュアプログラミングを採用する」と簡易にされました。(ハンドブックではないJIS Q 27000:2014の冒頭の改定の経緯解説に書かれています)
もっと読む以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」(IPAは2017年からプログラミング原則としている)入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。
このブログ最後に記載の通り、メールにて誤りを指摘していました。最初のJVNへのメールから3週間かかりましたが指摘した通りに修正されました。
標準的な入力バリデーション(入力の妥当性チェック)にはエスケープやフィルタリング、脆弱性を隠すという意味はありません。入力データが形式的に妥当であることを検証するのが入力データバリデーションです。これは70年代のFormal Verificationの頃からの定義です。
近年になって乱用/誤解/拡大解釈により間違った意味で使われている場合があるので注意が必要です。
もっと読むプログラムからCSSファイルにデータを書き込む場合、エスケープしないと不正なCSSになってしまう場合があります。現在のブラウザはCSSでプログラムを実行する仕様が削除されているのでコード実行脆弱性の問題になりませんが、不正なCSSはセキュリティ問題(クリックジャック等)になる場合もあります。
HTML内のCSSの場合、エスケープしないとJavaScriptの実行を許してしまいます。HTMLエスケープでJavaScript実行は防げますが、不正なCSSのインジェクションを防ぐにはCSSエスケープが必要です。適切に処理しないとCSSキーロガーを仕込まれて情報を盗まれたりします。
もっと読むJSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択/クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。
JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。
JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。
もっと読むWebアプリケーションを作っているとデータの完全性と機密性を保ちつつ「特定の処理を行うデータを渡すURL」を作りたくなる場合があります。
例えば、特定のURLをクリックすると特定ユーザーの連絡先にユーザーを登録する、などです。
もっと読むこのブログではどのように”データ型”の概念とセキュアコーディングが関連しているのか、Webサーバーアプリを主体に説明します。
セキュアコーディングの基本を理解している必要がありますが、難しくはないです。原則を知っているだけで十分です。セキュアコーディングの10原則は次の通りです。
1番目の原則「入力をバリデーションする」がデータ型と関連します。
もっと読む徳丸さんが独自のCWE-20(≒入力バリデーション)解説を行っているので、CERT(1989年に米カーネギーメロン大学に設置された世界最古のコンピューターセキュリティ専門機関)が30年くらい前から提唱し、ISO 27000/NIST SP-800-171/PCI DSS等で要求されているCWE-20の解説を改めて書きます。
CWE-20(入力バリデーション)がなぜ重要なのか?それはCERT/MITRE/ISOが入力バリデーションをどのように解説しているかを見れば解ります。いずれも最も重要/一番最初の対策としています。(※ MITREはCWEを管理する組織で、CWEの本家と言える組織です)
徳丸さんのブログより前に、このブログでもCWE-20について以下のブログで既に書いています。CERT(≒米カーネギーメロン大学のコンピューターサイエンス学科)が提唱するセキュアコーディング/コンピューターサイエンスの基盤となる基礎概念の紹介では十分ではなかったかも知れません。
もっと読む「ソフトウェアには入力バリデーションは必要ない」そんな事がある訳けないだろう?!いつも言っている事と真逆でしょ?!と思うでしょう。
しかし、「入力バリデーションが必要ないソフトウェア(=コード)」は沢山あります、条件付きですが。
もっと読む