2018年6月26日火曜日

正しく動作するプログラムには正しいデータが必須とは限らない

「正しいデータが必須条件」がプログラムの動作原理に基づく条件としている方がおりますが、それは間違っています。

仕様上あり得ない入力を受け入れる必要性があることもあります。
ソフトウェアは様々な物が存在し、そう単純ではないのです。
これが卓上の論争をしている人と、現場の人の意見の違いだと思います。

また別のある人は、「入力値検証では値の変更をすべきではありません。」とも書いています。
「全角数字が入っていたから半角にするなど、一見親切っぽい動作ですが、はっきりいって邪魔です。」と言っています。

まぁたしかに、プログラムを組むだけの人から見れば、余計な脆弱性を組み込む原因となるかもしれないから嫌だと思うかもしれません。
しかし実際は、業務上それが必要になることもあります。
全角入力でいちいちエラーになるより、自動半角で通した方がスムーズなのは明白ですからね。
特に一般ユーザーに入力させる場合、これをやるかどうかで売り上げに結構響きます。
そもそも全角半角って何?ですから。

またよくあるのは、1行のテキストボックス。
仕様上改行を入れることはできない、と普通は思います。
しかしコピー&ペーストを使うことで改行を含ませることができます。
そして、エクセルからのコピーでは改行が含まれます。
業務内容によっては、不正な改行を取り除いて正常なデータとして扱うという処理が必要になります。

こういった例は他にも色々あります。
いくらセキュリティーが高くても、目的を達成できなければ本末転倒なのです。
よって、入力の種類は4種類になります。

・正しい入力
・入力ミス
・不正な入力だが、ホワイトリストにより変換して正常に扱える入力
・完全に不正な入力


何を目的とするプログラムか。 それが一番大切です。
何事も、手段が目的にならないようにする必要があります。

2018年6月23日土曜日

Coinhiveは 仮想通貨発掘マルウェアだよ

近年登場して問題となっているマルウェアに、仮想通貨発掘マルウェアがあります。
感染したパソコン上で発掘するという悪質なソフトウェアです。

そしてさらに発展させて素人でも手軽に行えるマルウェアが登場しました。
それが coinhive です。

次々と逮捕されてますので、絶対に使わないようにしましょう。
少し考えれば、悪い事だってぐらいわかるはずです。たとえ違法じゃなかったとしてもやりすぎだ。
おそらく、バレないだろうと思って使うのでしょうけど、バレますんで使っちゃダメです。

あと、ある有名なセキュリティ専門家が反社会的なとんでも理論で正当化しようとしていたのは、とても残念に感じた。テロリストと同じ思考だということに気づいていないのだろうか。

coinhiveは簡単にブロックできますので、各ブラウザの拡張機能/プラグインを使ってブロックしておきましょう。no coinとか。
ウイルススキャナーを入れていれば、大抵はブロックしてくれると思います。
今時のブラウザの仕組み上、ブラウザを閉じても裏で発掘させることができますので、ブロックは必須に近い状態です。

合法的にcoinhiveを使いたければ、サイトのプッシュ通知の許可と同じことをすればいいんじゃないだろうか。
そうすれば、利用者の意思で動かしているので問題ない。いちいちポップアップするのでうっざいですけど。


coinhiveがどう悪いか、適当に書いてみると、

・サイトの片隅に表示される広告とはまったく別です。
広告は訪問者側にも利益がある場合があります。無ければ広告を表示する意味が無いわけですし。広告をクリックして商品購入をするってことは、その広告が訪問者の役に立ったということです。需要と供給なのです。ただリンクを置いているだけですし。
coinhiveはどうですが?訪問者に無断で敷地内で商売(採掘)をはじめるんですよ。
もはや泥棒と同じですよね。※リソースを泥棒して売り払う犯罪行為

・今やどのサイトもjavascriptが走っていてCPUに負荷がかかっていて、coinhiveもその中の一つですって?
おいおい、目的がまったく違うでしょう。すなわち許容を超えてるってこと。
coinhiveはサイトとは関係ないでしょ。 利益でサイト運営だから広告と同じだって? それじゃ上の説明に戻ってね。

・ブラウザのタブを10個20個開く人は結構多い。勝手に踏み台にされちゃたまったもんじゃない。


ようは、訪問者が認識することなく訪問者の財産を一方的に利用(踏み台に)して金儲けしているということが一番の問題なのです。
こんなの禁止の方向へ進むのが当然でしょう。





2018年6月12日火曜日

MySQLとVIEWとオプティマイザと速度

MySQLでは、VIEWを使うと重いと言う人が多いと思います。
ざっとブログを検索した印象ですけど。

結論から言うと、別にVIEWが重いわけではありません。
使おうが使いまいが、INDEXがちゃんと使われていなければ重い、ただそれだけです。

ようするに、使う側の問題です。
知識なしに使えば重くなる場合もあるという事です。

MySQLでは、2種類のVIEWが存在します。
マージ方式と、テンポラリテーブル方式です。
前者は、ただのクエリエイリアスであり、実行する際にクエリを展開します。
後者は事前にテーブルを作成して使います。後者はあまり使うことは無いので省略します。

前者はVIEWを使っても速くならないと思っている人も少なくない感じがします。
同じか少し重いという記事をいくつか目にしました。
しかし実際は、劇的に速くなることもあれば、劇的に重くなることもあります。
全ては使い方次第です。

クエリが同じはずなのに何故速度が異なるのかは、オプティマイザの働き方が若干違う場合があるということだと思います。

EXPLAIN をしてみれば、何が違うのか一目でわかります。
なので、速い方と同じ順番になるよう強制してあげれば、同じ速度になります。

連結順序が違う場合は、STRAIGHT_JOIN を使って、順序を強制しましょう。