はてなブログのヘルプです
ヤフーの画像はなぜyimg.jpドメインなのか? サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
セキュリティのためsudoコマンドを利用して、オペレーションを することがあると思います。このときにsudoersで実行可能な コマンドを限定することで、さらに安全になります。 そこで、出てくるのが、 sudo vi や sudo less がしたいとか 言われたりします。 sudo viを許可するとどうなりますか? viコマンドは、外部コマンドを実行することができるため、 sudo viで起動したroot権限を持つviは、root権限でコマンドを 実行することができます。viからコマンドが起動されるため、 sudoコマンドの設定の影響を受けません。 ようするに、何もかも許しているのとなんら変わりません。 lessも同様にコマンドを実行することができます。 sudo less file で実行したlessコマンドからcshを起動すれば、 root権限のシェルが起動されます。 このような任意
2008年05月30日カテゴリの文書一覧PerlのTaintモードについて -- 壱 -- [PDF]ファイル名securecoding_azurestone_2008_05_30最終更新2008-06-09 01:06種類PDF作成者AzureStoneAzureStoneによる問題提起の発表資料です。詳細は、http://securecode.g.hatena.ne.jp/azurestone/20080603/1212156333 こちらをご覧下さい。 RealVNCから学ぶローカライズのセキュアコーディング [ PDF ]ファイル名securecoding_localize_2008_05_30最終更新2008-06-07 11:50種類PDF作成者AzureStone参加者(hashyさん)による問題提起の発表資料です。詳細は、http://securecode.g.hatena
以前の続き。JavaScriptからプライベートデータの参照、更新が出来る。Google Account Authenticationの仕組みを利用している。この前動かなかったサンプルはいつの間にか動くようになってた。 最初プロトコルは勝手にJSONPと思ってたけど、中身見てみたらIFRAME 使った fragment identifier (window.location.hashの値、URLの#以降)による通信だった。たしかに、IEで音をONにしたらクリック音カチカチする。ちなみにfragment identifierによるクロスドメイン通信は他にdojoがライブラリとして実装しているのは知っているけど、これだけ大々的にサービスで使われてるのを見たのは初めて。もっとも、ブラウザでクロスドメイン通信を達成する方法のうち現時点でもっともマシなのはこれじゃないかという意見もある。 解析してみ
【1.初めに】 要望がありましたので、今回はLinux(実際はRedhat系Linux)でそこそこ安全かつ楽にサーバを立てる際の手順を記してみます。 ※一応注意:今回は、試しにサーバを立てる程度であればこのくらいで十分ではないかと思うレベルを想定しています。サービスに投入するサーバでは私はもっと細かいところまで手を入れています。 【2.そこそこ安全かつ楽にサーバを立てる手順】 さて、いよいよ本題です。サーバを立てる際は、不必要なものを全て取り除いてから必要なものを追加していくというのが基本になります。以下の手順1~5では不要なものの除去、手順6~7で必要なものを追加し確認しています。それを踏まえまして。 ■手順1. OSをインストールします。(私はLinuxであればCentOSを入れることが多いです。その際私はインストールの種類をカスタムにしパッケージグループの選択では開発ツール以外全部チ
Webアプリケーションのぜい弱性を示す用語として,クロスサイト・スクリプティング,SQLインジェクションといった言葉の認知度はかなり高まった。ブログ・サイトなどでも活発に議論されている。しかし,Webサイトの実態はどうだろうか。 筆者の所属する京セラコミュニケーションシステムでは昨年(2006年),ぜい弱性診断を実施したWebサイトの統計情報「2007年版 Webアプリケーションぜい弱性傾向」を発表した。これによると,パソコン向けWebサイトの48%に致命的なぜい弱性が見つかった。このうちワースト1位はクロスサイト・スクリプティングで56%,2位はSQLインジェクションで11%と,どちらもインジェクション(注入)系のぜい弱性。これらのぜい弱性を持った危険なサイトは依然として存在するのが実情である。 これらWebアプリケーションのぜい弱性があまりなくならない理由はいくつかあるが,以前は「ぜい
Examples; (MS) means : MySQL and SQL Server etc. (M*S) means : Only in some versions of MySQL or special conditions see related note and SQL Server Table Of Contents About SQL Injection Cheat Sheet Syntax Reference, Sample Attacks and Dirty SQL Injection Tricks Line Comments SQL Injection Attack Samples Inline Comments Classical Inline Comment SQL Injection Attack Samples MySQL Vers
エスケープだけしてれば、セキュリティ対策が万全になる訳ではないですよ - masaのメモ置き場 の話について、高木さんより「PreparedStatementを使いなさい、動的パラメータの例は分岐で処理しなさい」、という趣旨のコメントを頂いてしまった。まだ、もやもや感があるので、もう少し考えてみる。 数値型チェックの話 select password from usertable where id = 入力値 (idが数値型) 入力値に 1 or 1 = 1 が与えられると・・数値型の列に数値型以外の値が渡された時に発生する問題は、どの層ならば対策可能で、どの層が責任を持つべきなの?という話。型の概念を持つ言語なら、データベース層に数値型の引数を受け付けるインタフェースが用意されていて、アプリケーション層ではそのインタフェースを呼び出すことになる。型変換はアプリケーション層が行うことになる
« PERL5WEBDB | メイン | IIS のログを tail -f » 2006年04月11日 CSRF 対策 w. JavaScript CSSXSS に対して脆弱でない CSRF 対策とはどのようなものか、という議論が続いているようですが、JavaScript を用いてよいのであれば、簡単な対策手法が存在すると思います。 CSRF 対策では、フォームの hidden パラメタに、なんらかのトークンを埋め込むことで、第三者によるフォーム偽造を防止するのが一般的です。しかし、 CSSXSS を用いて、そのトークンを第三者が読み出せてしまうという点が、問題をややこしくしているように思えます注2。 しかし、 JavaScript を用いて良い環境では、単純な対策が存在すると思います。 HTML 内にあらかじめトークンを埋め込んでおくのではなく、フォーム送信時に、ブラウザ側でトークンを埋
■ WASF Times版「サニタイズ言うな!」 技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。 「サニタイズしろ」だあ? Webアプリを作ったらセキュリティ屋に脆弱性を指摘された――そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか? 「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの?プログラムの内容からして必要のないことなのに? そう
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう?というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して(HTTP1.1では303応答)、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
高木浩光さんの「サニタイズ言うなキャンペーン」 という言葉自体はずいぶん前から存在したのだが、 続・「サニタイズ言うなキャンペーン」とはにて高木さん自身がいくつも誤解の例を挙げているように、 そしてまた最近も 駄目な技術文書の見分け方 その1にて「まだわからんのかね」と言われているように、 「わかりにくい」概念なんだろうとは思う。 そこで、僭越ながら、「サニタイズ言うなキャンペーン」について、 私なりの解釈を書いてみようと思う。 もっともこれが正解であるという保証はないのだが、 間違っていたらどなたかツッコミいただけることを期待しています(_o_) そもそも何のせいで「エスケープ」しなければならないのか たとえば住所氏名を登録させるWebアプリケーションは珍しいものではないと思う。 そこで、私が「Taro&Jiro's castle サウスポール」 とかいう恥ずかしい名前のマンション(?)
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く