韓国のゲーム業界が中国の会社に市場を蹂躙されて雇用にも影響が出ているという話なのだけど、対岸の火事ではなく、手をこまねいていると日本の雇用にも影響すると警告している。
game.watch.impress.co.jp/docs/

なのでこの方を笑う気はない。ReDosについて考えたというだけでも成果だと思う。

github.com/expajp/reredos/blob
を読んだところ予想通りで、

irb(main):010:0> email
=> "h12o\nh12o@example.com"
irb(main):011:0> Reredos.valid_email?(email)
=> true

こういうこともできる。

ここから読み取れることは、メールアドレスの完全なバリデーションは本当に難しいということだ。
多くの人が挑んですべての人が敗れている(もちろん僕にも無理)。

MacBook Pro(Early 2015)で動かしているVS Codeが重すぎる様子。拡張機能を整理しよう。

出不精エンジニアにおすすめの趣味:
Mastodon鯖の建立(ぜんぶおうちでできる)

いま実は診断実作業は滅多に手がけていなくてほとんど技術営業なのだけど、楽しくやってる。

そこでgem install reredosしてみる。

irb(main):001:0> require 'reredos'
=> true
irb(main):004:0> Reredos.valid_email?('"a \" -OQueueDirectory=/tmp -X/tmp/exploit.php \"a"@example.jp')
=> false
irb(main):005:0>

falseになるメールアドレスはCVE-2016-10033にまつわる徳丸さんのブログエントリ
blog.tokumaru.org/2016/12/PHPM
から引っ張ってきたやつで、RFC的に正しいメールアドレスである。

reredosの作者の方のLightning Talkがおもしろかった(あの場で大垣さんのブログを典拠にするところまで含めておもしろかった)。
要はReDosを実際に試してみた話。そこで、ReDosを回避したメールアドレスチェックをgemで作ったそうで、reredosと名付けたそう。

【定期】上司のTwitterアカウントのスペルをいまだに覚えられない。

Ruby on RailsはHTMLエスケープこそやってくれるがJavaScriptエスケープまではやってくれない。

そういえば昔あったMastodonのXSSまだ突いていない。

(ローカルに閉じた仮想環境の構築が意外と難しいのよね、Mastodon)

僕が自分の書いたプログラムにOSコマンドインジェクションを入れ込んだのって、もう15年前なのだよね(ちなみに自分で発見した)。

> > 不開示とした理由
> > 旅券冊子の情報暗号化に関する情報であり,公にすることにより,旅券偽造のリスクが上がる(以下省略)
> ほぼすべての文が間違っており、どこから突っ込んで良いのか分かりませんが、 公開鍵を公開しても安全と秩序が損なわれることはないし、(以下省略)
たぶん自分たちも情報セキュリティに詳しくないことは分かっているけど誰かに判断を頼むことができない状況で自分たちで判断するしかなく、「旅券冊子の情報暗号化に関する情報」だから「公にする」ことはまずいに違いないという流れなんじゃないかと推測。この方が書いているように「病」だなあ。
osstech.co.jp/~hamano/posts/ep

>>
ただし、3キャリアがあえてこの形にしているのは、理由があります。前述の担当者は「大手3社共通のプラットフォームとして+メッセージを提供すると、独占禁止法に抵触する可能性がある」と話します。大きなシェアを持つ3社が共通の基盤を作ると、"囲い込み"をしているとみなされる可能性があるため、あえて「同じ名前で各社が運営する」という形をとっているわけです。

一方で、この+メッセージの運営形態は、MVNOや新規参入する楽天モバイルなど「大手キャリア以外」のサービス提供の障壁となっている可能性があります。
<<
やっぱりとしか言いようがない。
japanese.engadget.com/2019/04/

Show more