情報更新

last update 06/28 21:30

ツイート検索

 

@ikepyon
サイトメニュー
Twilogユーザー検索

Twilog

 

@ikepyon

Ikeda Masakazu@ikepyon

  • 875フォロー
  • 1,380フォロワー
  • 96リスト
Stats Twitter歴
3,679日(2007/06/04より)
ツイート数
17,940(4.8件/日)

ツイートの並び順 :

表示するツイート :

2017年06月28日(水)2 tweetssource

2017年06月27日(火)4 tweetssource

2017年06月23日(金)3 tweetssource

6月23日

@ikepyon

Ikeda Masakazu@ikepyon

@tomoki0sanaki 現状、データが多数とれて実は何らかの傾向があっても、見た目では分からないので、問題ないんですけど、何らかのブレークスルーで一気に分かるようになったりすると大変だなぁと思うわけで

posted at 15:30:39

6月23日

@ikepyon

Ikeda Masakazu@ikepyon

CSRFトークンやらセッションID等の推測可能性ってソースコード読めばまあ推測できそうという判断はつくんだけど、その値だけ見た限りだとわかんないことがほとんどなんだよねぇ

posted at 14:33:49

2017年06月22日(木)1 tweetsource

2017年06月20日(火)3 tweetssource

2017年06月19日(月)4 tweetssource

6月19日

@ikepyon

Ikeda Masakazu@ikepyon

「バリデーションorエスケープはセキュリティ対策です」というのはじゃ、セキュリティ重要じゃないからバリデーションorエスケープしなくてもいいよね感がすごく出るので言いたくないし、聞きたくないw

posted at 15:18:24

2017年06月16日(金)23 tweetssource

6月16日

@ikepyon

Ikeda Masakazu@ikepyon

脆弱性検査をやって脆弱性が何個見つかったかが手っ取り早いんだけど、アプリの仕様によって大きく変わることが予想されるし

posted at 15:41:54

6月16日

@ikepyon

Ikeda Masakazu@ikepyon

こうなると仕様自体がセキュリティ上問題となることがないかというのは非常に重要なことのはずなんだけど、いまいちそっちが盛り上がってないw まあ、現状はコーディングの問題による脆弱性の方が多いからねぇ

posted at 12:20:12

6月16日

@ikepyon

Ikeda Masakazu@ikepyon

アプリケーションには処理すべきデータとそうでないデータがあり、本来その違いを示す条件が仕様には必要。入力されたデータがその条件に合致しているかどうかを確認するのがバリデーションである

posted at 11:59:55

6月16日

@ikepyon

Ikeda Masakazu@ikepyon

アプリケーション開発において仕様を厳守することが第一である。仕様にない動作をすることはバグであり、アプリケーションの完全性を損なうことである。

posted at 11:57:33

2017年06月15日(木)19 tweetssource

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

バリデーションもエスケープもセキュリティと関係なく絶対に必要なことであって、セキュリティのために必要なことじゃない。だってtully'sやo'reilyが検索できなきゃ困るでしょ?

posted at 18:50:51

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

どんなに自分達の書いたコードに脆弱性がなくても使っているフレームワークやミドルウェアに脆弱性があったら、自分達のコードで対処するのは難しいわけで、その対策がかけてるとowasp top10のあの項目は言ってるんだと思う

posted at 18:19:26

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

無駄でもいいから何かしていることが評価されるので、いろいろ問題が起きているのだと思うんだよね。野党の政治活動なんてまさにそれorz

posted at 16:11:20

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

ただ組織としては問題発生を防ぐ仕組みを作り、それを実践している組織の方が、頻発する問題を個々に対処する組織より評価されるべきだと思う

posted at 16:06:26

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

仕事を減らす仕組みを作るというのは大体において評価されないw むしろ仕事を増やす方が仕事をしているように見えるので評価されるという謎w

posted at 15:58:19

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

セキュリティエンジニアも脆弱性が少なくなるような仕組みを作ることより脆弱性を一杯見つけたり、セキュリティ事故を少なくなるような仕組み作りよりセキュリティ事故が起こった時の対処の方が評価が高かったりするように思う

posted at 15:56:16

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

日本の組織って評価方法が色々おかしいんじゃないかと思った。システム運用なんてトラブルが起こって収拾したら評価されて、トラブル起こらないような仕組みを作っていたら評価されないとか

posted at 15:54:08

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

なので、仕様で許可されたデータはどんなもの(攻撃に使えるものであっても)でも正しく処理を行う(誤動作しない、攻撃がヒットしない)ように作るべき。これはバリデーションでは何ともできない

posted at 13:56:40

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

仕様では許可されたデータであるにもかかわらずバリデーションで攻撃に使えてしまうデータをエラーとしてしまった場合、そのアプリケーションは仕様を満たしていないことになる。これは問題。

posted at 13:53:59

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

バリデーションの目的は処理に値しないデータを処理しないようにすることであり、攻撃を防ぐことは目的ではない。したがって、「たまたま」バリデーションで脆弱性を防ぐこともできる。しかし、処理に「値する」データで且つ攻撃に使えてしまうデータはバリデーションでは防げない

posted at 13:48:12

6月15日

@ikepyon

Ikeda Masakazu@ikepyon

SQLインジェクションもXSSもコードのバグでしかないので、バグが少なくなるようなコーディングを心がければなくすことができる。

posted at 13:46:14

このページの先頭へ