Twilog

 

@ikepyon

Ikeda Masakazu@ikepyon

  • 878フォロー
  • 1,360フォロワー
  • 96リスト
Stats Twitter歴
3,614日(2007/06/04より)
ツイート数
17,755(4.9件/日)

ツイートの並び順 :

表示するツイート :

2017年04月21日(金)7 tweetssource

4月21日

@ikepyon

Ikeda Masakazu@ikepyon

@yousukezan しかし、みっちり8時間、月20日も転記する仕事があるのかという疑問もw
毎日脆弱性の報告の上がる開発現場ってのも嫌wいっぱい開発案件が並行で上がってるなら別でしょうけどw

posted at 17:09:52

4月21日

@ikepyon

Ikeda Masakazu@ikepyon

@yousukezan 見つけるんじゃなくて、見つかった脆弱性を開発者に説明する資料作成&いつまでに直すかの調整をする仕事のような。どっちにしろ安杉

posted at 16:48:12

2017年04月20日(木)14 tweetssource

4月20日

@ikepyon

Ikeda Masakazu@ikepyon

某人が信頼境界を強調するのはソースコード診断してると正しいのかw 攻撃に使えるかどうかは信頼境界外由来のデータかどうかで判断するわけだし。コード書くときには邪魔な考えでしかないけどw

posted at 14:08:18

4月20日

@ikepyon

Ikeda Masakazu@ikepyon

ツール入れるより人力で脆弱性探した方がコード読める人は早いんじゃなかろうかorz 現状はツールが発展途上だからなぁ

posted at 13:59:43

4月20日

@ikepyon

Ikeda Masakazu@ikepyon

@kidasan 某ツールのはそれ以前の問題ですorz
多分ある変数がどういうメソッドで使われていくかしか見てないものと思われます。データがどのように変わっていくか?を見ていれば検出できるはずなんですけどね…

posted at 13:16:58

4月20日

@ikepyon

Ikeda Masakazu@ikepyon

interface A があって,class B implement Aで宣言したClass Bがあるとする。
B b;と宣言したコードだと脆弱性を検出するが、A b;と宣言したコードだと脆弱性を検出しないorz

posted at 13:06:24

4月20日

@ikepyon

Ikeda Masakazu@ikepyon

某ツールあかんorz
Classで宣言した変数を使ったコードは脆弱性検出する。同じClassでもInterfaceで宣言した変数を使ったコードは脆弱性検出しないorz

posted at 13:04:25

2017年04月18日(火)4 tweetssource

4月18日

@ikepyon

Ikeda Masakazu@ikepyon

使ってるフレームワークやライブラリの脆弱性に対して即時対応できないなら、sucutumみたいなWAF入れておいた方が楽じゃね?別にsucutumの回し者じゃないけどw

posted at 17:51:19

4月18日

@ikepyon

Ikeda Masakazu@ikepyon

銀行もクレジット会社もAPIの提供に積極的ではないという事情もあるだろうけど、そのネット家計簿って信頼できるの?といつも思う

posted at 10:47:29

4月18日

@ikepyon

Ikeda Masakazu@ikepyon

時間割アプリにIDとパスワードを入力するのだめ!とか言う割に家計簿アプリに銀行のIDとパスワード入れるのだめ!というのはあまり聞かない。そっちの方が嫌だけど

posted at 10:45:25

2017年04月17日(月)4 tweetssource

4月17日

@ikepyon

Ikeda Masakazu@ikepyon

@tomoki0sanaki COBOLならまだ何とか。この間よく知らないRubyも読みましたが、ググって何とかなりましたw
LISPやらPrologは言語仕様が全く異なるので、まったくわかりませんw Prologなんてかじってみたけど読めるようになる気がしませんw

posted at 14:28:11

2017年04月14日(金)13 tweetssource

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

米「言われたパターンは直した。」
客「直ってるの確認できたけど、前直した問題また発生するんだけど」
というのもたまに見かけるw

posted at 14:58:16

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

大体、対策を考えるとき、信頼の内側か外側かなんてこと考えずに、これは許可されるべきものかどうかで考えるでしょうに

posted at 11:58:34

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

「信頼境界」はリスクを考えるときに考慮するものであって、対策を考えるときに考慮するものではないと思う。

posted at 11:56:44

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

@bugbird それをひとまとめにすると現実にそぐわないように思います。かけた工数に対してメリットが少ないという結果にしかならないような・・・

posted at 10:32:19

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

@bugbird ま、その問題はあります。なので、既にある脆弱性をどうにかする方法と、アプリを最初から作る場合に脆弱性を作りこまないようにする方法は分けて考えないといけない時期に来ているのかもと思うのです。

posted at 10:30:54

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

@bugbird 例えば、サービスは止められない、でも、攻撃を受けているクリティカルな脆弱性を今すぐ何とかしたい!というのであれば数時間で対応できるバリデーションによる対策は非常に効果が高いと思います。その後の改修において根本的な対策を含めないとダメなんでしょうけど

posted at 10:23:38

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

今存在する脆弱性を最低限の工数で直すのであれば、入力値バリデーションで問題を引き起こすデータをチェックするというのは検討に値するように思う。しかし、それでは漏れが発生する可能性があるし、一から作るなら脆弱性を作りこまない方法を検討したほうが、漏れがないように思う

posted at 10:14:23

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

現状存在する脆弱性をお手軽に直す方法と、これから作るものに脆弱性を作り込みにくく(作りこまないように)する方法は分けて考えないといけないのかもしんない

posted at 09:55:42

4月14日

@ikepyon

Ikeda Masakazu@ikepyon

アプリケーションのセキュリティにおいて「信頼境界」とか持ち出すのは一般論としての脆弱性と対策(っぽいもの)の説明が楽なだけで、実際の対策には屁の役にも立たないと思っているw

posted at 09:36:51

2017年04月13日(木)3 tweetssource

4月13日

@ikepyon

Ikeda Masakazu@ikepyon

外から来たか中で生成されたものかを判断しながらチェックするコード書くより、それの由来がどうあれ、処理するに適したものかどうかチェックするコードを処理の前に書いた方が楽だし漏れがない

posted at 16:35:26

2017年04月11日(火)5 tweetssource

4月11日

@ikepyon

Ikeda Masakazu@ikepyon

任意の口座への振り込みはできなかったけど、別途申請書で申請した振込先へは振り込みできてた。その後ワンタイムパスワードが渡されてオンラインで振込先の登録や任意の口座への振り込みができるようになった。

posted at 15:30:05

4月11日

@ikepyon

Ikeda Masakazu@ikepyon

健保の初期アカウント登録の件でふと思い出したけど、以前シティバンク銀行のオンラインバンクは口座作ると勝手に口座番号でアカウント作られて、初期パスワードが生年月日だったような。オンラインバンクから住所変更もできてたなぁ。

posted at 15:28:15

4月11日

@ikepyon

Ikeda Masakazu@ikepyon

その辺のこと考えて作ってたら防げた気がする。データに誰がアクセスできて、そのデータ(What)を誰(Who)がどういう状態(When)のときどうするのか(how)という機能仕様とデータのアクセス権を突き合わせて矛盾が起きれば機能仕様を変更するということを行えば楽に出来るような?

posted at 09:58:06

4月11日

@ikepyon

Ikeda Masakazu@ikepyon

暗号化では復号できるので、システム管理者やアプリ管理者は見ようと思えばデータを見ようと思えば見れる。パスワードはシステム管理者やアプリ管理者であっても書き換えは可能にすることはあっても、見えてはいけない。なので、平文で保存するなんてもってのほかだし、復号できる暗号で保存もダメ

posted at 09:52:00

4月11日

@ikepyon

Ikeda Masakazu@ikepyon

日産レンタカーのパスワードリセットの問題って「誰」がデータを参照できるかというのをきっちり定義してたら防げた気がしてきた。「誰」にはアプリを使う人だけじゃなく、システム管理者やアプリの管理者も含めて考えておく必要があるけど

posted at 09:49:52

このページの先頭へ