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

はてなキーワード: SQLインジェクションとは

2021-06-25

32    風吹けば名無し@転載禁止 [sage]    2014/11/25(火) 04:07:46 ( tor-elpresidente.piraten-nds.de )

>>29

使えなくは無いけども当職は使わないナリ

kaliかtailsをCDに焼いた方が便利ですを。win系のパスクラならophcrackがオススメナリ

守り方だけど鯖建てたい初心者はhackmeで検索してSQLインジェクションXSS辺りの初歩を学ぶと良いナリ

バッファオーバフローアップデートと設定さえ、やっとけば0dayで無い限りやられることは無いと思うナリ

win系とかの簡易ウイルス発見テクは「タスクマネージャが出ない」「隠しフォルダ強制非表示になる」

サービススタートアップタスクスケジューラに不審exe登録してある」「USBを挿した時autorun.infを上書きしようとする」等々のパターンが多いナリ

とりあえず常駐プロセスサービスがどこの会社のどのソフト理解しておくことも早期発見に繋がるので大切ナリ

防御ソフトとしてはpeerblock、sandboxie、privoxy、EMET、DNSCrypt、comodo firewall辺りと適当ウイルス対策ソフトナリ

ブラウザfirefoxアドオンadblock edge、cookiesafe、noscript、prefbar辺りを入れてprefbarでプロキシとかflashとかjavaオンオフ管理すると良いナリ 

ラッキング下準備

まず、基本となるLAMP自鯖を作って出来る限りのセキュリティを施すナリ

これでLinux系鯖の基本くらいは理解できるようにならないと侵入してもやることが無いナリ

次はツールの使い方を覚えるためにKaliLinuxとかを使って何とかして自鯖セキュリティを破って侵入するか

自分SQLインジェクションとかXSSとか書いて侵入するナリ

なお、簡単に入れる鯖はセキュリティ意識低いので拾ってきたバックドアでも問題無いナリ(例えばrootパスデフォ設定の所とか)

ここまで来たら後は近所の無線をaircrack-ng等でカラッキングtor+tsocksかproxychains辺りを使って恒心するナリ 

2021-06-17

anond:20210617124810

いいわけねーだろ(笑)

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

ア: ユーザー入力した文字列が、データベースへの問い合わせや操作において、意味のある文字列として解釈されないようにする。

イ: ユーザー入力した文字列HTMLタグが含まれていたら、HTMLタグとして解釈されない別の文字列に置き換える。

ウ: ユーザー入力に、上位のディレクトリ指定する文字列(../)が含まれていた場合入力を受け付けないようにする。

エ: ユーザー入力の長さが制限を超えているとき入力を受け付けない。

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

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

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

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

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

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

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

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

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

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

PythonJavaScriptマスターする

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

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

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

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

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


Gitの基本操作を覚える

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

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


Linuxの基本操作を覚える

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


Dockerの基本操作を覚える

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

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


⑤ Flaskを覚える

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

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

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

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

追記 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の設定などは既存のものを流用すればいい。



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

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

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

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

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

セキュリティを学ぶ

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

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

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

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

2021-05-20

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

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

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

はがき送りつけ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現状でもreCAPTCHABot対策されている。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は「政府は一元管理していません」に気を使っていることが分かる事例。

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

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

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

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


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

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


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

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

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


◾️メルカリ転売される

受付で本人確認する。

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


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

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

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

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

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


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

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


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

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

2021-05-19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考URL:

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

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

[]2021年5月18日火曜日増田

時間記事文字数文字数平均文字数中央値
0010914551133.557
018310345124.643
02345286155.576
03394085104.746
0463524683.368
0580493161.646
06193223169.649
07609865164.449.5
0877742996.526
091911452976.139
101941421173.343.5
111861666289.645
121661591795.937
13135817360.533
141991374269.134
151671415584.838
161761528586.836.5
171921534779.936.5
1812613863110.041
1914217051120.130
201751382079.033
21134904867.523.5
229412778135.944
2312019235160.354.5
1日296127877794.139

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

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

2021-05-18

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

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

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

脆弱性関連情報の届出受付

https://www.ipa.go.jp/security/vuln/report/

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

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

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

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

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

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

anond:20210518154151

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

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

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

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

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

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

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

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

 

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

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

 

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

コカ・コーラおいしいよな(つたわれ日本語)  しーよな おい47ぁ 伝わる俺たちの暗号

anond:20210518152433

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://togetter.com/li/1716106

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

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

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

ホントクソ

2021-05-17

anond:20210517201151

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

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

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

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

令和3年1月 20

本日厚生労働省は、米国ファイザー社の新型コロナウイルスワクチンについて、

日本での薬事承認等を前提に、年内に約1億 4,400 万回分の供給を受けることについ

て、ファイザー株式会社契約等を締結しましたので、お知らせします。

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

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

令和2年 10 月 29 日

本日厚生労働省は、米国モデルナ社及び武田薬品工業株式会社が新型コロナワク

チンの開発に成功した場合武田薬品工業株式会社による国内での流通のもと、来年

上半期に 4,000 万回分(2,000 万人分)、来年第3四半期に 1,000 万回分(500 万人分)

の合計 5,000 万回分(2,500 万人分)の供給を受けることについて、両者と契約を締結

しましたので、お知らせします。

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

令和3年5月14日

本日厚生労働省は、米国ファイザー社の新型コロナウイルスワクチンについて、本年第3四半期(7月~9月)に

約5,000 万回分の追加供給を受けることについて、ファイザー株式会社契約を締結しましたので、お知らせします。

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

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

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

 

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

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

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

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

 

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

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

 

 

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

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

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

追記:

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

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

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

5/18 追記

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

前提として、

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

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

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

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

実装レイヤー問題

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

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

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

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

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

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

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

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

結論

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

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

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

おまけ(どうすればよかったの?)

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

追記ここまで

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

この件ね

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

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

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

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

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

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

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

詰んでんだよね。

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

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

2020-12-27

anond:20201227124846

というかSQLインジェクションとかは、普通そもそも文字列の足し算すら使わないで、”から”までを”こみで抜き出して 足せとか たとえば 書いておくと どうやっても文字列しかならない

足し算する前に1文字から ラスト-1文字目を足せとかいておく とかな

わかりやすくかくと こうだけど ならないように もともとできてんだよ

からおっしゃるとおり ちんぴらが わざとやらないと そうならない そりゃそうですよねぇとおもった ってこと

から”までだから 自分で”をたすと そこまでしか抜き出されないで 残りを捨てる

2020-10-03

anond:20201002023509

Webエンジニア技術確認って、知識経験が多方面に渡るから難しいと思ってる。

まあWebエンジニアだけじゃないだろうけど。

Webアプリ作れます!と言って完成物だけを見るとたしかにそれなりのができてる。

でもコントローラに全てのロジックが書かれてる。

もちろんテストはない。動けばいい。

N+1SQLインジェクションが埋め込まれてる(後者フレームワーク側でほぼ無いが)。

APIフロントに渡すデータの中に個人情報が含まれている。

Gitは漢のmaster(main)一本だし、rebaseはできない。何かgitでトラブったら全消ししてcloneし直す。

デプロイHerokuコマンドをよく分からず打ち込んでるだけ。ちょっと凝ったことはできない。

データベースも大きなExcel程度と考えていて、一つのテーブルに全部のデータを入れる漢のスキーマ

コマンドも例えばgrepやfindを使えない。XXenvの使い方がわからない。何でもかんでもsudoをつける。

環境変数がどういうものであるか分からない。

エディタコードジャンプができない。

vimが使えないからなんかのはずみでvimの画面になったらパニックになる。

まだまだいろいろあるけど挙げたらきりがない。

これを1時間やそこらの面接判断するのは不可能でしょ。

となるとどこかで線引きをしなければいけないけど、その線引きの一つの手段が対面での会話の内容、受け答えの態度だと思う。

上っ面の知識でも話が上手ければ(そして意識高ければなおさら)、いくらでも「できる人」を見せることができる。

まあ結論としては採用戦略は大切だなということ。

2020-08-11

anond:20200811190716

そういう意味ではSQLインジェクションというが、あれはデータをインジェクションするもの

本来は、異なる。たまたまソースコード実行型のインタプリタからそう感じるだけ。

地デジなんて、コピー禁止回路を迂回するためにジャンパ切れとかよくあるじゃん

2020-07-15

いいよいいよ

「つまりユーザ入力をそのままどこかに出力したら駄目なんだな」

ってことをわかってくれてればいいんだ

SQLインジェクションクロスサイトスクリプティングを取り違えてたっていいよ

SQLインジェクション

でき んだろ

うそいうな。

関数を単純コピペで10000行にしてやるっ

2020-04-03

[]2020年3月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

254あとで/2503users 総説 新型コロナウイルス感染症(COVID-19)|中外医学社Online|note

204あとで/1478users 上手な「在宅勤務」のコツ | Google Cloud Blog

165あとで/2268users 「先生オメガを倒したら宿題やってきてやるよ」と生徒が言ったので、わたしゲームライターになった|Yuka S.|note

145あとで/706users さくらPythonの基礎講座を無償提供 新型コロナで外出控える人向け - ITmedia NEWS

142あとで/1433users アルゴリズムビジュアル大事

137あとで/731users 【翻訳コードは書けないけど、1人で作ったwebサービス収益化した話 - Qiita

131あとで/2848users 100日間おなじ商品を買い続けることでコンビニ店からあだ名をつけられるか。|yosano|note

130あとで/624users 普通プログラマーAWSゼロから勉強するためにやったことと現在勉強方法 | Developers.IO

129あとで/676users systemd エッセンシャル

129あとで/746users Wikipedia特に人物記事と言うのは簡潔な表記なのに長編小説を読んだかのように強烈な印象を与えるものが多い。 - Togetter

127あとで/926users 家で暇をつぶせるサイト10個ほど紹介する:哲学ニュースnwk

120あとで/2055users 高校レベル数学から大学教養数学くらいまでを学び直した - razokulover publog

119あとで/774users 実は便利な「Google Keep」、その使い道は? 電話取次メモを同僚と共有、写真からの“文字起こし”にも ~小ワザ集<1>【「G Suite」時短コラボ仕事術】 - INTERNET Watch

114あとで/605users 社内で好評だったSQLインジェクション資料を公開します – Webセキュリティの小部屋

113あとで/902users スタートアップ組織設計図の5類型と、その失敗率 | Coral Capital

110あとで/845users 現代ウェブフロントエンドウェブアプリケーション)について理解する唯一の方法|erukiti|note

106あとで/973users 話が上手な人と下手な人の違い | knowledge / baigie

103あとで/615users イミュータブルデーモデル - kawasima

102あとで/1194users ゴミ屋敷父親が腐って死んでた上に仕事も失ったけど最終的に何とかなった話|麻宮ミヤネ|note

101あとで/513users エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog

97あとで/499users The History of the URL | The Cloudflare Blog

97あとで/523users 今からVue.jsを始める人のための「知るのを後回しにしてよい」n個のこと - Qiita

97あとで/1087users 男子校出身の18歳に鴻上尚史が教えた「絶対に選んではいけないサークルバイト」とは? (1/4) 〈dot.〉|AERA dot. (アエラドット)

97あとで/2505users 24暮らしてきたイタリアが、大変なことになっている。

96あとで/1494users 全国一斉休校を受け無償提供されたオンラインサービスをまとめてみた - piyolog

93あとで/852users 米グーグルテレワークVPNを使わない、なぜなら「あれ」が危険から | 日経クロステック(xTECH)

93あとで/1880users よく心理戦で「相手は私の思考を読んでこうするから、それに対し私はこうする」みたいな読み合いがありますが、ずっと互いに読み合っていたら無限ループで切りが無いはずです。どこまで読むのが正解なのですか?に対するMasahiro Sekiguchiさんの回答 - Quora

92あとで/488users 0から始めるNode.jsパフォーマンスチューニング | kohsweblog

91あとで/513users エンジニアとして影響を受けた技術書ランキング2020年

90あとで/628users UIの細かい動きについて | ゲームUI演出

90あとで/661users そうだ、任天堂宮本茂さんに聞いてみよう──ビデオゲームのこの40年、マリオ任天堂の“らしさ”と今後【インタビュー】 - ファミ通.com

あとで読むタグ2月に激減したが3月さらにもう少し減った。

アエラが説くには大学入学したら男しかいないサークルや男しかいないバイトを選んではいけないのだそうな。

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長ITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOSスマホアプリ実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセスインターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによります実施しなくとも良いとも思います

ベンダ説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います

サーバコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正海外IPからで、国外からアクセス許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います

Webサービスですが、ログインログアウト処理は必須でしょう。また、新規登録情報変更、退会処理も重要です。

パスワードリセットどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社存在しています

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります

別のベンダ発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料セブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断セブンに委ねられます

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます

特定ベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います

使ったことはありませんが、SecurityBlanket 365というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールOSSのものもあればベンダ販売していたり、SaaS提供しているものもあります

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしま可能性があります

また、ツール使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います

・・・とは言ってもセブンにはCSIRT部隊ちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループCSIRT として設置され、グループ企業に対してサービス提供しています。』と記載があります

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています

グループ企業情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査分析リスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会情報管理委員会のどこかに所属しているんじゃないかと思われます

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバー専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います

会見内で言われた二段階認証検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRT機能していなかったか力不足判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダCSIRT部隊情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧表現で伝わっていなかったとか・・・

ベンダ実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48

2019-03-08

歌詞を利用したsqlインジェクションとかできるのかな カラオケマシン壊そうぜ

2019-01-30

サーバパスワードを保存する時はハッシュ化したものを保存する

仮にパスワードを平文で保存したとして考えられるリスク

あと1つは?

2018-02-14

DBに生パスワードを保存してた

サイト運営を引き継いだんだけど

ユーザー認証用のユーザーIDのと生パスワードをそのままテーブルに保存してて吹いた

SQLインジェクション対策だけしてるのがまだ救いか

ログイン ユーザー登録
ようこそ ゲスト さん