これなら合格! 正しいリダイレクターの作り方:HTML5時代の「新しいセキュリティ・エチケット」(4)(1/3 ページ) えっ、まだmeta refreshとか301使ってるの? リダイレクターの作り方も時代とともに移り変わります。記事を読んだらすぐに使えるセキュリティ・エチケットを紹介しましょう。 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。今回は、「オープンリダイレクター」という脆弱性について説明します。 オープンリダイレクターとは? オープンリダイレクターとは、あるURLを開くと自動的に他のページにジャンプするリダイレクト機能が、攻撃者によって任意の外部ページへのリダイレクターとして利用可能になっている問題です。 「http://example.jp」上で提供されるWebアプリケーションにて、例えば「http://example.jp/go?url=/nex
ファイル名は「左から右に読む」とは限らない?!:セキュリティTips for Today(8)(1/3 ページ) 私たちの常識が世界では通用しないことがあります。攻撃者はそんな心のすきを狙って、落とし穴を仕掛けます。今回はそれを再認識させるかのような手法と、その対策Tipsを解説します(編集部) 皆さんこんにちは、飯田です。先日、セキュリティ管理者の方々と「今後のウイルス対策のあり方」について意見交換をする機会がありました。参加者からは活発な意見や質問も飛び交い、盛り上がりを見せた意見交換会となりました。私自身も多くの気付きや学びを得ることができ、貴重な時間を過ごすことができました。 その意見交換会の中で、Unicodeの制御文字を利用したファイルの拡張子偽装の話題が出ました。この手法は目新しい手法ではなく、数年前からすでに指摘されていたものです。しかし、久しぶりに本手法について議論するこ
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。(1)文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と,(2)文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング(1)――冗長なUTF-8符号化問題 まず,(1)の不正な文字エンコーディングの代表として,冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン(表1に再掲)を見ると,コード・ポイントの範囲ごとにビット・パターンが割り当てられているが,ビット・パターン上は,より多くのバイト数を使っても同じコー
カミンスキー氏が発表したDNSアタック手法と対策例:DNSキャッシュポイズニングの影響と対策(前編)(1/4 ページ) 2008年7月に公開されたDNSキャッシュポイズニングの脆弱性。DNSの仕様に深く関係するこの手法に対して、エンジニアはどのように対策を打つべきでしょうか。この脆弱性の本質的な問題と対策、そして私たちが考えなくてはならないセキュリティの心構えなど、2回に分けてお送りします(編集部) ※ご注意本記事に掲載した行為を自身の管理下にないネットワーク、コンピュータに行った場合は、攻撃行為と判断される場合があり、最悪の場合、法的措置を取られる可能性もあります。また、今回紹介するツールの中には、攻撃行為に利用されるという観点から、アンチウイルスソフトにウイルスとして検出されるものも存在します。このような調査を行う場合は、くれぐれも許可を取ったうえで、自身の管理下にあるネットワークや
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Parental ControlTop Smart Phones High Speed Internetmusic videosfashiontrends Trademark Free Notice Review ourPrivacy Policy Service Agreement Legal NoticePrivacy Policy|Do Not Sell or Share My Personal Information
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか -SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
前回の新生銀行のサイトの使い勝手についてのポストに思いのほか反応がありました。はてなブックマークでも「新生の使いづらさは尋常じゃない」とか「こに書いてあること全部の10倍くらいダメ」とか「書いてもらえてスッキリした」みたいな反応が多くて、そういう声を引き出せたのは書いた甲斐があるなぁ。 それで、セキュリティに関する話だから噛みついてくる人もいるだろうと思っていたらやっぱりいて、カレーなる辛口Javaな転職日記で「全般として,いかにも素人っぽい批判に終始しているように思う」と書かれていたのを見つけたので読んでみたのだけど、そこに書かれていた反論は「もっとセキュリティを下げろなんて論外」という、予想通りのいわゆる一段階論理だったのですが、よく考えてみればそういう思考回路の髪のとんがった上司をどう説得するかというシチュエーションは現実問題としてあるわけで、そのためもう少しだけ深追いしてみること
どうやら、どこかの馬鹿たれがお客様の所でUSBメモリを落としたらしい。幸いお客様が拾ってくれたので、最悪の事態は免れているようだが…。 よく、こういう状態になると、 ・USBメモリ、利用禁止 という話になる。現にうちでもそうなっている。その気持ちは判らなくもないが…この指示には2つ問題がある。 1) そもそも現在の世の中、輸送しなくてはいけないデータ量が莫大である そんな中で、あれもだめ、これも駄目、と駄目駄目尽くしをすればセキュリティが守られる、と考えているようだが、その発想こそが守ることは可能だが、仕事はできなくなるような状態を作り、結果としてルールはルール・実態は実態などという腐った状態を作り上げるのだ。 駄目駄目ルールを作る前に、一体どれぐらいの情報を持ち歩く必要があるのか、なぜ持ち歩く必要があるのか(大抵の場合、自宅に仕事を持ち帰らないと終わらないぐらい、一人ひとりに仕事を割り
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
お問い合わせフォーム、登録フォーム、キャンペーンの申込フォーム。 Webにはいろいろなフォームがある。 Webプログラマーであれば誰もが一度は作ったことがあると思う。 新人プログラマーの初めての実務がフォームであることも多いだろう。 新人が作っているというのにもかかわらず、技術的にも面白い部分がないせいか、正しい知識のある人がレビューすることが少ないと思われる。 単純さゆえにテストが不足しているということもあるかもしれない。 上記の理由は憶測にすぎないが、杜撰なフォームがたくさん出回っているのは事実だ。 もう、CAPTCHAの話とか以前の問題だ。 よく見かける悪い例を簡単にあげておく。新人が初めての実務に当たるときにこれを気にしてくれれば、世の中のフォームがだいぶ良くなると思う。 1. クライアントサイド(JavaScript)でのチェックのみ。 2. 選択肢式の入力欄に対するチェックの漏
最近ようやく初級プログラマーを卒業できた手応えのようなものを感じており、いよいよコードを読み書きするのが楽しくてしょうがない段階になってまいりました。 こういうとき、Rubyは初心者にもやさしいけど、上達すればどこまでも上のステージが用意されているような、まるで自然言語のようななめらかさ・しなやかさがあって、ほれぼれとします。デザインの美しいものに触れているときには人間はこんなにも幸せになれるのか、という感じですね。ときに、今回のブログネタは、デザインの悪いものに出会うとこんなにも気分が悪くなるのか、という話なのですが。 なお、新プロジェクトではデザイナーのクリスの勧めでHamlを使うことにしたり、アーキテクトのダニーの設計でJavascriptにPublish-Subscribe型の(つまり一対多の)コールバックのフレームワークを作ってみたり、ReallySimpleHistoryを使い
Webサービスの認証などに利用される変形文字のCAPTCHAはユーザーの妨げになるだけで、不正アカウント取得を防ぐ役には立たなくなったのか。Webサービスでアカウントの不正取得を防ぐために使われている変形文字の「CAPTCHA」は、もう役に立たなくなっている――。人気WebメールのCAPTCHAを破るボットの相次ぐ登場を受け、セキュリティ研究者がこう指摘した。セキュリティ企業のWebsenseは先に、米Microsoftの無料Webメール「Windows Live Mail」のCAPTCHAを破るボットが出現したと報告。続いてGoogleのGmailのCAPTCHAも破られたと伝えている。 IBM傘下のセキュリティ企業InternetSecurity Systems(ISS)のガンター・オルマン氏は2月25日のブログでこうした現状について紹介。CAPTCHAはかつてはいいアイデアだっ
初心者はPHPで脆弱なウェブアプリをどんどん量産すべし ↑のブックマーク うん。増田くんはいつもいいこと書くね! ブックマークの方には 危険だとか迷惑だとか踏み台だとか色々かいてあるけれど(というか踏み台ってなんだろ?) そんなに大切な個人情報をたくさん扱ってるサイトなんてどれだけあるかな。 みんなそういうサービスつくってるの? なんかすごいね。 ぼくの使っている範囲だと、(提供側が気をつけていないと)本当にまずいのは銀行と証券とカード会社のような、お金のからむサービスくらいだよ。 もちろん、他にメール内容だとか、購読しているフィードだとか、知られたくない個人情報なんてのは、人によってたくさんあるよね。 だけど、例えばぼくがメールサービス作りましたなんて言ったら誰か使う? それか無名の団体だったらどうかな。それで大切なメールやりとりしちゃうの? そう。そもそも、利用者もそれほどバカじゃな
via del.icio.us/popular Coding Horrorブログの記事Has CAPTCHA Been “Broken”?(CAPTCHAは破られたか?)では、CAPTCHAの解読ツールに値段をつけて売っている中国の業者の価格表を紹介していて、これが面白い。 CAPTCHA用の文字列画像を作るときは、文字を画像化したり、色をつけたり、線を引いたり、無関係な点や図形を足したり、湾曲させたり、と、いろいろな加工で「人には読めるけど機械には読めない」ように作るわけだが、この価格表では、単純なCAPTCHAで彼らの販売するツールで読み取れる可能性が高いものほど値段が安くなっているし、彼らのツールでは読み取れてない場合も多いような難しいものについては、ツールの値段も高くなっている。 この価格表で図らずも、いろいろな大手サイト(主に英語と中国語でのサイト)が使っているCAPTCHA図形
セキュリティ自由研究:この夏、グミ指を作ってみないか:Security&Trust ウォッチ(48) 指紋は指先にある紋様で、人ごと、指ごとに異なる。指先から出る皮脂などによって、この紋様が何かに付着することを指紋が付くという。その特徴を生かして、指紋は個人を特定することにもよく用いられる。事件の証拠として利用したり、入室管理や携帯電話のロックなどの認証でも用いられている。 以前、指紋認証システムを食用のグミなどで作った指紋(グミ指)で突破することができるという記事を何かで見掛けて、一度試してみたいと思っていた。身近な材料で、最先端の技術が突破されるというギャップに驚きを感じた。今回は実際にこの目でグミのチカラを確認してみようというレポートである。セキュリティ自由研究レポート ■採取した指紋からグミ指を作ろう 指紋はそこら中に付いている。指紋は皮脂なので一度付着すると取れにくいようだ。と
君は“はまちちゃん事件”を知っているか? mixiのホームページ。mixiユーザーの中には、赤で囲んだ“マイミクシィ最新日記”欄に、“ぼくはまちちゃん!”の文字がいくつも並んだ人がいた 古くからのmixiユーザーであれば、“はまちちゃん事件”を覚えている人も多いだろう。2005年4月、mixiで大勢のユーザーが“ぼくはまちちゃん!”というタイトルを付けた、謎の日記を次々に公開するという怪現象が起こった。 きっかけとなったのは、あるユーザーが投稿した日記。その日記の本文には「こんにちはこんにちは!!」という言葉とともに“あるURL”が貼り付けてあった。 このURLが罠で、不思議に思って押すと、クリックしたユーザーのページに“ぼくはまちちゃん!”というタイトルで同じ文面/URLの日記が勝手にアップされてしまうのだ。 投稿は“ねずみ算”的に増え、一時は混乱状態に…… さらに、勝手にアップロードさ
Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP(Open Web ApplicationSecurity Project)は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASPTop Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く