Programming – yohgaki's blog

Development, Linux, Programming, Security

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

9月 26, 2022 投稿者 yohgaki

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アプリの入力を厳格にバリデーションする必要があります。

参考：

validate-phpのPHPスクリプト版

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

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

https://github.com/yohgaki/ssblocker

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

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

5月 25, 2022 投稿者 yohgaki

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

もっと読む

Computer, Development, Linux, Programming, Secure Coding, Security

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

5月 14, 2022 投稿者 yohgaki

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

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

このようなスクリプトで

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

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

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

iPhone(iOS)のWi-Fi機能無効化バグ

6月 22, 2021 投稿者 yohgaki

Gigagineで比較的珍しいバグが見つかったことを記事にしています。

「％p％s％s％s％s％n」というSSIDのネットワークに接続すると、iPhoneのすべてのWi-Fi関連機能が無効になってしまう
https://gigazine.net/news/20210620-specific-network-name-disable-wi-fi-iphone/

「セキュリティって難しいんだな」と感じるニュースではなく「大手でも基本が出来てないんだな」と思えれば、似たような問題で困ることが無くなります。

もっと読む

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

常識？非常識？プログラムは1文字でも間違えると正しく動作しない

6月 8, 2021 投稿者 yohgaki

プログラムのコードを書く場合1文字でも間違えると致命的な問題になる事がよくあります。=< であるべき所を < で条件分岐すると困った事になります。何を当たり前の事を言っているのだ？と思うでしょう。プログラマには常識です。プログラマーは1文字も間違いがないコードを書くために懸命にコードを書いています。

しかし、プログラムでデータを処理する場合1文字でも正しく取り扱うことができないモノが含まれると正しく動作できない、これは常識でしょうか？それとも非常識でしょうか？プログラマは自分が書いたコードに正しく処理可能なデータであることを保証するコードに（データを検証するコードを記述）しているでしょうか？入力データの検証はアプリケーションでは必須ですが検証できているでしょうか？

もっと読む

Computer, PHP Security, Programming, Secure Coding, Security

出力時のフェイルセーフ対策が最も重要なセキュリティ対策であるはずがない

6月 3, 2021 投稿者 yohgaki

コンピューターサイエンス・システムエンジニアリングに基づくソフトウェアセキュリティ対策は論理的に構築されており問題ないです。しかし、一般に広まっているソフトウェアセキュリティ対策には出鱈目が普通にまかり通っています。

その最たる例はCWE-20の出鱈目な紹介や解釈です。

JVNのCWE-20の解説が間違っている件について

Terminology
The “input validation” term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.
Some people use “input validation” as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean “checking if an input conforms to expectations without changing it.” CWE uses this more narrow interpretation.
太字部分の訳
他の人々はより狭いコンテクストで”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用する。CWEはこの狭い意味の解釈を採用している。

このように現在の本家CWE-20の用語補足では「”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用」と明記されていますが、CWE-20にエスケープやフィルタリングが含まれる、とする驚くべき解説をする”セキュリティ専門家”が居たりします。（普通は「CWEはこの狭い意味の解釈を採用している」と注釈なくてもそれ以前に解説の文意で判る）

もっと読む

Computer, Development, Programming, Secure Coding, Security

ユーザーや開発者はIPA・専門家の責任にしてWebアプリなどに”本物”のセキュアコーディングを適用する方がよい

5月 31, 2021 投稿者 yohgaki

非エンジニアのユーザーに現在のほぼ全てのWebサーバーは送信されてくるデータが妥当かどうか確認していない、と説明すると驚きます、「そんな仕組みでマトモに動くソフトウェアが作れるのか？」と。当然の疑問でしょう。

実際、コンピュータサイエンス・システムエンジニアリングの世界では一貫して入力データの妥当性検証を重要なセキュリティ対策として実装するように求めています。

現在のISO 27000ではセキュアプログラミング技術の採用を要求しています。セキュアプログラミングで最も重要な事は入力データバリデーションです。2013年にISO 27000が改定されるまで、入力データバリデーションだけは具体的な仕様が解説されていました。2013年の改定で普及したので「セキュアプログラミングを採用する」と簡易にされました。（ハンドブックではないJIS Q 27000:2014の冒頭の改定の経緯解説に書かれています）

もっと読む

Computer, Development, Programming, Secure Coding, Security

JVNのCWE-20の解説が間違っている件について

5月 27, 2021 投稿者 yohgaki

以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」（IPAは2017年からプログラミング原則としている）入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。

追記：指摘通りに修正されました

このブログ最後に記載の通り、メールにて誤りを指摘していました。最初のJVNへのメールから3週間かかりましたが指摘した通りに修正されました。

標準的な入力バリデーション（入力の妥当性チェック）にはエスケープやフィルタリング、脆弱性を隠すという意味はありません。入力データが形式的に妥当であることを検証するのが入力データバリデーションです。これは70年代のFormal Verificationの頃からの定義です。

近年になって乱用／誤解／拡大解釈により間違った意味で使われている場合があるので注意が必要です。

もっと読む

Computer, PHP Security, Programming, Secure Coding, Security

Pharファイルを利用したコード実行 – POP攻撃

5月 14, 2021 #PHP, #セキュアコーディング, #入力バリデーション投稿者 yohgaki

Pharファイルは複数のPHPスクリプトをアーカイブ＆パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。

PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか？解説します。

もっと読む

Development, PHP Security, Programming, Secure Coding

CSSのエスケープ方法

2月 14, 2021 #インジェクション, #エスケープ, #セキュアコーディング, #セキュアプログラミング, #出力対策投稿者 yohgaki

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

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

もっと読む

Database, Development, PHP Security, Programming, Secure Coding, Security

JSONPathインジェクション

8月 3, 2020 #PostgreSQL, #SQLインジェクション, #インジェクション, #エスケープ, #セキュアコーディング, #出力対策投稿者 yohgaki

JSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択／クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。

JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。

https://jsonpath.com/

JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。

もっと読む

Computer, Development, PHP Security, Programming

特定の処理を行うデータを渡すURLの作り方

5月 5, 2020 #PHP, #セキュアコーディング, #入力バリデーション, #暗号投稿者 yohgaki

Webアプリケーションを作っているとデータの完全性と機密性を保ちつつ「特定の処理を行うデータを渡すURL」を作りたくなる場合があります。

例えば、特定のURLをクリックすると特定ユーザーの連絡先にユーザーを登録する、などです。

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

データ型とセキュアコーディング

2月 16, 2019 #セキュアコーディング, #セキュアコーディング論理, #入力バリデーション, #未検証入力投稿者 yohgaki

このブログではどのように”データ型”の概念とセキュアコーディングが関連しているのか、Webサーバーアプリを主体に説明します。

セキュアコーディングの基本を理解している必要がありますが、難しくはないです。原則を知っているだけで十分です。セキュアコーディングの10原則は次の通りです。

１番目の原則「入力をバリデーションする」がデータ型と関連します。

もっと読む

Computer, Development, Programming, Secure Coding, Security

おかしなCWE-20の読み解き方（CWE-20入門）

2月 15, 2019 #アンチプラクティス, #セキュアコーディング, #入力バリデーション, #未検証入力投稿者 yohgaki

徳丸さんが独自の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（≒米カーネギーメロン大学のコンピューターサイエンス学科）が提唱するセキュアコーディング／コンピューターサイエンスの基盤となる基礎概念の紹介では十分ではなかったかも知れません。

CWE-20は知られているか？〜開発者必修のNo.1脆弱性のハズが知られていない〜

もっと読む

Development, PHP Security, Programming, Secure Coding

ソフトウェアに入力バリデーションは必要ない〜ただし条件付きで

2月 8, 2019 #7PK, #アンチプラクティス, #セキュアコーディング, #セキュアコーディング概念, #信頼境界, #入力バリデーション, #未検証入力投稿者 yohgaki

「ソフトウェアには入力バリデーションは必要ない」そんな事がある訳けないだろう？！いつも言っている事と真逆でしょ？！と思うでしょう。

しかし、「入力バリデーションが必要ないソフトウェア（＝コード）」は沢山あります、条件付きですが。

もっと読む