IPアドレス・クッキー・JavaScript・UAなどを使わずユーザーを個別に追跡する方法
by Vernon Swanepoel ウェブサイトのユーザーがどれぐらいページを見てくれているのか、訪問頻度はどれぐらいなのかといった情報を追跡するのにはクッキー(Cookie)やJavaScriptなどが使用されますが、そうやって追跡されるのがイヤだということでCookieを受け入れないように設定したり、JavaScriptをオフにしているという人もいるはず。しかし、それでもユーザーを個別に追跡する方法があります。 Lucb1e.com :: Cookieless Cookies http://lucb1e.com/rp/cookielesscookies/ これはオランダ在住でコード・セキュリティ・ネットワークを愛しているというlucb1eさんが明らかにしたもの。手法としては新しいものではなく、多数のサイトで使われているにもかかわらず、そのことを認識している人はほとんどいないというも
もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう
スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前（ファイル名を使う直前）に行うべきだ、という考え方です。 スタ
それは robots.txt の問題じゃなくて...
なんか robots.txt がホットなキーワードになっていたので今さら知ったのですが、通信機器レンタルサービスの会社さんがクレジットカード情報をど派手に流出させたた件で、サイトに設置されていた robots.txt が色々と残念な件について話題になっていました。 robots.txt ： はてなブックマーク 不正アクセスによるお客様情報流出に関するお知らせとお詫び ： エクスコムグローバル株式会社 情報が流出した直接の原因は SQL インジェクションによる攻撃を受けたとのことで、同サイトの robots.txt が何の経緯で話題になったのかはわかりませんが、robots.txt の内容から、CMS に Drupal を使ってるらしいことや、Drupal のパッケージに同梱されてくる robots.txt ほぼそのまま設置されている件、さらにその、Drupal の古いバージョンには XSS
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
今日こそわかる、安全なWebアプリの作り方2010
2. アジェンダ • 本日の構成 – 脆弱性の分類 – Webアプリの構造と脆弱性の原因箇所 – 「入力」では何をすればよいのか – SQLインジェクション対策の考え方と実際 • 原理の話（グローバル） • 文字コードの話（グローバル&ローカル） – ケータイWebアプリのセキュリティ（ローカル） • 議論の焦点 – Webアプリケーションのセキュリティ施策の考え方 – グローバル v.s. ローカル – 対策の歴史とあるべき姿 Copyright © 2008-2010 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何
「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...
タイトルが長くて略称があれば知りたい感じの「安全な Web アプリケーションの作り方」を暇を見つけて読んでいます。今まであいまいなままだった部分を順を追って説明してくれるので、本当に助かります。Web アプリ作りの初心者は卒業したかなーという人は必ず目を通しておくと良いと思います。 Cookie を用いたセッションについて復習 「HTTP はステートレスで」とかいう話はよく聞きますが、じゃあどうやってセッション管理するのがいいの？って話をよく考えると体系的に聞いたことがなかった！というわけで、この本で文字通り体系的に学び直すことができました。 その中でも、「セッション ID の固定化」という話題はちゃんと分かってなかった部分があったので、こちらのサイトを参考に PSGI なアプリケーションを作ってみました(僕の書いたアプリ自体はその他の脆弱性に溢れていますがｗ)。コードはエントリの最後に。
初心者Webアプリケーション開発者がチェックすべき情報源 - ハニーポッターの部屋
初心者Webアプリケーション開発者がチェックすべき情報源を集めてみた。他に追加した方が良い情報源があった場合はご指摘いただけると助かります。 @ikepyonさんのご指摘により「LASDEC ウェブ健康診断」を追記した。 はてなブックマークの関連リンクによさそうな情報源があったので追記しました。それから、カテゴリを作りました。 ■Webサイト構築 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html 安全なウェブサイトの作り方(全92ページ、2.09MB） セキュリティ実装 チェックリスト（Excel形式、33KB） 安全なSQLの呼び出し方（全40ページ、714KB） ■Webアプリケーション開発 セキュア・プログラミング講座 http://www.ipa.go.jp/security/awareness/ve
WEBプログラマー必見！WEB脆弱性基礎知識最速マスター - 燈明日記
以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。 WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。 また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。 WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。 そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。 今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。 このまとめがWEBアプリケーション開発の参考になれば幸いです。 インジェクション クロスサイト・スクリプティング セッション・ハイジャック アクセス制御や認可制御の欠落 ディレクトリ・トラバーサル(Directory Traversal) CSRF（
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.saitolab.org/taiken/
パスワードをハッシュ化（暗号化）保存することを法律で義務化するくらいのことが必要だと思う