サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
ikepyon.hatenablog.jp
http://blog.ohgaki.net/char_encoding_must_be_validated まあ、当たり前にはならないでしょう。どう考えても不正な文字エンコーディングを受け付ける言語やらフレームワーク、DB、ブラウザが悪いと思う。不正な文字エンコーディングをチェックするというのはバッドノウハウだと思うし。そんなことに対応するのは大変すぎるからねぇ。 アプリ開発者を啓蒙するより、PHPとか直したほうが早いと思うんだけど。 XSSやSQLインジェクションが発生しないようにエスケープ処理やバインド機能を使うというのは、プログラムの基本に立ち返って、どんなデータが渡されても正確に処理を実行するために必要なことなので、当たり前といえると思う。 でも、不正な文字エンコーディングのチェックはプログラミング手法ではなく、それを受け取って変に解釈してしまうDBやらブラウザなどが直せないから
http://webappsec.sakura.ne.jp/modules/wfdownloads/singlefile.php?cid=3&lid=9 セキュメロの資料を公開した。まあ、ツッコミはいろいろあると思いますが、受けます http://www.mbsd.jp/event/detail125-desc.html に行ってきたので、簡単なメモ 楽天のインターネットセキュリティの取り組み 楽天におけるインターネットセキュリティの考え方 楽天のシステムは原子力発電所並みの運用体制と安全性を求められている（by 三木谷氏） 事業継続のため万全な対策を 予算内だけの対策というわけにはいかない 被害時のインパクトが大きい（2週間止まると250億の機会損失）から 予算の何パーセントで出来るかという考え方 開発全体予算の2％程度で実現 ハイスキルのセキュリティエンジニアが対策を最適化 グループシ
昨日書いたネタの続きだけど、そういえば、iモードIDって送信されないこともあるんだった。 http://www.nttdocomo.co.jp/service/imode/make/content/ip/#imodeid SSL使ってる場合、昨日のコード使えねぇじゃんw 結局、PHPのセッションIDきちんと使いましょうってことだな。 改めて読んでみたんだけど、微妙な所がちらほら。 CSRF対策にSSL SSL/TLSの使用 リクエスト強要（CSRF）対策に用いる照合情報は、他者に傍受されると都合が悪い。また、リクエスト強要（CSRF）対策が必要となる場面においては、ユーザやWebアプリケーションにとって重要なデータが送受信されることが十分考えられる。したがって、この場面においては、SSLあるいはTLSの使用が不可欠である。 http://www.ipa.go.jp/security/awa
ワッサーでつぶやいていて、PHPで個体識別番号をセッションIDとして使う方法を教えてもらった。http://wassr.jp/user/nihen/statuses/skctoRFZ3G 目からうろこが落ちた。 <?php session_id(get_mobile_id()); session_start(); if (!isset($_SESSION['count'])) { $_SESSION['count'] = 0; } else { $_SESSION['count']++; } echo $_SESSION['count']; ?>http://pastebin.com/m74eb934f ここで、get_mobile_id()で個体識別番号を取得するらしい。 で、それをセッションIDとして、session_idで認識させる。すると、CookieやHiddenを使えなくてもO
http://www.msng.info/archives/2009/06/caracter_reference_on_mixi_diary.php と言うのを見て、確認してみた。 mixiでは、コメントや日記の本文を確認する画面が出てくるが、実際に書き込みするために、hiddenフィールドでデータのやり取りをやっている。これはサーバの負荷等を考えてのことだろうと思われる。 ということで、コメントや日記の本文に「&"><&」を入れてみた。 そうすると、確認画面では以下のようなレスポンスが得られる。 <p>&"><&</p> : <input type="hidden" name="comment_body" value="&"><&" />表示部分では、「&」->「&」、「"」->「"」、「<」->「<」、「>」->「>」と変換して
http://脆弱性診断.jp/specifications/index.html 発注側のセキュリティ要件書。 ざっとみたけど、まあよくまとまっていると思う。でも、要件だしたら必ずチェック方法を考えないとなぁと思うんですが･･･ あと、コレを見てどれくらいの人が理解して使うことができるか？ではないかなぁ？ やっぱり、各機能ごとにこういうことを考えてね見たいなテンプレートのほうがいい気がするなぁ。 例えば、ログイン機能はパスワード8文字以上にするとか、検索機能では「'」を含む文字列を正しく検索できるとか、決済機能では意図しない決済が行えないようにとか････ こういうパターンを幾つか作っておいて、それを選択するような感じのほうがいいのではないか？と思ってしまう。 とまぁ、要件に対するチェック方法として、自動検査ツールを使うと言うのは一つの解だと思う。しかし、現状の検査ツール（商用、フリー問
http://www.milw0rm.com/papers/288 後で読む 夫ユーザがXSSという、バグのような脆弱性のようなものに熱中しています。 やってみたら？と言われて地球防衛軍で監視したところ、平日・休日関わらず、一日のうちに何度も、攻撃がされていました。 やjavascript:alert(document.cookie);を送るのではなく、+ADw-script+AD4-alert(document.cookie)+ADsAPA-/script+AD4-が、数行ぐらいずつリクエストとして連なっています。 夫ユーザの趣味の仲間も参加していて、最初は、脆弱性を発見するとスカッとするのかな、と思っていたのですが、一緒にドラマを見たり脆弱性を修正したり、子供と出かけたりサイトを更新した後、夫ユーザがリアルタイムでIPAに報告しているのを見ると、興ざめするようになりました。 最近では、
この間のまっちゃでチラッと話した政府が出している要件ってこれ。 http://www.nisc.go.jp/active/general/pdf/dm4-01-061_sample.pdf http://www.nisc.go.jp/active/general/pdf/dm6-03-051_sample.pdf http://www.nisc.go.jp/active/general/pdf/dm6-07-071_manual.pdf まあ、前にもリンクを張ったのだけど、再度掲載。 全部は読んでないのだけど、なかなかよさげなので使えると思う。
とりあえず、現在のバージョン（ベータ版）を公開しています。 あくまで自分が管理しているサイト若しくは、自分が開発したアプリに対してしか使用しないことが前提です。また、一応簡単な使い方はドキュメント化していますが、全然できていないため、試行錯誤し自己解決ができることが必要です(当然、簡単なことであれば回答しますが、あまり、サポートは期待しないでくださいw)。 テストパターンが必要となりますが、悪用防止のため配布していません。テストパターンが欲しい人はメールをください。 というわけで、欲しい人はこちらからユーザ登録を行って、ダウンロードしてください。 このツールを使って少しでも安全なアプリができることを望んでいます。 主な理由は、商用の検査ツールが高くて、ちっちゃな会社や、個人が開発、メンテしているソフトには使えないからだ。 かといって、自分でセキュリティ検査をするには、それなりの知識が要り、
暑いし眠いしorz http://internet.watch.impress.co.jp/cda/news/2008/06/18/19989.html 行ったセミナーの記事が出てた。 というわけで、昨日のセミナーのまとめっていうか殴り書きｗ あまり参考にならないだろうけどｗ ・事件発覚前のサウンドハウス社の売り上げの75%はインターネット経由のものである。 ・売り上げのうちクレジットカードを使用した決済は38%であった。 ・代金引換、銀行振込み、クレジットカード決済はほぼ満遍なく使用されていた。 ・プレスリリース（http://www.soundhouse.co.jp/news/20080418.pdf）を出すにあたり、 社内、LACからの反対があった（プレスリリース後、問い合わせが増えると考えたため） が、事件の詳細を出すことにより社会へのセキュリティに対する認識が向上すると考え、 公
なんか、暑い日がないんですけど・・・ セキュリティ業界ってなんとなく新興宗教っぽいなぁと。 「あなたのサイトは悪いハッカーに狙われているかもしれません。今ならこの製品を買えば、被害を受けることを防げます」とか、「 あなたのサイトが情報漏えい事件を起こしてしまったのは信心が足りなかったからです。この製品さえ買えばこれからあなたのサイトは安全になります」見たいな感じで営業してるしｗ いや、何ね、なんとなく胡散臭いなぁと思っただけですｗ もうちょっと別のアプローチで攻めないといけない気がする今日この頃
某所のネタを他の人からもらうために、書きなぐってみるw 脆弱性のチェック方法として、レビューとテストという二つがあると思う。 まあ、レビューがチェックなのか？という突っ込みは別にして、ソースコード監査も一種のコードレビューだからレビューもチェック方法のひとつとしよう。 そのうち、レビューは設計レビューとコードレビューに分かれるだろう。 とまあ、その時どういった観点でレビューするかというのをつらつら書き出してみると以下のようになるかな？ 設計レビュー ・基本設計 機能設計／リソース 機能・リソースへの脅威に対する対策が十分か？ 特に重大な被害を及ぼす脅威に対して複数の対策を施しているか？ 不要な機能はないか？ 機密性・完全性・可用性について適切な評価を行っているか？ I/O関連 信頼できるInputか？ ユーザから入力されるものは信頼できない ファイルから読み込まれるものはファイルを作成する
XMLHttpRequestを使えば、自由に改行が操作できるみたい。 例えば、こんなScriptがあったとすると。 <script> function createHttpRequest(){ if(window.ActiveXObject){ try { return new ActiveXObject("Msxml2.XMLHTTP") } catch (e) { try { return new ActiveXObject("Microsoft.XMLHTTP") } catch (e2) { return null } } } else if(window.XMLHttpRequest){ return new XMLHttpRequest() } else { return null } } function requestFile( data , method , fileNa
戦線にいまだ動きなし。うーむ、わざとなのか?それとも自分の仕事じゃないと思っているのか?どっちだ？ もう知らんけど。 しかし改めて過去の日記を見てみると、かなりたまってるなぁ。ガス抜き代わりに使ってるし。そろそろ愚痴大会もやめないと。 http://www.itmedia.co.jp/enterprise/articles/0505/02/news040.html わっはっはっ。もうお客とけんかする気満々ですが、というかけんか吹っかけてます。このままずるずるやってても意味ないしぃ。きちんとプロジェクト進めるためにも、首根っこ捕まえてやらさんといけないしぃ。 大体エンドユーザーと言うのは技術のことがわからないから、手間のかかるやり方をしようとするものだし、ベストな方法を提示して説明するのが技術屋さんのお仕事だと思う。場合によっては客先の担当者とけんかするのはありだと思ってるんだな。それによっ
セキュリティ機能要件 アプリケーションのセキュリティを考えるとき、必要なセキュリティ機能がいくつか存在する。そしてその要件はほとんどのアプリケーションで大きく変わることがないと思う。以下はそのような不変の機能であると思う。 認証機能 データ暗号化 通信の暗号化 ログ出力機能 認証機能 認証機能を実装する際、以下のような要件が必要と思われる。 1.認証方法 パスワードによる認証を使用するのであれば、次項のパスワードに関する要件を参照すること。 ユーザーが限られ、取り扱う業務が重要であれば、クライアント証明書による認証を検討する。クライアント証明書による認証には、クライアント証明書の取り扱いに関するポリシー、ルールが必要となる。 2.ログインIDポリシー ログインIDに使用できる文字種は数字と大小英字を含み、記号も使用可能とする。 ログインIDにメールアドレスを使用しない。 ログインIDを認証
このページを最初にブックマークしてみませんか？
『ikepyonのお気楽な日々〜技術ネタ風味〜』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
