次のうちSQLインジェクションの対策として正しいものはどれか。

ア: ユーザーの入力した文字列が、データベースへの問い合わせや操作において、意味のある文字列として解釈されないようにする。
イ: ユーザーの入力した文字列にHTML タグが含まれていたら、HTML タグとして解釈されない別の文字列に置き換える。
ウ: ユーザーの入力に、上位のディレクトリを指定する文字列（../）が含まれていた場合、入力を受け付けないようにする。
エ: ユーザーの入力の長さが制限を超えているときは入力を受け付けない。

こんな基本情報試験レベルの知識がない奴雇いたいと思うのは底辺企業だけだよ。

Permalink | 記事への反応(1) | 13:10

■未経験 から1ヶ月でWeb系企業に就職する勉強法

取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。

重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。

逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。

基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。

以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。

経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。

特定の言語やフレームワークの書き方を知っていること自体に意味は無い。

重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。

① PythonとJavaScriptをマスターする

この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。

プログラミング言語は完璧に理解する必要がある。

基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。

言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。

また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。

② Gitの基本操作を覚える

Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、

リポジトリを作成する
.gitignoreを記述する
リポジトリをクローンする
ブランチを作成する
変更をコミットする
ブランチをマージする

等の基本的なフローは必ずできなければならない。

https://git-scm.com/book/ja/v2

③ Linuxの基本操作を覚える

多くの場合、本番環境やテスト環境はLinux サーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。

ファイルやパーミッション、ユーザーやプロセスのような基本概念を理解する
grepやfindやxargsなどのコマンドを組み合わせて簡単な処理を自動化する
IPアドレスを調べたり、SSHでリモートマシンにログインする

④ Dockerの基本操作を覚える

環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。

これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。

https://docs.docker.com/

⑤ Flaskを覚える

Flaskは、数あるWeb フレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。

フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。

データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。

作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。

https://flask.palletsprojects.com/en/2.0.x/

追記 2021/06/17 14:07

ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。

SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）

参考: https://devcenter.heroku.com/ja/articles/sqlite3

ありがとうございます。

⑥ Vue.jsを覚える

今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。

2021年現在、実用的なフロントエンドのフレームワークはReactとVue しかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。

フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。

https://jp.vuejs.org/index.html

⑦ 基本的なアルゴリズムを学ぶ

アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。

高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。

それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。

また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。

⑧ セキュリティを学ぶ

セキュリティは言うまでもなく学ばなければならない。

有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。

各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。

認証やパスワード管理などを実装する際は、当然ベストプラクティスに従わなければならない。

Permalink | 記事への反応(39) | 07:52

2021-05-20

■anond:20210519214122 政府向けシステムの話をするときの前提知識

政府向けシステムに関わったことがある身からすると、政府向けシステムの話をするときに前提として知っておいてほしいことは、住基ネット最高裁判決に「現行法上，本人確認情報の提供が認められている行政事務において取り扱われる個人情報を一元的に管理することができる機関又は主体は存在しない」という骨子があること。これによって政府向けシステムは個人情報を一元的に管理できず、個人情報は各自治体で分散管理しかできない。この文面でググれば政府がどれだけこの骨子を気にしているかは分かると思う。

今回の話は「国民マスターテーブルを持たずに認証するにはどうすべきか」という政府向けシステムで常に挙がる課題で、良いアイデアがある人は政府に提案しにいってほしい。個人情報保護法の目的外利用に違反しない上で。

はがき送りつけ

これをできるのは自治体のみで防衛省はできない。防衛省は国民の住所氏名を知らないのではがきを送れない。防衛省に限らず、どの省庁も国民の住所氏名を一元的には知らないので、政府はできない。

自治体 から発行済接種番号と生年月日のペアのデータ 提供を受けて、接種番号をIDとし、生年月日を仮パスワードとして登録し、認証 システムとする。

かなり難しい。上の骨子により防衛省が個人情報を一元的に管理することができないので、最高裁判決とは条件が異なることを主張しないといけない。たとえば「都市圏だけなので一元ではない」とか。それに国民や野党が納得するかどうか。これがひろみちゅの言う「政治的にそう言えないというのはあり得るが、乗り越えなければならない」課題。

来る者拒まずベストエフォート 方式にする

これで良いなら予約システムなんていらないけど、密を作って高齢者に何日も前から徹夜で並ばせるのが今のシステムより良いと思う？

どうすればよかったのか？

政府が使える一元的な情報はマイナンバーしかない。マイナンバーカードを読み取れる人だけが利用できる予約システムなら認証できるけど、自治体のネット予約さえ高齢者には使えないと叩かれているのに「マイナンバーカードとリーダーが必要です」なんて要件で作れるわけがない。そもそも「短期間に多くの人に接種させる」という目的にもそぐわない。

各自治体の予約システムがAPIを持って防衛省が接種券番号の有効性をAPIで確認できれば認証できるけど、首都圏だけで200以上ある自治体がばらばらに調達しているすべての予約システムに高負荷でも落ちないAPIを共通仕様で緊急で作らせれる必要がある。けど、そんな体力があるならば自治体の予約システム自体が落ちないようにすれば良いわけで、大規模接種自体が不要かもしれない。

個人情報を一元的に管理することができる機関を立法すればできる。けど、そんなものは「たった1年」じゃ作れない。マイナンバーと住基ネットに何年掛かったと思っている？「パンデミックという緊急事態なので防衛省が高齢者の個人情報を一元的に管理することができる」世界は「戦争という緊急事態なので防衛省が20代30代男性の個人情報を一元的に管理することができる」世界につながっていることを理解した上で、国民はこの法案に賛成できるのか？　できるなら、良くも悪くも政府向けシステムの将来は大きく変わる。

結局、「国民に行政サービスを直接提供するのは自治体で、そのための個人情報を持っているのも自治体。政府は自治体を支援する」というデザインですべてが作られている日本において、菅の「政府主導でのワクチン接種」というアイデアの実現がそもそも無理ゲー。出生届や転入届を出すのは各自治体、運転免許の番号を発行しているのは各都道府県公安委員会。政府は国民の個人情報が一元的に入った共通データベースをどこにも持っていないから管理できない。従来通り、政府は自治体の支援に特化するべきだった。

中国みたいな管理国家に日本はならないという選択を国民がした時点で、この予約システムでの認証の実装の難易度は相当高い。ウイルスとの戦いに強い国は戦争にも強い国で、「人間にせよウイルスにせよ、敵との戦いに勝つために国民は政府にどれだけ一元管理されてもよいか」の総意を国民が取らないといけないので、マイナンバーや住基ネットの実績を考えると1年くらいの準備期間じゃ、みんなが期待している認証をこのシステムでは実現できない。

認証は無理としてチェックデジットくらいは入れられたのでは？

チェックデジットがないことで誰かの誤入力で自分の予約ができない確率が上がっているのは残念。ただ、発券しているのは各自治体なのでチェックデジットをつけられるのも各自治体なので、開発会社も防衛省もやれることはない。誰なら事前に自治体に統一仕様で作らせられたかというと厚労省だけど、接種券の仕様が決まったあとに大規模接種の話が出てきたので事後諸葛亮。こんなこともあろうかとチェックデジットの指摘が事前にできる勘が良い人がいたなら、たぶん落ちない予約システムの作り方の指摘も事前にできただろうから、大規模接種自体が不要だったかもしれない。

いたずら予約で枠を全部押さえられたらどうするの？

現状でもreCAPTCHAでBot 対策されている。reCAPTCHAを越えて大量予約するやつは悪意があるので逮捕で良いでしょ。

接種券番号のバリデーションは無理として、市区町村 コードのバリデーションはできたのでは？

できた。でも、接種券番号のバリデーションができない時点で大した意味はない。入力フォームの電話番号にSMS送って電話番号全体の有効性を確認することはあっても、市外局番の存在有無だけをバリデーションするなんてことしないでしょ。入力された市外局番と市外局番マスターを引きあててバリデーションをしている者だけが石を投げられる。

生年月日が65歳未満でも登録できるのはバリデーションすべきでは？

防衛省は生年月日の正しい情報を持っていないので、この数字に大した意味はない。たぶん予約キャンセル用のパスワード相当、当日の誤入力を見つけるためのヒントくらいの意味しかない。「パスワードを設定してください」でも良かったんだけど、高齢者には難易度が高いと思って生年月日にしたんだろう。秘密の質問みたいなもの。あなたの母親の旧姓が本当に正しいかどうかにシステム側は興味がないのと同じくらい、この生年月日が正しいかどうかに大規模接種予約システムは興味がない。

SQLインジェクションは？

いまだに具体例が出てこないので、多分ガセ

接種券番号だけが ユニークになっている

異なる市町村番号＋同じ接種券番号＋異なる生年月日でログインできないことで接種券番号だけがユニークと主張しているけど、ログインできない理由はそれだけじゃない。たとえば2-123,5678がすでに登録されていることをこの人は知らない状況で、この人は1-123,1234でログインできるけど、2-123,7890はログインできない。システムとしておかしくない。

追記（2021/05/21 2:45）

よくあるコメントに返信。

接種番号と生年月日は個人情報ではない

法律は素人のシステム屋なので、この指摘は正しいのかもしれない。一方で「個人情報とは個人を一意に識別できる情報のことを指すもの」というコメントもある。私には判断できないけど、仮に個人情報ではないとすると、

かなり難しい。上の骨子により防衛省が個人情報を一元的に管理することができないので、最高裁判決とは条件が異なることを主張しないといけない。たとえば「接種券番号は個人情報ではない」とか「都市圏だけなので一元ではない」とか。それに国民や野党が納得するかどうか。これがひろみちゅの言う「政治的に（『接種券番号と生年月日は個人情報ではないので一元管理します』とは）言えないというのはあり得るが、乗り越えなければならない」課題。

が正しいのかもしれない。住基ネット最高裁判決によって政府向けシステムに認証機能をつけることは想像以上に難しいという趣旨は変わらないけど、悪いのは菅じゃなくて「個人情報ではない」で突っ張れなかった防衛省なのかもね。いずれにせよ「認証すらまともに作れない技術力」から「接種券番号は個人情報なのか」に議論が高まってくれれば書いた甲斐があった。

VRSでは一元管理できている

VRSってのは各自治体の接種会場で使われているバーコードがなくてOCRが必要なことで有名なシステム。OCRは置いておいて、VRSは一元管理していない。 https://cio.go.jp/sites/default/files/uploads/documents/vrs_overview_210506.pdf の6ページ目に書いてある。

＞市区町村ごとに区切られて保存されており、個人の記録は、接種券を発行した市区町村が確認できます

国民の接種率が重要指標なんだから DBは1個にしたほうが便利なのに、「あえて」区切って保存している。また、個人の記録は各市区町村しか確認できい、つまり串刺しで全国民の個人記録を見られる人はいないと書いてある。そんなわけでVRSは「政府は一元管理していません」に気を使っていることが分かる事例。

Permalink | 記事への反応(31) | 17:57

■防衛省のワクチン予約システムの何が問題なのか

◾️海外からサイバー攻撃されたらどうする

ソース見たらわかるけどリキャプチャ入ってるよ。

スクリプト組んで乱数で大量に空予約を登録なんてことはできなくなってる。

◾️存在しない番号が入力できる

悪質なのは偽計業務妨害罪になるからそれで抑止。

◾️2月30日や未来の生年月日が入力できる

受付で本人確認する。（接種券と免許証等）

例えば3月30日生まれの人が間違えて2月30日を入力していたとしても、受付で人が判断してそのまま接種させればいい。

◾️メルカリで転売される

受付で本人確認する。

上記のように3月30日生まれの人が間違えて2月30日になるくらいならそのまま受け付ければいいが、あまりにも入力内容と本人の属性が異なってたら、見たらわかるだろ。

◾️予約済み番号が二度入る

誤入力で他人の予約を意図せず上書きしてしまうというのは起こり得る。

これは問題だから、予約者に予約完了メールを送るようにシステムを修正するべきかもしれない。

1%の人間が誤入力でシステム上の予約日と違う日に来ても、1万人が１万100人になるレベルだから、受付で予約完了メールが確認できれば、そのまま接種させればいい。

ここだけは改善点として挙げられる。

◾️SQLインジェクションできる

twitterで噂になってるから探したけどソースが見つからないんだよね。デマじゃないの？

金融機関のシステムでもないのに、本人確認などかっちりシステム作って、稼働は1ヶ月後ですってなったら、その間にワクチン打てた30万回が遅れることになる。

個人的にはそれって誰得なんだよって思うけど。

Permalink | 記事への反応(3) | 14:17

2021-05-19

■バグと脆弱性(セキュリティホール)の線引

ワクチン大規模接種東京センターの予約システムで発生した、適当な数字を入力しても予約できるシステムの不備はバグなのか脆弱性(セキュリティホール)なのかを考えていこう。

もし、脆弱性であるとするならば、しかるべき報告フローを取る必要があるからだ。

記事の末尾に参考リンクをいろいろおいておいたので、詳細は確認してほしい。

この問題は、本来するべきチェック処理をしていないのだから、バグの一種といえる。

// ただ、改善する気がないのなら仕様となるのだろうけどね。

あるゆる、脆弱性はバグの結果起きる。

では、適当な数字を入れても予約できちゃうバグは、脆弱性(セキュリティホール)と言えるのか？

もし、脆弱性(セキュリティホール)となるなら、ゼロディでいきなり公開する前に、しかるべき報告フローを取るべきだ。

// ただ、新聞社は、ネットで噂になったものを取材して報道しただけであるから、ゼロディで公開とは言えないだろうけどな。

個人的な意見としては、脆弱性とまでは言えないと思う。

これはタダのバグであって、脆弱性(セキュリティホール)と呼ぶのは言い過ぎだろう。

例えば、教科書レベルの「"＜script＞alert("XSS");＜/script＞」でXSSを発生させる意図的な入力をして、誤動作が発生するなら、それは間違いなく脆弱性(セキュリティホール)といえる。

同様に、SQLインジェクションを発生させる意図的な入力をして、何か変なことが起きれば、これも間違いなく脆弱性といえる。

他にも、超でかいデータを送りつけてバッファオーバーフローさせたり、特殊な入力をしてスタックを破壊して戻り値を改ざんして任意のコマンドを実行するみたいなものも同様に脆弱性と呼んでもいいだろう。

(注:念のために書いておくが、不正アクセスで違法になる可能性があるので、自分の所有するサイトやコンピュータ以外へは、これらの入力を試さないように。)

でも、ごく普通の入力をしても、エラーとしてはじかないで受け入れてしまうのは、脆弱性ではなく、タダのバグであるように思う。

「こういう操作したら、計算結果が変になった」はバグの領域であって、脆弱性とまでは言えない。

今までの話を簡単に言うとしたら、ドラクエ4で8回逃げたら会心の一撃が連続して出るのはバグなのか脆弱性なのか？って話になるのかな。

確かに、8回逃げることで、データのバッファオーバーフローが発生して、そのような結果になる。

でも、8回逃げるというはやろうと思えは誰でもできる動作であって、これをバグではなく脆弱性(セキュリティホール)と呼ぶのは違和感がある。

この裏技を見つけたとして、脆弱性としてしかるべき報告フローを取らずに公開したことを咎められるとしたら、実に変な話である。

これら裏技を試しても不正アクセスと言われて、罪を着せられたり、裏技の記事を削除されるとしたら、強烈な違和感がある。

このあたりのバグと脆弱性の線引はどうなっているのか。

今回の事件で、それが一番気になった。

最終的には、裁判で裁判所が決めることになるんだろうけど、あまりアホな判決を出して、日本のエンジニアの手足を拘束しないでほしいと思う。

参考URL:

■ドラクエ４で「にげる」８回でずっと会心の一撃になるバグ、こういう仕組みで起こってたらしい

https://b.hatena.ne.jp/entry/s/togetter.com/li/1715732

■「誰でも何度でも予約可能」ワクチン大規模接種東京センターの予約システムに重大欠陥

https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html

■岸信夫 on Twitter: "自衛隊大規模接種センター予約の報道について。...

https://b.hatena.ne.jp/entry/s/twitter.com/KishiNobuo/status/1394440062125805572

■脆弱性の手口、IPA「見つけたらまず開発者やIPA窓口に報告して」　コロナワクチンの架空予約巡り

https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2105/18/news145.html

■Hiromitsu Takagi on Twitter: "私はこの届出制度の提唱者・設計者・運用協力者・有識者研究会委員であり、IPAの広報が取材にこんな回答をしたのであれば、出鱈目であり、...

https://b.hatena.ne.jp/entry/s/twitter.com/HiromitsuTakagi/status/1394713619212816385

■ワクチン大規模接種「架空ウェブ予約」やったら犯罪？　国は「法的手段」に言及

https://b.hatena.ne.jp/entry/s/www.bengo4.com/c_23/n_13071/

■確認作業は公益性高い、毎日新聞　接種センター架空入力は取材目的

https://b.hatena.ne.jp/entry/s/this.kiji.is/767285347672670208

■AERA dot. 記事への防衛省の申し入れに対する見解

https://b.hatena.ne.jp/entry/s/dot.asahi.com/info/2021051900065.html

Permalink | 記事への反応(7) | 06:14

■[増田統計]2021年 5月18日 火曜日の増田

時間	記事数	文字数	文字数平均	文字数中央値
00	109	14551	133.5	57
01	83	10345	124.6	43
02	34	5286	155.5	76
03	39	4085	104.7	46
04	63	5246	83.3	68
05	80	4931	61.6	46
06	19	3223	169.6	49
07	60	9865	164.4	49.5
08	77	7429	96.5	26
09	191	14529	76.1	39
10	194	14211	73.3	43.5
11	186	16662	89.6	45
12	166	15917	95.9	37
13	135	8173	60.5	33
14	199	13742	69.1	34
15	167	14155	84.8	38
16	176	15285	86.8	36.5
17	192	15347	79.9	36.5
18	126	13863	110.0	41
19	142	17051	120.1	30
20	175	13820	79.0	33
21	134	9048	67.5	23.5
22	94	12778	135.9	44
23	120	19235	160.3	54.5
1日	2961	278777	94.1	39

本日の急増単語 ()内の数字は単語が含まれる記事数

SQLインジェクション(8), 新安(4), 保法(4), 水からの伝言(4), ひろみちゅ(22), セックル(3), 高木先生(3), 徳丸(4), カイドウ(4), usagi(5), ガザ地区(3), ベーシックインカム(25), 接種(53), 予約(64), 文法(11), 飼う(11), 所得税(11), 番号(20), ひろゆき(12), 処女(26), ワクチン(93), 学術(16), 権威(13), システム(96), 共産党(17), 大規模(15), ウマ娘(24), マスコミ(22), 弱者男性(72), IT(36), 科学(19), 救わ(20), 政府(60)

頻出トラックバック先 ()内の数字は被トラックバック 件数

■みんなやってるけど公には言わないグレーな行為 /20210518100156(75), ■葬式シーンで雨が降ってるとムカつく病 /20210517 205623(25), ■マジでいいところまで書いてて死んでしまった作家 /20210518144014(20), ■中国韓国との競争に敗れ衰退が続く日本の造船業について /20210518071533(18), ■ワクチン予約のクソシステムについての私見 /20210517 20 1151(16), ■5大、終わらせる気がなさそうなダラダラ漫画 /2021051811 1230(16), ■彼女の実家と家族がドカタであることが判明してショックだった /20210518195105(14), ■母がハマってきたものと最近のトレンド /20210518063647(14), ■まじめな話、男のどのくらいが処女厨なん？ /2021051811 2052(13), ■弱者男性に１番厳しい属性ってフェミ男性なんだな /20210517 20 1726(13), ■科学リテラシーって要するに権威主義って認識であってる？ /20210516225443(11), ■本当の「弱者男性の丁寧な生活」 /20210517213621(11), ■スピリチュアルにハマる母についての考察 /20210518113034(11), ■疲れたから聞いてくれ /20210518140340(9), ■ワクチン予約のシステム、納期ありきのクソプロジェクトあるあるすぎ /20210517 234543(9), ■結局なぜ満員電車で大規模感染が引き起こされなかったのかの答えは出ていない /20210517 170136(9), ■出先上司「増田くん平成産まれだから円周率は3なんでしょ」 /20210518105636(9), ■有明アリーナが電通に1/5の価格で譲渡される件のカラクリ /20210517222926(9), ■孫子は巧遅より拙速なんていってない /20210518113524(8), ■anond：20210518160647 /20210518161458(8)

Permalink | 記事への反応(0) | 00:04

2021-05-18

■もし、あなたがワクチン予約のサイトで脆弱性を発見してしまったら

やるべきことはひとつです。

IPAの「脆弱性関連情報の届出受付」に届け出ましょう！

脆弱性情報を適切に共有するために

https://www.npa.go.jp/cyber/kanminboard/siryou/sec_hole/partnership.html

間違っても、5chに「SQLインジェクションできる」などと書き込んだり、個人のブログで脆弱性をつく手口を公開したりすべきではありません。

また、それらの情報を粗雑な粒度でまとめたツイートやまとめサイト記事などの拡散に協力すべきでもありません。

上記の行為は、法的責任に問われる可能性があるだけでなく、当該サイトを攻撃のリスクに晒す行為でもあります。

もちろん、日々圏論やデータ分析の記事をブクマし、技術力の向上に努める技術寄りのはてな民が情報セキュリティ教育の基礎の基礎をすっ飛ばしているとは思いませんので、釈迦に説法とは思いますが、一応のリマインドとして置いておきます。

Permalink | 記事への反応(1) | 16:57

■anond:20210518154151

フレームワークの偽装サイトをつくって

街のあるSQL入のフレームワークを上げておいて

クリック詐欺でダウンロードさせて

すり替えるのもSQLインジェクション

フレームワークを狙う方法もある。DNS 偽装を使うと、ほぼあらゆるフレームワークがインジェクション

DNSインジェクション　こんなもの署名検証で一撃だけど　署名検証しないAutoUpdateがどんだけあると思ってんだと

そして、じゃぁ署名検証をすれば

偽装署名インジェクション

極基本的なプログラマが気をつけるレベルでこれ

セキュリティー担当だともっとうるさいが、そこが面白い話がある

おれたちプログラマーが、銀座で口が軽くなるの法則知ってる？酔っ払うとどうしてもな

コカ・コーラおいしいよな（つたわれ日本語）　　しーよな　おい４７ぁ　伝わる俺たちの暗号

Permalink | 記事への反応(0) | 15:48

■anond:20210518152433

＞付け加えると、更新系処理のSQLインジェクションを「安全に」確認することも難しいです。試している人は「正義のため」という意識でやっているかもしれませんが、本番データ壊したら「正義」どころではないですからね

https://twitter.com/ockeghem/status/1394464099405160450

Permalink | 記事への反応(2) | 15:32

■大規模接種予約システム、開発元は仕様通りの代物を納品しただけだろ

本来なら各自治体が作成した優先接種対象者の情報（マイナンバー、接種券番号、氏名、生年月日）を大規模予約システムに集約し照合をかけるべきだった。

しかしなあ、優先接種対象者の連携仕様ができたのいつだと思う？ついこの間の4月だよ。

ベンダー側のプログラム入替が完了してなくて未対応の自治体がほとんどだよ。

防衛省の仕様段階で照合なしの予約システムだったのは確定だろう。

存在しない生年月日と自治体コードくらいはバリデーションすべきだとは思うが、

リリース前に開発元がやれたことといったらそのくらいしかない。

あとSQLインジェクションの噂があるが、本当であれば速やかに IPAなり開発元なり防衛省なりに通知すべきことで、噂だけ広めていいことじゃないだろう。

事実ではなかった場合は、例え噂を広めただけでも名誉棄損に問われる可能性もあるわけで、みなさん言動には慎重になろうよ。

Permalink | 記事への反応(1) | 13:50

■日本人ってほんとクソだな。

ワクチン大規模接種東京センターの予約システムに重大欠陥

https://dot.asahi.com/dot/2021051700045.html

【悲報】防衛省のワクチン予約システム早速ネット民のおもちゃに「SQLインジェクションできる」「同じ番号入れるとその前の予約がキャンセル」

https://togetter.com/li/1716106

1年前から準備しとけ、とか、アプリの実装がクソとか、政府の対応にかなり問題があるのは解るけど、だからって、勝手に予約したり、遊びものにしていいもんじゃないだろ。

日本人の大好きな「人の揚げ足取り」してる状況か？

利用方法を注意喚起して、みんなで善意で回すのが、最善だろ。どう考えたって

ホントクソ

Permalink | 記事への反応(4) | 13:26

2021-05-17

■anond:20210517201151

この記事をめぐる話題について。システム的な側面よかもうちょい根っこの部分で噛み合ってない気がしてて。

これから数ヶ月でてんこ盛りで来るはずのワクチンをどう捌くかというのが論点のはずなのに、

「ワクチン一滴血の一滴！二重予約を許すな」的な論調がやたら強くない？という感じがする。

ワクチン契約状況は厚労省のプレスリリースによるとだいたいこんな感じで

令和３年１月 20 日
本日、厚生労働省は、米国ファイザー社の新型コロナウイルスワクチンについて、
日本での薬事承認等を前提に、年内に約１億 4,400 万回分の供給を受けることについ
て、ファイザー株式会社と契約等を締結しましたので、お知らせします。

https://www.mhlw.go.jp/content/10906000/000723852.pdf

( https://flyteam.jp/news/article/131928 の表はおそらくこの契約の一部分。５月には週1000万本ペースで5000万本の入荷予定との話だけど、河野大臣が以前出してたツイや厚労省の接種予定報告とおおむね整合性が取れてる)

令和２年 10 月 29 日
本日、厚生労働省は、米国モデルナ社及び武田薬品工業株式会社が新型コロナワク
チンの開発に成功した場合、武田薬品工業株式会社による国内での流通のもと、来年
上半期に 4,000 万回分（2,000 万人分）、来年第３四半期に 1,000 万回分（500 万人分）
の合計 5,000 万回分（2,500 万人分）の供給を受けることについて、両者と契約を締結
しましたので、お知らせします。

https://www.mhlw.go.jp/content/10906000/000723852.pdf

令和3年5月14日
本日、厚生労働省は、米国ファイザー社の新型コロナウイルスワクチンについて、本年第３四半期（７月～９月）に
約5,000 万回分の追加供給を受けることについて、ファイザー株式会社と契約を締結しましたので、お知らせします。

https://www.mhlw.go.jp/stf/newpage_18648.html

まとめると、今後数ヶ月で1億本分以上のワクチンが来る予定が立ってる(ほんとに予定通り来るかどうかは来てみないとわからないけど)。

まあ国内の各地自治体に分配する手間があるので、入荷したらすぐに射てるようになる訳ではないけれど。

で、おそらく件の「ワクチン予約のクソシステム」は、この直近数ヶ月で積み上がるであろう莫大な在庫（賞味期限があるし保存も面倒だし長時間停電とか発生したら責任問題で目もあてられないし一刻も早く減らしたい）をいかにハイペースで減らすかというのが大目標になってるはず。

と考えると、市町村の接種システムとの二重予約とかシステム内の多重予約をどうするかみたいな（システム的に解決しようとしたら外部連携でコストと時間がかかりそうだけど、運用で回避できそうな）話、二の次になってもしょうがないよな感がある。

なんというか、「ちゃんとした」システムは来年あたりの余裕が出来たときに改めて開発良いのでは？今必要なのは直近で業務を回せる「クソシステム」で。

まともなシステムでもクソシステムでも、どのみち会場で本人確認は取らないといけないし、イレギュラーな予約を会場で弾くのもまあありなんじゃね感。

「いやそれでもちゃんと事前に計画しとけよ」というのは正論では有るけど、上で貼った契約のうち三個目の7～９月に5000万回分入荷する話が公開されたの、ほんの数日前だかんね。

事前計画がきちんと固まってから動いてたら間に合わない。

あと一応貼っとくけど、世界に冠たるIT 先進国なアメリカのワクチン接種管理、こんな感じのゆるゆるシステムなので。

https://jp.wsj.com/articles/covid-19-vaccination-cards-are-the-only-proof-of-shots-soon-an-essential-11617162748

これでも仕組みは回る。「とにかく接種数を稼ぐ」という目標を関係者全員で共有できれば…だけど。

追記:

現状が理想と言いたいわけじゃなく、ここ数ヶ月から半年ぐらいの土壇場を乗り切るために突貫工事もやむを得ないし、必要に迫られてる突貫工事に対して「ちゃんとやれ」というのはあんま意味ないよねという話。（「ちゃんと」やった結果としてスケジュールが遅れたら洒落にならないので）

まあ、流石にSQLインジェクションであれこれ的な話が本当なら要改修だと思うけど。

Permalink | 記事への反応(1) | 23:10

■ワクチン予約のクソシステムについての私見

5/18 追記

色々情報が出てきたので答え合わせ。

前提として、

接種番号は自治体が発番する。そのため、このシステムは、入力された接種番号が正しく存在する番号かどうかさえ確認するすべはない（形式的に間違っている番号はわかる）。
接種番号は自治体が発番するため、接種番号と接種者の情報を紐付けられるのは自治体のみ。接種番号に対応する郵便番号や生年月日も、このシステムはわからない。
接種券は、このシステムが開発着手する前から印刷されていた。チェックディジットやハッシュは、その時点で接種番号の仕様に含まれていなかった。
大規模接種会場の予約システムなんて話が裏で進められ始めたのが今年の1月。接種券の印刷・送付の通達が出たのは去年の12月。

　その通達では、券番号として、自治体内で一意であることしか定められていなかった。

このシステム、ひいては大規模接種の目的は、早期にワクチン接種を完了させること。

　したがって早期にシステムが稼働していることが求められ、期間的に全国2000ある自治体のシステムと連携させるとか、自治体にデータ入力させるとかいった手立てはとれない。

　また、本システム側から発番済みの番号がわからない以上、仮パスワードを登録すること自体が困難。

システム設計レイヤーの問題と、実装レイヤーの問題があって、その2つは分けて考えないといけない。

実装 レイヤーの問題

SQLインジェクション可能とか、無茶苦茶な生年月日を登録できるとか。

これらはシステム会社の責任。

特に SQLインジェクション可能が事実なら論外で、自治体と連携させなくてむしろよかったなぁという感想。

でも、5chのデマらしいけど。

システム 設計 レイヤーの問題

誰でも予約可能みたいなのは、このシステム会社からはどうしようもなかった。

生年月日を仮パスワードにして〜は、自治体だけができること。

むしろ全国横断のシステムにするのではなく、パッケージにして、自治体に配布するほうが良かったんではと思うが、それはそれで、自治体側に運用コストが発生するし、結局データを自治体側に入力させることになるし、早期の稼働には間に合わなかっただろう。

結論

本システムには、開発会社に起因する、稚拙な不具合が含まれている一方で、認証まわりの誰でもログイン問題は、開発会社の責任ではない。

去年の早い時期、ワクチン交渉の段階で、官邸や厚労省はすでに設計を開始しておくべきだった。

「誰でも予約」の問題は、直接には官邸の思いつきの大規模接種のブッコミが原因だけど、そもそも大規模接種や予約の問題は、厚労省が接種番号の仕様設計の段階で考慮しておくべきことだった。QRコードもな。

おまけ（どうすればよかったの？）

「この日に来てください、嫌なら希望の日の当日整理券を受け取って、別レーンに並んでください、接種券と本人確認書類を持ってきてね」ってはがきを送りつければよかった。

追記ここまで

=============

この件ね

https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html

いや俺も、最初はこの会社クソやなと思ったんだけどさ。冷静に考えると、取れる手立ては少ないんでは。

このシステム、まともに作るなら、ワクチン接種番号の他に仮パスワードをつけてログインさせ、初回ログイン時にパスワード変更させるかたちになるだろう。

年寄りにそれができると思えないし、問い合わせは今の10倍以上くるだろう。

それに、日本中からアクセスしても落ちない認証システムを、このためだけに急遽立てろというのは酷だよ。

認証させないなら、それはそれで他人の番号で勝手に予約して、本人に摂取させない嫌がらせができてしまう。

そもそもワクチン接種券の仕様を決めたのは、竹中の会社じゃない。仮パスワード印刷をして各家庭に配布するのも、竹中の会社じゃむりだし、自衛隊側も嫌がるだろう。

詰んでんだよね。

そもそも番号と個人の紐づけ情報を参照できたのかも不明なんだけど。

なんか、システム会社を責める人も多いみたいだけど、それよりもっと以前、厚労省の段階から無計画だったんじゃねぇの。

Permalink | 記事への反応(38) | 20:11

「SQLインジェクション」を含む日記

■夏コミ(C100)一般参加申し込むか迷ってる

■SQLインジェクションと江戸橋ジャンクションって

■本のまとめ