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

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

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の「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

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

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

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ このエントリーをはてなブックマークに追加ツイートシェア

2019-03-08

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

2019-01-30

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

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

あと1つは?

2018-02-14

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

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

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

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

2015-06-13

ハッカーに聞きたいんだけど

ハッカーはこのはてな匿名ダイアリーから個人情報を引っこ抜くことってできたりするの?ユーザー名とかパスワードとかそういうの。

XSSなりSQLインジェクションなりで。

いや別にしてくれというわけじゃないけどさ。

このサイトってどれくらいのセキュリティがあるのかなーって気になったんだ。

2015-01-25

SQLインジェクションで開発業者有罪判決が出た件

まり話題になってないね。これは予想外。

Winny裁判匹敵するぐらい、結構衝撃的だと思うんだけど…

2015-01-23

542 仕様書無しさん sage 2015/01/23(金) 12:39:08.24 
>>541 
ちょっと違うと思う。IT疎い人はこういう説明でなるほど開発会社が悪い!となって、裁判官も多分そう思って判決出してる。 
普通に運用しててビニール入るのは欠陥だが、SQLインジェクションは欠陥ではない。 

俺が思うに、ローカルディレクトリが外から見えるようになってたとか、認証掛けてるつもりがかかってなかったとかが重過失。 
何故ならそれは家に鍵を掛けずドアが開いているか、ドアがないのと同じだから泥棒するつもりのない人でもうっかり入って来れちゃう。 

それに対しSQLインジェクション犯罪者がすること。悪意を持って行われる攻撃行為で、一般人はやらない。 
家で言うと鍵のピッキングだな。 
ピッキング泥棒入ったら工務店が悪い、みたいなのが今回の判決ピッキングにどこまで耐えられるように作るべきか、事前に仕様で決めておく必要がある。今回はSQLインジェクション対策仕様に入っていなかった。 
仕様にないから強い鍵を付けなかったら破られた。これを重過失ってのはひどすぎ。重過失って故意匹敵するレベルの過失だぜ。契約書の賠償上限無効にしてしまう程の。 

俺の考えはこうだ。SQLインジェクションなどセキュリティ対策実装について、 
仕様に書いてあった → 重過失 
仕様に一切無し →無罪または普通の過失 

パスワードがadmin/passwordとか改善の提案を拒否したとか別の話も話をややこしくしているが、話のコアの部分は以上のようなことだと思う。 

2014-11-08

中学生ハッカーゴーストライターになった話

兄弟からプログラミングやりはじめたんだけれど、この問題の答えになるようなのJavaで書いて欲しいんだ」みたいなリクエストがあった。

以前からパソコンハッカーとかに興味があった従兄弟で、

俺は一応エンジニアで飯を食っているのでよく懐いてくれた。

よくある初心者用の問題だったので、初心者が躓くポイントコメントをつけてメールで返す。

何度かやり取りが続いた。

たまにコードダメ出しをして欲しいとかいってくるが、ほとんど俺が書いていた。

俺の勘としては勉強のためというかは宿題の代行をしているみたいな気がしてきた。

なんかどこかに公開してんじゃないか?と思って、

コードのある部分をグーグル検索してみた結果一つのブログが出てきた。

ブログというよりは、SNSに近いあのサービスなのだが、完全に俺のコードがそのまま公開されていた。

そこの主のIDも従兄弟メールIDとかなり近い。

レーベンシュタイン距離が3で済むくらいIDが似ている。

もう完全に本人。

ハッカーバトル

なんかそのブログはいわゆるワナビーたちがいっぱいコメント書いていて

何だが微笑ましいんだけれども

なんかワナビーたちのグループが幾つかあって、そのグループ間でバトルになっていた。(総勢7人もいなかったが)

情弱とかスクリプトキディとかそんな煽り言葉が飛び交い、知識のひけらかしと揚げ足取りの激しい応酬が繰り広げられていた。

IP抜く、IP抜いてそこにトロイを送る、IPで住所を調べる、IPでどこ中かしらべる。

などなど…いやいや、IP信仰すげーよ。

太古の日本本名を知られたら魂を操られるという信仰くらいIP信仰すごいよ。

Wikipediaとかで知識を仕入れるんだろうね。

SQLインジェクションでお前のパソコンパスワード抜く」とか、「クロスサイトスクリプティングクッキー攻撃だ」とか…

攻撃名前ってかっこいいもんね。

分かる俺も中学生だったら使いたくなっちゃう。

そんな中で、従兄弟自分の成果として俺のコードを出していた。

ヘッダの署名や、冗談MITライセンスを記載していたがそれまでそのままコピペ

ここに集まってくる子たちはどんな子なのかと、それぞれのIDをぐぐってみたら

出るわ出るわ。ツブヤキサービスや別のブログサービスアカウントが…そして学校名も…

不正アクセスなんかしなくても個人情報すぐわかるのに、彼らはバトル中にそれらググれば分かる情報をつかって煽ることは無かった…

まあ、そんなもんか

とりあえずおもしろいので、しばらくゴーストライター続ける。

リアルタイム生産される黒歴史が見れて兄ちゃんちょっと懐かしい気持ちになったよ。

しばらくすれば飽きてくるだろう。

その時は従兄弟スキルがつくかも知れないから、一緒にソフトウェア開発をしたいと思っている。

スマホアプリとかWEBサイトとかね。

2014-06-27

徳丸本の内容を実践しながら学べた話

新卒入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェア制作販売するソフトウェアハウスだった。

入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページ管理があった。主な業務は、ページの文章更新と確認、誤字脱字の修正、古く間違ったHTML修正など。

会社ホームページには自社のサービス製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションセキュリティ勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。

から読み進める。1章に用語の整理があるおかげでだいぶ理解やすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。

なるほど、XSSクロスサイトスクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックス入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社ホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テストサーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……

検索ワード:
   +----------------+
   |                |
   |   1            |
   |       [  OK  ] |
   +----------------+

なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性修正の実習もできるな。

このようにして、徳丸本を読み進め、(テストサーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:

  1. 上述のXSS。直した。
  2. SQLインジェクション - XSSと同様の検索フォーム部分、ログイン部分。誰のアカウントにでもログインできた。急いで直した。
  3. CSRFクロスサイトリクエストフォージェリ) - ログイン済みのユーザを細工されたページに誘導すると、パスワード任意の値に変更できた。すぐ直した。
  4. クッキー不適切な利用 - httponlyでないCookieに、ユーザIDパスワードナンチャッテ暗号化(全ユーザ統一の値でxorしただけ)して保存していた。1のXSSとの合わせ技でその内容を外部に送信できたし、暗号の強度もダメだったし、そもそもログイン自体に使う情報Cookieに保存すべきではない。しかしこのCookie依存している箇所がたくさんあったため、XSS修正とhttponlyの対応だけになった。一応直った。

ショッピングシステムの中身が、フレームワークライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。

これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性始末書は、すべて現在担当である自分が書くことになった。

自分入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会コードレビューバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。

自分の作業はすべてgitで記録していたので、自分担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験からバージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。

こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さら勉強し、3年目に入るころには情報セキュリティスペシャリスト試験合格し、転職した。

Webサービスセキュリティ勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験環境CDもついているので、A社でホームページ担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)

すばらしい本を書いてくださった徳丸先生感謝します。

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

2014-04-22

パスワードの文字数制限って何であるの?

金が絡むサービスに限って、脆弱パスワードしか使えないことが多い気がする。

「8文字以上、16文字以内で記号なし」とか。

短く制限して何の意味があるの?

SQLインジェクションビビって記号さけるのはまぁ10000歩譲って分かるけど、なんでパスワードに桁数制限があるの。

単なる文字列なんか100文字ぐらい許してくれてもいいでしょ。そんなにリソース取らんでしょ。

問題は使用者が覚えてられるかだけど、そんな長いパスワード毎回入力するのはキチガイだけで、コピペするのが現実

最近1Password自動生成したパスワードしか使ってないので、一つも覚えてない。

ていうかキャッシュカード暗証番号とか4桁の数字だしありえなーい(棒読み)

2014-04-09

http://anond.hatelabo.jp/20140409134135

SQL組み立てで変数入れる場合は必ずprepared statement使えよって思うけど。

SQLインジェクションが発生しない場面もあるとは思うが、紛らわしいので、SQL組み立てに文字列変数直接入れ込むのは禁止したい。

2014-03-23

http://anond.hatelabo.jp/20140323204441

お金はかかってはない。っが、DB設計の都合優先だとは思う。

SQLインジェクションで穴作りたくないとバリデーションチェックでむやみやたらに全角押し付けた結果じゃないかな。

基本設計書にセキュリティ的な観点は入っても、全体を通したUI観点なんてまずみないから

その時点でお仕着せのようにここフリースペースなので全角オンリーねとアホの一つ覚えで決まったのでしょう。

全角⇔半角の処理を入れてUI向上を図りたい、その分、もちろん工数貰いますが、どうですか?なんて提案が

実際に作成する三次請け、四次請けの現場から出るとは思わないし、

アホみたいにお金かける場所は他にもたくさんあるから、そのまま、ユーザー検証とか顧みる事なく作られたんじゃねーの。

2014-02-14

http://anond.hatelabo.jp/20140212180803

んで、プログラマー()とか言ってる奴の仕事の大半はただただ命令通りにコードを書いてくだけなんだから一昔まえの事務仕事と一緒。

誰でも出来る簡単なお仕事

なぁなぁ、それってどうやって実現してんだ?

SI界隈でメシ食ってるけど、見てきたコードの9割がクソコードなんだが。今日でも20年前より状況が良くなってる感じがしないぞ。

ヒープとスタック区別も知らないスコープ意味もわかってない時間計算量も空間計算量も考慮されてなくて、

利用者が1人なら動くけど10人で利用すると挙動おかしいとか、

データ100件ならすぐ終わるけど10000件だと24時間たっても終わらないとかメモリがあふれるとか、

月や年をまたいだはずなのに32日になってるとか13月になってるとか、月末締切のはずなのに月末の前日に締め切られるとか、

SQLインジェクションどころか認証もしてないのに他人のパスワード書き換えられるとか、

カンマやダブルクォート入力したらCSVな出力データが壊れるとか、

マルチバイト文字列バイト単位で分割して分割部分の文字を壊すとか、

そういうことがおきないんだよな? おまえのとこでは。

本当にどうやって実現してるんだ?

2012-12-04

http://anond.hatelabo.jp/20121203233526

どうせSQLインジェクションとかサニタイズしてなかったとかその程度のレベルなんだろ?そんなのセキュリティ対策とは言わない。常識的なレベル。さすがにこの程度の指摘で根をあげてたら何も成長しないぞ

2011-05-15

http://anond.hatelabo.jp/20110514170542

システム管理から言わせてもらうと、これだけの情報ではシステム停止対応した是非は判定できないが、

おそらくは、事前通知なしのシステム緊急停止は行きすぎた対応はないかと思う。

それに、この派遣社員は、テスターとしては合格だが、技術者としては微妙ビジネスマンとしてはアウトだ。

このケースは、「SQLインジェクション」といって、攻撃により情報漏えいが起きる可能性であり、

システムセキュリティ上の致命的な欠陥が潜在的に存在すると分かっただけで、事前通知なしの緊急停止という対応普通はしない。

逆に、具体的な攻撃が観測された場合、または通常の操作情報漏えいが発生する欠陥が見つかった場合などは、迷いなく事前通知なしの緊急停止に踏み切るべきだ。

プライベート趣味サイトであれば即停止でもよいだろうが、ビジネスで使っているシステムである以上、セキュリティだけでなく、事業継続性や説明責任や止めた場合の影響も考慮すべき。

緊急度や対応方法もいろいろなバリエーションがあるし、インシデント発生対応時のマニュアルを参照しつつ、状況を照らして迅速に判断することになる。

なお、判断するのは、あくまで正社員責任者(内容によっては経営者が)であって、派遣社員はない。

ただ会社側の体制に問題があると思う。

派遣社員暴走?も、会社側がこういう場合対応について考えるきっかけを与えることになっただろうから、それはそれで意義はあったのではないかと思う。

システムのことさっぱりわからない経営者マネジメント側の人間ができることは、

(1)派遣社員には、システム運用稼働中に本番サーバを触らせないように権限を決めておく。

(2)その代わり、システム管理者として、スキルと判断力と責任感を兼ね備えた人材(正社員)を配置しておく。

(3)インシデント発生対応時のマニュアルを整備しておく。

ことだろう。

プライバシーマークISMSを取得すれば、こういうことが体系的にできる。

私がもしこのテスター(派遣社員)から運用中のシステム脆弱性を指摘されたらどうするか考えてみた。

(そもそもこんな品質レベルシステムは導入する時に却下するだろうが。)

(1)テスターから第一報をうける。時刻を記録

 ここからインシデント対応マニュアルを参照しつつ対応する。

(2)上司に口頭で「XXシステムで、セキュリティ上の問題発生、これより対応開始します」と報告。時刻を記録

(3)状況を確認する。

 (「SQLインジェクション脆弱性存在することがわかった。

  アクセスログなどから攻撃や情報漏えい痕跡はとりあえず見当たらない。

  ただし、攻撃は比較的容易で、個人情報流出する可能性があることが分かった。)

(4)対応方法を判断する。

 緊急性、停止方法、影響、修正、暫定復旧のめどを見積もる。

 (1時間以内に顧客通知を完了した上で、システムを停止して調査するとする。)

(5)上司対応概要説明。同意を得る。

(6)顧客通知開始。時刻を記録

(7)システム停止。時刻を記録

(8)ここからは調査、復旧作業など、具体的な対応に入る。

トラブル対応は手がいるので助っ人を頼む。顧客への連絡などは、営業担当者でも手伝ってもらえるはずだ。

システム停止後は、攻撃や情報漏えいが起きたか起きなかったかの調査が先になるだろう。

もちろん致命的なバグを仕込んだ開発者は呼びつけて調査に加わらせる。

都度、時刻を記録するのは、後で顧客に提出する報告書を書くためだ。

また、システム停止前に利用者に事前通知するかどうかは重要ポイントで、

データ更新処理を行うデータベース連携システムであれば、

更新処理中にシステムを停止すると、データの内容に不整合が生じる可能性もある。

事前通知なしでシステム止めた場合責任上これが問題となってくるし、データ整合が発生したら、その分復旧も遅れだろう。これひとつとっても、やみくもにシステム停止すればよいわけでは決してない。

備えあれば憂いなし。

2011-04-14

パスワード個人情報を扱うサービスを作る際に気をつけたこと

HTMLはわかるけど、サーバーサイドはお遊びでphpを触ったぐらいだったので、会員制でデータをためこむサイト作りに初めて挑戦した

今回重視したのは、「いか個人情報をお漏らししないようにして、万が一漏らしても被害を少なくするか」ということ。

世の中、有償サービスでもパスワードを平文で保存してるサービスが意外と多いらしいので、流出した時のリスクを少しでも減らせる対策として書きます

今回のシステム構成

サーバーロケットネットキャンペーンにでレンタルサーバ年1000円ポッキリプラン

クライアント側の処理HTML+CSS+jQuery(とプラグインもろもろ)
サーバ側の処理PHP
WebサーバーApache
データベースMySQL

個人情報こわい!

個人情報ビビる漏洩とかまじ困るし怒られるしこわい。

俺も巻き込まれたところでは、サミータウンがメールアドレスパスワードセットでお漏らししてお詫びに1ヶ月無料なにそれこわい

サミータウンだけならまだいいけど、メアドパスワードを他のサービスで共通化して使ってる情弱なので、

共通化してメアドパスワードをどこかのサービスが一箇所でも漏らすと、ヤフオクID乗っ取り事件みたいなことになる。

http://internet.watch.impress.co.jp/cda/news/2008/09/26/20967.html

だってできれば人様のメールアドレスパスワードとか預かりたくない。

万が一、肉親のメールドレス発見してパスワードにrapemeとか入ってたら明日からどういう顔すればいいかからない。

ググってみてもどこにも情報のってない。うーん困った。ダメもとで「個人情報ってどうやって保存したらいいんだろう。。。」

って、twitterでつぶやいたら、「住所とかは可逆暗号化でいいけど、パスワードハッシュで不可逆化しないとだめだよ!」

と、呪文のようなありがたい言葉を教えてもらった。

暗号化の種類

「住所とかは可逆暗号化でいいけど、パスワードハッシュで不可逆化しないとだめだよ!」

何のことかわからなったので、調べてみると、

・可逆暗号=元のデータに戻せる暗号化方式。

ハッシュハッシュ値を使った、元のデータに戻せない暗号化方式

うーん。。。よくわからん。。。

電話番号とか住所は、第三者が使用する情報なので、可逆が必要。パスワードは、認証しか使わないので、

ハッシュ値結果が一致すれば元のデータがわからなくてもOK、という方式なのでこういった暗号の使い分けをする。

●可逆暗号イメージ(もとにもどせる) 暗号キー開発者が指定する。
090-xxxx-xxxx →(暗号化)→ !'&%($% →(復号化)→ 090-xxxx-xxxxハッシュイメージ(もとにもどせない) 
登録passwordDBに保存)→(ハッシュ値抽出)→!"$#'$#="
ログインpassword →(ハッシュ値抽出)→!"$#'$#="
※二つのハッシュ値が合っていれば、パスワード一致として認証する。

暗号化の実現方法

可逆暗号電話番号とか住所とかに適用

今回はMySQL関数で実現した。encode関数暗号化して、decode関数でもとに戻す。

例えばtel_noという項目だけあるテーブルがあるとすると、

//データベースに保存する時
insert into テーブル名 (tel_no)  values (encode(tel_no,'暗号キー'));
//データベースから取得する時
select decode(tel_no,'暗号キー') from テーブル名;

これで、データベース格納時は暗号化(バイナリ化)されて、データベースから取り出してHTML表示する時に復号化はされる。

ハッシュパスワードかに適用

今回はphpのhash関数で実現した

ユーザ登録時>

$password=(フォームから取得)
$hash=hash('sha512',$password)
//ユーザ登録時は、ここで生成した$hashをデータベースにぶっこむ。

ユーザ認証時は、入力されたパスワードと、データベースパスワードが一致するかチェック。

ログイン認証時>

//フォームから入力されたパスワード
$input_password=(フォームから取得)
$input_hash=hash('sha512',$input_password);

//MySQLに保存されたパスワードを取得(略)
$db_hash==(データベースから取得)

//判定
if($input_hash==$db_hash)
	echo 'ログインしますよ!';
	//ここにログイン処理を書く
else
	die('メアドパスワードがあってないよ!');

これでもしSQLインジェクションとかでデータ流出しても、ハッシュ暗号パスワードに関してはまず解析されないはず。。。

可逆暗号データphp側の暗号キーが盗まれない限りバレない。。。はず。。。

暗号化する対象のデータをえらぶ

何でもかんでも暗号化するとコードが煩雑になるし、パフォーマンスにも影響でそうなので、

住所データ都道府県とか、漏れても良いような情報暗号しませんでした!!

本人が特定できなければ個人情報はないらしいので。。。

個人情報保護法
2条による定義個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)をいう。

http://ja.wikisource.org/wiki/%E5%80%8B%E4%BA%BA%E6%83%85%E5%A0%B1%E3%81%AE%E4%BF%9D%E8%AD%B7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E6%B3%95%E5%BE%8B#2

これで、もし漏れても、俺、ウンコ漏らして臭いけど、パンツから出てないからいいよね?というレベルはなった。はず。

お漏らさないようにキツくする

万が一漏れても大丈夫!と書いたけど、そもそも漏らすなというお話になる。色々調べた結果、以下の対策をほどこした

SQLインジェクション対策

・当初jQuery側でSQL組み立ててPHPに渡してたので、これだと任意のSQLが実行できて漏らし放題なのでやめる。

GETとかPOSTでDBに渡すパラメータを扱ってる場合、ちゃんとエスケープする。

例えばログイン認証するPHPで、GETメソッドでフォームからデータを取得するような場合

$id=$_GET['id']
$pwd=$_GET['pwd']
$sql="select * from ユーザーテーブル where uid='$id' and pwd='$pwd'

とかやってると、login.php?id=admin'&pwd=' OR '1'='1とかパラメータを渡されるとあら不思議

select *from ユーザテーブル where uid='root' and pwd='' or 1=1

で、誰でもログイン出来ちゃう!ので、mysql_real_escape_stringでエスケープしたり、渡されたパラメータが想定した値かどうか(例えば数値かどうか、とか)のチェックをいれたりする。

クロスサイトスクリプティング

・保存するデータタグJavascriptを埋め込まれないように、保存されたデータを出力する場合PHP側でhtmlspecialchars関数使ってエスケープするようにする。

こんな感じでお漏らし対策をした。間違いがあったら教えて欲しい

ちなみに出来上がったサイトはこれ。

http://oreni-makasero.com/

2010-08-05

また、個人情報流出か・・・

顧客クレジットカード情報約1万2千件が流出

http://sankei.jp.msn.com/economy/business/100804/biz1008041648025-n1.htm

なんか、また、SQLインジェクションとかそんな勢いか?

課金用の顧客DBWebエンジサーバーと切り離されてなかったのね・・・

やっぱり、サーバー構成と内部サーバー間のAPIの切り方がセキュリティー上は重要だなぁ。

2010-04-04

http://anond.hatelabo.jp/20100404214311

残念だけど、SQLインジェクションとか、セッションキーのコリジョンとかだったら、まだわかるが・・・

URLをちょっと変えただけで他人のデーターがみえちゃいますとか、どんだけだよ。

残念だが、この業界プロを名乗るなら、このレベルは、知っている範囲で、あきらかな過失だよ。

 

サービスするんだから、専門家を雇えよ。当たり前だが、作る業者と検査する業者は別にしろよ。知らないんだったら。

何回も言ってるけど、今回の被害者情報漏洩された人たちで、加害者はあくまで、サービス主体のPCソフト販売業者。

僕もだまされたんです、知りませんてのは、普通は・・・情状酌量の余地はあるけど・・・、

責任をとるのはあくまでも、PCソフト販売業者。PCソフト販売業者が別途制作会社を訴えるかどうかはそら、PCソフト販売業者の話で、ユーザーには関係ない。

残念だけど、PCソフト販売業者は加害者なんだよ。

 

つか、メールベースシステムなら問題なかったのに、知識もなく、予算もなく、ツテもなく、Web化してコケたんだろ・・・どんだけだよ。

無知は罪を正当化しないって言葉は知ってくれ。

データーはログインして、セッションを持ちましょうとか、本にも初歩として書いてあるだろうと。さすがに、このレベルは酷いよ。

程度の問題だよ、程度の問題。

 

他にもパスワード平文で保存して流出とか  svnバックアップサーバーにあげて流出とか パスワードEXCELで保存して流出とか

頭痛いすぎるんだよ、最近の事件は・・・ハッキングですらねーだろと

パスワード平文で保存は、情状酌量の余地もあるが・・・

パスワードEXCELで保存とか、今回の件は、酌量の余地があるのかよ?

http://anond.hatelabo.jp/20100404011633

しかしなぁ、

世の中には、パスワード一覧をEXCELファイルで作っちゃって、まちがってメールで関連先に送付しちゃって大問題っていう

インターネット企業』もあるわけだし・・・

それでいて、操業停止になるくらい、ユーザーが離れるわけでもないんだぜ?

そりゃぁ、セキュリティーなんて向上しないし、みんな無視するよなぁ

 

安かろう悪かろうで、そういう業者に発注するからそういうことになるんだが・・・

真面目にセキュリティーに取り組んでる奴がバカをみる・・・

嫌な時代だよな。

ちなみにな・・・

http://mag.wb-i.net/2010_04_02.html

対処策が・・・

1.metaタグの挿入(noindex,nofollow,noarchive)

2.USER_AGENTよるSpiderの排除

なんつーかな。

そもそも、セッション持って、外部から見られないように対策すべきであって、クロールされなきゃ良いって問題じゃないと思うんだが?

それにmetaタグよりrobots.txt使えば早いのに・・・とか、突っ込みどころ満載。

クッキーを使ったログイン機能と指定したIPアドレス(複数指定可能)からのみ管理プログラムアクセスできる機能を搭載予定

これを無しで販売したそのマインドがすばらしいし

それを購入した方のマインドもすらばらいい。

起きるべくして起きた事件としかいいようがない。

 

無かったのかよ・・・管理画面にログイン機能・・・

つーか、こんな初歩の初歩にひっかかるようじゃ、

真面目な攻撃食らったら簡単に個人情報吐き出しそうだな・・・このプログラム

SQLインジェクション感染したりして・・・w

2010-01-02

http://anond.hatelabo.jp/20100102215934

DBへのアクセス完璧コントロールされてるのなら…まあ…いいじゃないか…。

SQLインジェクションとかのハッキング原理的にありえません」とか断言できるならいいのかも?

平文で通信しているなら手の施しようがないが。

2009-02-12

http://anond.hatelabo.jp/20090212020601

どう修正してもいいけど、いい機会だからSQLインジェクションXSSを潰すことをお勧めする。

2008-10-20

[]今日増田情報セキュリティの日

私は単なる一増田でしかないのだが、なんとなく今日増田情報セキュリティの日とすることに決めた。

なぜって、今日は、年末年始という忙しく、そして狙われやすい時期をはさみ、2月2日からきっかり103日前だからである。

決して、はまちちゃんとエガミ君のやり取りがあったとか、増田セキュリティ関連の話題に乏しいとか思ったからではない。

さて、一口にセキュリティといっても、その幅は広い。まずは定番から攻めるのが定石であろう。何が定番なのかについては、例えば「Webアプリ脆弱性オタがふつーのSEの彼女に脆弱性世界を軽く紹介(ry」などが参考になるだろう。

しかし、たとえば「初心者はPHPで脆弱なウェブアプリをどんどん量産すべし」といったような初心者には、まずは10というよりも1から脱初心者していただくのがよいであろう。

そんなわけで、今年のテーマXSSとする。繰り返すが、はまちちゃんとエガミ君のやり取りがあったとか、XSS以外のネタが少ないとかではない。

さて、このように、今年のテーマXSSとなった。それではXSSとは何か、どのように起き、どう対処すればよいのか、そのような実例ちょうど良いエントリが「エガミくんの脆弱性のやつ」である。

さらに、このエントリをよんで、実際に「XSSしたい><」と思った人に読んでいただきたいのは「今昔さっき物語」であろうか。

さて、非常に簡単にXSSについて書いたが、このXSS、実はその他のさまざまな脆弱性の基礎でもある。

出力がHTMLならXSSだが、SQLならSQLインジェクションだし、シェルならコマンドインジェクション、メールヘッダならメールヘッダインジェクション等々になりえる。とくに、初心者にとってシェルは予想外のところで使われているから、気をつけよう。

その他セキュリティに関心があればsecurityタグお勧めしたい。セキュリティよりもsecurityの方が濃いのである。

p.s.

最後にこのエントリメモしておく

2008-07-27

Webアプリ脆弱性オタがふつーのSE彼女脆弱性世界を軽く紹介(ry

まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、

「オタではまったくないんだが、しか自分のオタ趣味を肯定的に黙認してくれて、

 その上で全く知らない脆弱性世界とはなんなのか、ちょっとだけ好奇心持ってる」

ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために

説明するべき10パターンを選んでみたいのだけれど。

(要は「脱オタクファッションガイド」の正反対版だな。彼女脆弱性布教するのではなく

 相互のコミュニケーションの入口として)

あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。

できれば、秋葉原とか筑波とかから突っ込みはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。

あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。

プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。

そういう感じ。

彼女の設定は

セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。

ひろみちゅとか、はまちちゃんてなんだろうという好奇心もある

サブカル度も低いが、頭はけっこう良い

という条件で。

まずは俺的に。出した順番は実質的には意味がない。

XSS

まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。

ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。

この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報彼女

伝えられるかということは、オタ側の「真のコミュニケーション能力」試験としてはいタスクだろうと思う。

MITM, DNS Rebinding

アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性(そうオタクが思い込んでいるだけ。実際は全然受け入れられない)」そのもの

という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには

一番よさそうな素材なんじゃないのかな。

Webアプリ専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう?」って。

パストラバーサル

侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを

彼女に紹介するという意味はいいなと思うのと、それに加えていかにもマニアック

「よく眼にするけどあまり実害の思いつかない」/etc/passwd

「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow

の2ファイルをはじめてとして、オタ好きのするファイル世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。

CSRF

たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。

そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性日本で大人気になったこと、

ひろみちゅがはまちを焦がしたのは事故か、わざとか?

なんかを非オタ彼女と話してみたいかな、という妄想的願望。

メールヘッダインジェクション

「やっぱりWebアプリ脆弱性個人情報DBなんかがあるサイトものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」

でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから

断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、

その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまから

ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが

Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。

なのに、安全APIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても

自分過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、

親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。

ディレクトリリスティング

今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。

SQLインジェクションよりも前の段階で、個人情報漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、

こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、

別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、

いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。

OSコマンドインジェクション

UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。

ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、

からこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。

「侵入先のコンピュータコードが動いてこそなんぼ」というクラッカー感覚今日さらに強まっているとするなら、その「クラッカーの気分」の

源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、

単純に楽しんでもらえるかどうかを見てみたい。

Hiddenフィールド改ざん

これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。

こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか

突っ込みを誘発するか、というのを見てみたい。

SQLインジェクション

9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。

XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と

なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。

というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら

教えてください。


「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。

こういう試みそのものに関する意見も聞けたら嬉しい。


Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん