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

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

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インジェクション対策だけしてるのがまだ救いか

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

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