タグ

ブックマーク / www.oiwa.jp/~yutaka (5)

  • Webとセキュリティとソフトウェア工学 - こめんと(2016-06-20)

    ■ [Security] Webとセキュリティとソフトウェア工学 超久しぶりに、かつ真面目な内容で更新です。 徳丸浩さんのTwitterでの 何度でも言うが、自力でトラブルシューティングできない人や組織は、自前でWordPres立ててはいけない / “一般ブロガーがAmazon Web Service(AWS)で独自ドメインのWordpressサイトを10分で作る方法…” に対して、 山田さんの(恐らく)達観したコメント「こうやってセキュリティが素人プログラマーや、見習いプログラマーを殺すんだろうなぁ。想像していたとはいえ、現実になってくると絶望しかない。」 を、 奥くんのコメント経由で見たわけです。 正直なところ、徳丸さんの元のコメントには100%同意で、山田さんもわかった上での達観なんだと思うのです(少なくとも「批判」ではないと思う)が、 ソフトウェア科学→セキュリティ→ソフトウェア工

    cubed-l
    cubed-l 2016/06/21
    犯罪者が悪いのだけれども、第三者にも被害を与えかねないのがサーバーで遊ぶときの面倒くささなんだよね。誰でも楽に使えれば良いけど、現時点では頑張るしかない。頑張らなきゃいけないことは知ってて欲しいかな
  • こめんと(2006-04-02) CSRF と CSSXSS に関する議論について

    ■ [Security] CSRF と CSSXSS に関する議論について (3/30の続編) 思いっ切り一時 Slashdottedでした (^^;。 自前サーバの耐久性低くて済みません>読者のみなさま。 # FastCGI のおかげで、tDiary の負荷が上がってもシステム運用には影響出てなくて、 復旧もそんなに大変じゃない辺りはいい感じなんですけど、tDiary 自体は割とすぐ重くなりますね……。 随分と CSSXSS*1 のIEのバグ挙動の性質が整理されてきたようです。 そうは言っても所詮IE6の実装バグに起因する挙動なんで、性質を推定しても それが当に正しいのかは観察の積み上げというレベルでしかわからないという嫌な状況ではあります。 元々の30日の原稿、 CSSXSS 自体の性質にはあまり踏み込まず、 一般的に「他ドメインのページからデータの読み取りが可能な脆弱性がブラウザに

  • こめんと(2008-04-22) - MutualTestFox 公開

    ■ [Misc] 怒涛 うわー、なんか無茶苦茶忙しかった……。 とりあえず2件の発表を終えました。やること溜りまくりですねぇ。 ■ [Work] Fail-Safe C release 1 公開 というわけで、1つ目の発表は Fail-Safe C の正式版公開 です。 最初に函館で発表したのが2001年のJSSST大会*1 で、かれこれもう7年もかかってしまいましたので、プレスリリースは自分なりの1つの纏めとケジメのつもりです。 協力して頂いた皆様、当にありがとうございました。 Slashdot をはじめいろいろ連絡とかバグレポとかフィードバックを頂いた皆様、対応が遅れていてすみません。 有難く早急に取り組ませて頂きたいと思います。 Fail-Safe C の研究を始めるに当たって「C言語を対象にする」と決めた時点で、 実用に供するというのは大前提の1つです。これからも Fail-Sa

  • こめんと(2006-11-13) - 悪趣味な「月刊」セキュリティーホール

    ■ [Security] 悪趣味な「月刊」セキュリティーホール 最近気に入らないのが、「Month of Kernel Bugs」とか、「Monthly Undisclosed Bug」の類の企画やってる連中。 ハッカーセキュリティバグを見つけた際に、クラッカーとして悪用するか、 悪用せずに「適切に」利用するかの境界は、結局人のためになるか、 という一点につきると思う。どのように「人のためになるか」、については セキュリティ関係者の間でも議論が分かれていて、しばしば紛争になるのは 周知の通りかと思うが、大きく分けて次のような考え方があると思う。 ベンダ修正を待つべき派 結局ソフトウェアのバグを直せるのはベンダだけなのだから、 バグを見つけたらこっそりベンダに教えてあげて、 直った時点で公表するのが悪用を防いでみんなのためになる。 Full Disclosure 派 ベンダは基的に可能な

    cubed-l
    cubed-l 2006/11/13
    外からはハッカーなのかクラッカーなのか判別できない
  • えび日記: CSRFの説明に追記 - こめんと (2006-03-30)

    ■ [Security] えび日記: CSRFの説明に追記 (4/2、この項に別記事で追記。) ええと、この議論はずっと続いていますね。こういう時間かかる話はできれば年度明けてからやろうよ(笑)。 ※ちなみに「CSSXSS」と呼ばれている問題の質は「クロスドメインで任意の HTML の内容が読み取れてしまう」という点です。これは XSS とはあまり関係ありませんし、ある意味 XSS よりも危険です。その呼称は誤解を招くと個人的には思っています。 (「えび日記」より引用) この脆弱性の存在を根拠に「いわゆる高木方式は良くない、安全な他の方式にすべきである」という議論がよくあります。 いつも反論してるのですが、割と議論が噛み合わないのは、ひょっとしたら僕が「いや、高木方式で安全なんだ」と 主張しているように思われているのかなぁ、とふと感じました。 実はそうじゃないんですよね。僕の主張は、「い

  • 1