この1～2年で、ウェブサイトの脆弱性を狙った攻撃が急増している。特に、2008年3月ごろから「SQLインジェクション」攻撃によるホームページの改ざんやサイトへの不正コードの設置が多発した。このような状況のなかで、(財)地方自治情報センター（LASDEC）では、ウェブアプリケーションの脆弱性を診断するサービスを提供している。本稿では、地方自治体の現状とLASDECの取り組みを解説する。 （百瀬 昌幸＝(財)地方自治情報センター 主任研究員） 地方自治情報センター（LASDEC）では、地方公共団体の情報セキュリティを支援する各種事業を展開している。平成19年3月には自治体セキュリティ支援室を発足し、以来今年で3年目を迎えた。こうした事業の1つが、「ウェブ健康診断」であり、当室が平成19年度から地方公共団体を対象に実施している事業（無償）だ。本事業では、地方公共団体の公式ホームページをはじめ、図
Webアプリケーションファイアウォールの機能をサービスとして提供する国内初の取り組みをセキュアスカイ・テクノロジー（SST）が始めた。オープンソース由来の同サービスの開発を手がける金床氏とSSTの若林氏に、その狙いと目標を聞いた。 WebサイトやWebアプリケーションを標的にするサイバー攻撃が激増する中、これらの攻撃に対処する手段としてWebアプリケーションファイアウォール（WAF）が注目されている。WAFはクロスサイトスクリプティングやSQLインジェクションなどWeb特有の脆弱性に特化してシステムを保護できるものの、導入や運用にはある程度の手間やコストも伴うことから、使いこなすようになるまでには時間やリソースを費やす側面もある。 Webセキュリティ企業のセキュアスカイ・テクノロジー（SST）は、オープンソースのWAF「Guardian」をベースにWAFの機能をオンラインで安価に提供する国
昨日書いたネタの続きだけど、そういえば、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
1. Web サーバの設定方法を覚えてほしい そんなに深くじゃなくてもいいんです。Apache でも IIS でも、なんだったら AN HTTPD だっていい（というか AN HTTPD って学習用にはかなりおすすめです）。それでどこにファイルを置くと外部からアクセスできちゃうのかということを知ってほしい。直リンクで様々なファイルを叩いてほしい。 「どんなところで稼働するのか」ということをほとんど学ばずに Web アプリケーションを書いている人って意外と多くて、そういう人が顧客情報がぎっしりつまったデータファイルを平気で外部からアクセス可能なところに置いたりするんですよね。 2. HTTP クライアントを作ってみてほしい とにかく Web プログラム自身が吐き出した HTML を善意に解釈するブラウザ（IE や Firefox）からのみアクセスされるものだと思い込んでいる Web プログラ
今回は、Webサイトやサービスをメンテナンス中にする場合に、どのURLにアクセスしても「メインテナンス中です」の画面を出す正しいやり方を、人間にも検索エンジンにも適切にする作法を主眼に解説します。 この週末の土曜深夜～日曜早朝にかけて、データセンターの設備メインテナンスのため、Web担を含むインプレスグループのほとんどのWebサイトが、どのURLにアクセスしても「メンテ中です」という表示になっていました。 なのですが、その実装がちょっと気になったので、「正しいメンテナンス画面の出し方」を説明してみます。 ※2010-01-16 Retry-Afterを指定するHeaderの指定を修正しました（コメント参照） ※2009-06-17 RewriteCondから [NC] 条件を削除しました（コメント参照） ※2009-06-16 Retry-Afterの記述をGMTに変更しました（コメント参
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
海の向こうで一気に議論が過熱したrev="canonical"ネタ。ざっくりまとめると、TwitterやSMS等の文字数制限のあるメディアで長いURLを投稿するためによく使われてるURL短縮サービスはアレだよね……というところから始まって、じゃぁ個々が自前で短いURLを用意してやって機械的に辿れる仕組み、rev="canonical"を使おうぜ！ という感じ。 URL短縮サービスの提供する短いURLは、on url shortenersで触れられているようにいくつもの問題点がある。一番身近なのはスパムの温床になっていること。インバウンドリンクの追跡が不可能であることなんかも気になる人が多いかもしれない。この話題が再燃した一番大きな原因はDiggBarの登場で、そこらへんの細かいところは短縮URLは必要悪か、単なる悪か。に詳しい。 「短縮URLは必要悪か、単なる悪か。」の最後で触れられている
前回ツールの欠点を書いたけど、Disるだけではひどいので、ツールを使う利点と言うのをあげてみるｗ 検査工数を大幅に減らせる 自動検査ツールを使わない場合、WebScarabとかProsなどで、手動で検査しなくてはいけないわけだが、コレが意外と手間がかかる地道な作業となる。 あるアプリで1ページに平均10個のパラメータがあるとする。そのアプリの検査対象ページが10ページだとする。 受入れテスト用セキュリティチェックリストのテストパターンを行うとして大体40個弱のテストを一つのパラメータに実施しなければならない。 となると、10（平均パラメータ数）×10（総ページ数）×40（テストパターン数）＝4000というかなり多くのテストパターンをセキュリティに関することだけで実施しなければならない。最も、テストパターン全てをやる必要はないだろうけど･･･ これを、手動でやるのは実際かなりめんどくさい。と
http://脆弱性診断.jp/specifications/index.html 発注側のセキュリティ要件書。 ざっとみたけど、まあよくまとまっていると思う。でも、要件だしたら必ずチェック方法を考えないとなぁと思うんですが･･･ あと、コレを見てどれくらいの人が理解して使うことができるか？ではないかなぁ？ やっぱり、各機能ごとにこういうことを考えてね見たいなテンプレートのほうがいい気がするなぁ。 例えば、ログイン機能はパスワード8文字以上にするとか、検索機能では「'」を含む文字列を正しく検索できるとか、決済機能では意図しない決済が行えないようにとか････ こういうパターンを幾つか作っておいて、それを選択するような感じのほうがいいのではないか？と思ってしまう。 とまぁ、要件に対するチェック方法として、自動検査ツールを使うと言うのは一つの解だと思う。しかし、現状の検査ツール（商用、フリー問
Expired：掲載期限切れです この記事は，ロイター・ジャパンとの契約の掲載期限（30日間）を過ぎましたので本サーバから削除しました。 このページは20秒後にNews トップページに自動的に切り替わります。
以前の肩書は物理学者、そして今やナイトの称号を持つTim Berners-Lee氏は、欧州原子核研究機構（CERN）で働いているとき、現在のインターネットの基礎となる提案をまとめた。 Berners-Lee氏は、世界中の異なる大学や研究機関で働く科学者の間で、自動情報共有を促進しようとしていた。 1989年3月、Berners-Lee氏は上司に「情報管理：提案（Information Management: a Proposal）」と題された文書を提出した。その文書には、翌1990年にWorld Wide Webとなる内容が書かれていた。この図はBerners-Lee氏のWorld Wide Webを説明した提案書の最初のページだ。 提案を進める許可を出したBerners-Lee氏の上司Mike Sendall氏は、この提案を「漠然としているが、興味をそそられる」と表現した。 提供：Cer
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のさかいです。 ネットサーフィンに慣れている techblog 読者のみなさんの中には、あちこち見て回っているうちに重いページに行き当たり、イライラしながら応答を待ったり、容赦なくバックスペースキーで前のページに戻ったり…という経験をされた方が多くいらっしゃると思います。 そういったストレスのないレスポンスが行えるよう、バックエンドのプログラムの最適化や、サーバーのチューニングを行うのは私たち技術者の仕事のひとつです。 しかし、あるウェブサイトにアクセスして、そのサイトを閲覧できる状態になるまでの時間のうち、そういったバックエンドでの処理に必要な時間は 1〜2 割でしかないというデータがあります。残り
Webアプリケーション開発者にとって切っても切れない問題――それがセキュリティ対策だ。日増しに複雑になっていく要件・機能に対する脆弱性検査に悲鳴をあげているデベロッパ/テスターも多いことだろう。そのような中、あのGoogleが、社内でも活用している脆弱性発見ツールをオープンソース化して公開した。同ツールは脆弱性検査の新しい決め手となるか。以下、基本的な使い方や主要機能について紹介していこう。 Google社内で現役の脆弱性検知ツール - ratproxy Googleは1日(米国時間)、Webアプリケーションのセキュリティ監査を実施するツール「ratproxy」をリリースした。ratproxyはプロキシサーバとして動作するオープンソースソフトウェア。同ソフトウェアを経由してWebアプリケーションを操作することで、XSS(Cross Site Scripting)問題や不適切なXSRF(Cr
デザイナーとプログラマーの間に優劣なんかない。あるのは役割の違いだけ。なのになんでHTMLコーダーとかデザイナーとかをバカにするプログラマーが多いのかサッパリわからない。 HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね。 web業界にも様々な職種があり、最近では分業化も進んでるみたいだが、 だからって「自分はHTMLコーダーですから、プログラミングには興味ありません」は通用しない。 HTMLコーダーやデザイナーも、プログラミングは勿論サーバーやネットワークの知識を持つべき。 まぁデザイナーは別業界でもある程度潰しがきくかもしれない。 プログラミング知らないHTMLコーダーがダメな理由 なんでやねん。なんのために仕事が分かれていると思ってんねん。デザイナーがサーバやネットワークを知らないといけないような状況って、プログラマーがクソなだけだろ。 そんないうんや
2008年7月，米グーグルは同社が開発したWebアプリケーションのぜい弱性検出ツール「ratproxy」をオープンソースとして公開した。検索サイト最大手の同社は，攻撃を受けることも多い。Google Appsをはじめ，代表的なWeb 2.0系アプリケーション開発の先駆者でもある同社が開発したツールの威力はどれほどのものか。ぜい弱性検査の専門家が探った。 “受動的”な検出ツール，Web 2.0系のぜい弱性に強み 検出できるぜい弱性は42種類，SQLインジェクションは苦手 Content-TypeなどでXSSの危険度をチェック JavaScriptスクリプトに潜むXSSのぜい弱性も検出 JavaScript Hijack/JSON Hijackのぜい弱性
Webアプリケーションのユーザーインターフェイス[6] 「戻る」で入力データが消えてしまうフォームはいらない 「寛容性とユーザーコントロール」 ソシオメディア 上野 学 2005/12/22 前回「入力情報を預かる責任を果たせる画面デザインとは？」は、あらゆる経験則の土台となる価値観として、「ユーザーを尊重する」というユーザー中心の姿勢について述べました。今回からは、Webアプリケーションのユーザーインターフェイス（UI）・デザインを行ううえで有効な経験則を、少し具体的に考えていきたいと思います。 その前にまず、連載の第1回「ユーザーにとっては“ユーザーインターフェイス”こそが製品そのもの」で触れた HCI（Human-Computer Interaction）の分野でよく挙げられる、コンピュータを用いた対話型システムの設計原則を紹介しておきます。ここでいう「対話型システム」とは、ユーザー
SitePoint - 11 Expert Tips For Enhancing The User Login Process WebサービスやWebアプリケーションをローンチしたときは開発者もやる気に満ち溢れ、初期ユーザからもいいフィードバックがもらえる。ユーザは自分の意見がストレートにサービスに反映されることを嬉しく感じ、デベロッパも開発に手応えを感じ熱心に改善する。しかし時が半年も経つといつのまにかユーザが遠のいている。よくある話だ。 Webサービスは導入までの敷居が低いため、ユーザはちょっとでも不便なUIがあると使う気が失せて別のサービスを探すようになる。たとえばそれがログイン部分であったら致命的だ。ログインしてもらわないことにはまず使ってもらえない。ログイン処理はセキュリティであったりユーザ体験であったりもっとも重要な部分だ。 Gary Barber氏がSitePointに11
「優れたCSSレイアウトのマークアップを研究したい」「制作途中のWebページの表示不具合の原因を探りたい」――そんなときに使えるツールといえば「Firebug」や「Web Developer」がおなじみだ。これらのツールはCSSや（X）HTMLの確認だけでなく、その場で編集したり、JavaScriptのデバッグもできるスグレモノ。だが、もっと最低限の機能だけを手軽に使いたい、というケースもあるだろう。 （X）HTMLの構造やCSSのプロパティのチェックに特化したシンプルなツールが「XRAY」だ。Webブラウザーに登録して使うJavaScriptブックマークレットのXRAYは、アドオンをインストールする必要もなく、機能が絞られている分、動作も軽快だ。 事前準備は、作者・Westcivのページにアクセスし、「XRAY」と書かれたボタンをブックマークに登録するだけ。FirefoxやSafariな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
