交通系ICカードなどに使われる非接触型IC技術「FeliCa(フェリカ)」のICチップに脆弱性があると指摘された件で8月28日、開発元のソニーや「Suica」に同チップを採用したJR東日本、「iD」のNTTドコモなどが相次ぎ「引き続き安心して使える」旨の声明を発表した。
「Suica」などに採用の「FeliCa」に脆弱性見つかる それでもソニーが「引き続き安心」とアピールする理由 - ITmedia NEWS
脆弱性を指摘した共同通信の記事によると、セキュリティー企業のアンノウン・テクノロジーズ(東京都千代田区)がFeliCaの暗号システムを突破し、暗号鍵を取り出せることを確認したという。アンノウンはIPAの「情報セキュリティ早期警戒パートナーシップガイドライン」に基づき、この脆弱性を7月にソニーに報告していた。
「Suica」などに採用の「FeliCa」に脆弱性見つかる それでもソニーが「引き続き安心」とアピールする理由 - ITmedia NEWS
⇧ 発見したのファインプレー過ぎる気はするのだが、
⇧「独立行政法人情報処理推進機構(Information-technology Promotion Agency, Japan、略称: IPA)」が注意喚起してないの、残念過ぎる...
とりあえず、
スイスチーズモデル(英: Swiss cheese model)は、マンチェスター大学のジェームズ・リーズンが提唱したリスクマネジメントおよびリスク分析のモデル。航空や船舶といった交通の安全、エンジニアリングや医療現場の安全に加え、ITセキュリティにおける多層防御に応用されている。
失敗や欠陥といった問題点をスイスチーズの穴[注釈 1]に見立てる一方、不完全な安全対策を穴の大きさや位置が異なるスイスチーズのスライスに見立て、複数のスライスを重ねることで穴を塞ぐ。すなわち、リスク対策を冗長化することによって安全を確保しようとする考え方である。
⇧ 上図のパターンのように「多重防御」し切れない可能性もゼロじゃないので、「独立行政法人情報処理推進機構(Information-technology Promotion Agency, Japan、略称: IPA)」の資料に事例として残しておいて欲しい気がするが...
2025年9月10日(水)追記:↓ ここから
何やら、
経済産業省は9月9日、報道におけるソフトウェアなどの脆弱性情報の取り扱いについて、改めて「情報セキュリティ早期警戒パートナーシップガイドライン」に即した対応を求める声明を出した。8月28日に共同通信が報じた「FeliCa」の事例が念頭にあるとみられる。
⇧ とあるのだが、情報を隠蔽する期間次第では被害者が続出するかもしれないリスクは考慮しないのかね?
それよりは、早い段階で公表して、対策されるまで利用停止すれば良い気がするんだが...
2025年9月10日(水)追記:↑ ここまで
curlのオプションnoproxyは環境変数のプロキシ設定も無効にできるっぽい
何か、curlを使ったときに「プロキシ」の設定した覚えはないのに、「プロキシ」が利用されてしまってエラーになってしまい、何でだろうと思って徐(おもむろ)に、
printenv
⇧ とかかましてみたところ、
⇧ 上記サイト様にありますように、「環境変数」の、
- http_proxy
- https_proxy
が設定されておりました。
故に、「curl」コマンドを実行すると、問答無用で「プロキシ」が利用されてしまうという罠...
「外部」に対する「リクエスト」は、「セキュリティ」的に考えた場合も「プロキシ」を経由させるべきな気はするので、デフォルトで「プロキシ」を利用するようになっているのは、親切心だということも何となく分からないでもない、周知はされていないので「暗黙知」になってしまっていて「属人化」してしまってはいるわけなのだが...
実際には「プロキシ」の設定が「プロキシサーバー」側で為されていなくて、原因調査に不毛な時間を消費させられることが起きたとしてもイライラしてはいけない、「アンガーマネジメント」で耐え忍ぶのが、サラリーマンの宿命。
で、話を戻すと、「プロキシ」使わずに「HTTP リクエスト」を実行したい時がある、人間だもの。
というわけではなく、「仮想マシン」にインストールしている「ソフトウェア」が提供している「API」に対して、「ソフトウェア」がインストールされている「仮想マシン」内から「HTTP リクエスト」を叩く時なんかは、「プロキシ」無しで実施したいことあるあるですと。
ということで、
⇧ 上記サイト様にありますように、『俺は「プロキシ」を止めるぞ!』というオプション「--noproxy」が「curl」で利用できるようになったらしい。
とりあえず、
⇧ 上記のような心持ちで、「プロキシ」させたくない時もあるということですかね...
ちなみに、ChatGPTに「プロキシ」の設定の優先順位を質問してみたところ、以下のような回答が返ってきた。
優先順位 | 設定方法 | 対象プロトコル | 形式/例 | 備考 |
---|---|---|---|---|
1 | コマンドライン | 全プロトコル | --proxy http://proxy.example.com:8080 |
最優先。環境変数や .bashrc より優先されます。 |
2 | .bashrc (シェル設定) |
全プロトコル | export http_proxy=http://proxy1.example.com |
~/.bashrc に設定された環境変数。シェル起動時に適用され、curl に影響。 |
3 | 環境変数(小文字) | http , https 等 |
export http_proxy=http://proxy1.example.com |
.bashrc よりも後の優先度。小文字(例:http_proxy )が優先される。 |
4 | 環境変数(大文字) | HTTP , HTTPS 等 |
export HTTP_PROXY=http://proxy2.example.com |
大文字(例:HTTP_PROXY )は小文字より後の優先度。 |
5 | no_proxy 指定 |
全プロトコル | export no_proxy=localhost,127.0.0.1 |
特定のホストに対してプロキシを使用しない設定。プロキシ設定より優先。 |
6 | .curlrc (設定ファイル) |
全プロトコル | proxy = http://proxy3.example.com:8080 |
.bashrc や環境変数よりも低い優先度。~/.curlrc は設定ファイル。 |
例の如く、「AI」の回答が「幻覚(ハルシネーション)」なのかどうかが全く分からないのだが、「コマンドライン」を実行の際の指定が最も優先順位が高いということらしいのだが、
- noproxy
- https_proxy
- http_proxy
のように上から順番に優先される感じなのかね?
ハッキリしないのよな...
ちなみに、
⇧ 上記サイト様にありますように、中途半端に対応されていると、結局のところ、どの設定が悪さをしているのか特定するのに不毛な闘いを余儀なくされることあるあるなのが「ソフトウェア開発」なため、発狂しそうになることが屢屢(しばしば)なのだが、
⇧ 上記の「石川啄木」御大のような厚顔無恥の精神を参考にして、心の安寧を得るように頑張りましょう。
今日も今日とて、否応なく精神汚染に晒され続ける大ストレス社会で生活するしかないわけですが、働きたくないですな...
何と言うか、
「働いたら負けかなと思ってる」(はたらいたらまけかなとおもってる)は、2004年(平成16年)に日本で生まれ流行したインターネット・ミーム。
⇧ 上記にある勝ち負けとかはどうでも良いんだが、仮に毎日不自由なく生活できるのに必要な予算を死ぬまで提供してくれる約束が保障されるのであれば、みんな「労働」をしなくなるとは思いますが...
「不労所得」や「FIRE:Financial Independence, Retire Early」って概念が謳われているあたり、「働きたくない」という思想が「マジョリティ(majority)」な気はしますかな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。