もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
バグを放置したら逮捕？ 話題の「ウイルス作成罪」の改正刑法が成立 - はてなニュース
これまで処罰が困難だったコンピューターウイルスを使った犯罪を取り締まるための改正刑法が、6月17日（金）の参議院本会議で可決、成立しました。はてなブックマークでは以前から同改正案の内容に注目が集まっています。この改正案の成立の経緯と、議論の的になった問題点を紹介します。 ▽ コンピューターウイルス作成罪を新設 改正刑法が成立 :日本経済新聞 ▽ 法務省：情報処理の高度化等に対処するための刑法等の一部を改正する法律案 改正刑法の正式名称は「情報処理の高度化等に対処するための刑法等の一部を改正する法律」です。改正案は5月31日の衆議院で可決されており、6月17日の参議院での可決により成立しました。 この改正では、ウイルス（不正指令電磁的記録）の作成者に対して3年以下の懲役または50万円以下の罰金を課します。ウイルスの定義に触れている該当の条文を引用します。 第百六十八条の二 正当な理由がないの
知らなかったらNGなWEBアプリケーション脆弱性一覧 : mwSoft blog
先日、AmebaなうがCSRFという非常にポピュラーな脆弱性を披露したかと思ったら、ここ数日はセブンネットショッピングでXSSの脆弱性と、ID推測による他ユーザの個人情報閲覧の問題が発生しているという噂が流れています。 ユーザの情報を預かっておきながら、基本的なセキュリティの対策もできていないというのは、銀行に例えるなら、お金を預けようとした時に「お金は預かります。ちゃんと保管します。でも警備はあまりしないので盗まれたらスイマセン」と言われるようなものだと思う。 警備に穴があったというのではなく、まともに警備してませんでした、というのはさすがにありえないことです。 そこで、野良WEBプログラマである私が知っている脆弱性を列挙してみた。 私はプログラマであってセキュリティの専門家ではないです。しかも今年の春辺りからずっと外向けのWEBプログラムは組んでません。 その人間が知っているものを並べ
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
書籍『Ajaxセキュリティ』に関する残念なお知らせ - ockeghem's blog
昨年の10月に刊行された書籍Ajaxセキュリティは，発刊直後に購入したが，しばらく積ん読になっていた。最近になって読み始めたのだが，いささかあきれる結果となった。HPの現役エンジニア2名の著作，一人は元SPI Dynamics社(WebInspectの開発元，HPが買収)出身，GIJOE氏の監訳ということで期待していたのだが，残念である。 残念だと思う主要な理由は，脆弱性への対策が十分に示されていないことだ。Ajaxであってもインジェクション系脆弱性が発生する可能性があること，むしろ従来型のWebアプリケーションよりもその可能性が広がることは説明されているが，肝心の対策が不十分だ。 本書第四章の後半には，対策として入力検査（バリデーション）が示されている。 4.6 適切な入力検査 4.7 リッチなユーザ入力のバリデーション しかし，入力検証だけでは，任意の文字入力を許す場合の対策はできない
第2回セキュアコーディング勉強会まとめ資料公開
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
5分で絶対に分かるバッファオーバーフロー ― ＠IT
バッファオーバーフロー攻撃の仕組みを知ろう 皆さんがよく利用しているアプリケーションにセキュリティホールが見つかり、「悪意のあるコードが実行される可能性がある」というような内容のニュースをよく耳にします。 しかし、自分でインストールしたわけでもなければ、実行させたつもりもない「悪意のあるコード」がなぜ実行できるのでしょうか？ 今回は、バッファオーバーフローを利用して、ほかのアプリケーション上で悪意のあるコードが実行される仕組みについて説明していきます。
確認画面でhiddenに入力値を埋め込むのはセキュリティ的にダメか? | ブログが続かないわけ
お礼 先のエントリー(初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス)で、自分でもびっくりするくらいのブックマークを頂いた。この内容が参考になると思ってブックマークしてくれた人より、他の人にも紹介したいとか、よくあるよねといった共感に近い気持ちでブックマークしてくれた方が多かったのは、素直にうれしいしと思ったし、安心もした。 本題 ただ、何人の方から「確認画面でhiddenに入力値を埋め込むこと」に対して疑問を抱かれた。これに対して僕なりの解釈を付け加えておきたいと思う。 以下は、あくまでもフォームの話。 セッション管理されたシステム内におけるなんらかの書き込みシステムでは、話が全く変わってくることにご注意を。 結論から言うと「確認画面でhiddenに入力値を埋め込むこと」はセキュリティ的には問題ない。 (以下、この方法をhidden方式と呼ぶ) そもそも、セキュリティ
ブログが続かないわけ | 初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス
お問い合わせフォーム、登録フォーム、キャンペーンの申込フォーム。 Webにはいろいろなフォームがある。 Webプログラマーであれば誰もが一度は作ったことがあると思う。 新人プログラマーの初めての実務がフォームであることも多いだろう。 新人が作っているというのにもかかわらず、技術的にも面白い部分がないせいか、正しい知識のある人がレビューすることが少ないと思われる。 単純さゆえにテストが不足しているということもあるかもしれない。 上記の理由は憶測にすぎないが、杜撰なフォームがたくさん出回っているのは事実だ。 もう、CAPTCHAの話とか以前の問題だ。 よく見かける悪い例を簡単にあげておく。新人が初めての実務に当たるときにこれを気にしてくれれば、世の中のフォームがだいぶ良くなると思う。 1. クライアントサイド(JavaScript)でのチェックのみ。 2. 選択肢式の入力欄に対するチェックの漏
コメント: PHPは駄目な言語なのか? - スラッシュドット・ジャパン
趣味でやっている人のことは、まあ、いいとして（踏み台にされる可能性はあるけど）、仕事でPHPを使うときの注意を書いておこう。 コーディング規約を守る。組織にコーディング規約がないなら、Zend Framework PHP標準コーディング規約 [zend.com]を使う。オレ流コーディングスタイルは禁止。 内部コードにはEUC-JPかUTF-8を使う。入出力もできるだけShift JISを避ける。Shift JISを使う場合には2byte目に0x5Cを含む文字の動作を忘れずに確認する。 開発環境の警告レベルをE_STRICTにする。本番環境ではdisplay_errorsをオフにする。 register_globals、magic_quotesはオフにする。 type hintingを積極的に使う。 スコープの長い配列をクラスでラップする。 プレゼンテーションとロジックを分割すること。プレゼ
高木浩光＠自宅の日記 - WASF Times版「サニタイズ言うな！」
■ WASF Times版「サニタイズ言うな！」 技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。 「サニタイズしろ」だあ？ Webアプリを作ったらセキュリティ屋に脆弱性を指摘された――そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか？ 「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの？プログラムの内容からして必要のないことなのに？ そう
初級PHPプログラマがおかしがちなミスＴＯＰ１０:phpspot開発日誌
The PHP coder's top 10 mistakes and problems @ SourceRally.net PHP Community 「PHPプログラマがおかしがちなミスＴＯＰ１０」、という記事があったので紹介。 PHP初心者だとこういうミスがよくありますね。ということで今年からPHPをはじめようと思っている人には気をつけてほしいリストです。 生でクエリを出力しない echo ＄_GET['username']; ↓ echo htmlspecialchars(＄_GET['username'], ENT_QUOTES); やらないとクロスサイトスクリプティングされます。 SQLクエリに＄_GET,＄_POST,＄_REQUESTの値を直接含めない ＄sql = "select * from table where id=".＄_GET["id"]; ↓ ＄sql =
Ajaxの特徴に潜むリスクをサンプルアプリで確認しよう ― ＠IT
第1回 Ajax技術の目に見えない通信内容をのぞいてみようでは、Ajaxの技術背景を解説しました。今回は、「セキュリティ」という観点でAjaxを見ていきたいと思います。 2回目の今回は、非常に幅広く、奥が深い「Ajaxの特徴に潜むセキュリティリスク」を、実際のサンプルアプリケーションの通信や、マウスの動きを動画で見ながら、理解しましょう。スパイウェアやキーロガーへの基本的な対策も解説します。 通常のWebアプリと異なるAjaxの特徴に潜むリスク 「Ajaxのセキュリティ」といきなりいっても、『Ajaxとはいえ、単なるWebブラウザで動作するアプリケーションなのだから、これまでのWebアプリケーションのセキュリティとあまり変わらないのでは？』と予想される方も多いでしょう。確かに、Webアプリケーションとして注意すべきセキュリティのポイントは、Ajaxにおいても共通して当てはまると考えて問題あ
コード一行怪我一生 : 404 Blog Not Found
2006年05月02日21:15 カテゴリBlogosphereLightweight Languages コード一行怪我一生 ソース嫁という主張にも一理あるのだけれども、ソース嫁派が見落としていることが一つある。 Amazonアソシエイトのtakochu04-22って何？ - diary.yuco.net (2006-05-01) 全サイトはてブ化・その場コメント・ワンクリブクマというGreacemonkeyの拡張機能によるものでした。ソースを見たら確かに「takochu04-22」の文字が。ちなみに、この拡張機能の解説ページにすべてのアソシエイトIDを書き換える旨の断り書きは見当たりませんでした。 ＊「ふっかつのじゅもんがちがいます。」 - ソースを読めない人はgreasemonkeyを使ってはいけないgreasemonkeyスクリプトは危険なことができるので、自分でソースを読んで安全
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
高木浩光＠自宅の日記 - 続・「サニタイズ言うなキャンペーン」とは
■ 続・「サニタイズ言うなキャンペーン」とは 「サニタイズ」という言葉はもう死んでいる サニタイズ言うなキャンペーンがわかりにくい理由, 水無月ばけらのえび日記, 2006年1月5日 というコメントを頂いた。まず、 これは「サニタイズという言葉を使うな」という主張ではありません。「そもそもサニタイズしなくて済むようにすべきだ」という主張です。言い方を変えると、「サニタイズせよと言うな」という主張になります。 「サニタイズ言うなキャンペーンがわかりにくい理由」, 水無月ばけらのえび日記, 2006年1月5日 とある。「サニタイズせよと言うな」キャンペーンでもよいのだが、 その場合は次の展開が予想される。 「サニタイズせよと言うな」を主張する際の具体例として、XSSやSQLインジェ クションのケースを挙げた場合、正しいコーディングは、「その場の文脈でメ タ文字となる文字をエスケープすること」と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
PHPでのセキュリティ対策についてのメモ - Liner Note
A. WEBプログラマコース