もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
ヤフーにおけるインプットバリデーション「何も信じるな」 (Yahoo! JAPAN Tech Blog)
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R＆D統括本部 開発推進室 セキュリティプラットフォーム技術 セキュリティスペシャリストの戸田 薫です。 今回は、私たちが普段からヤフーのシステムに対する入力にどのような注意を払っているのか、そのいくつかをご紹介致します。 入力とは? Webサイトを運営している場合、どのような入力があるでしょうか？ たとえば、Webサービスには、以下の入力があります。 Cookie URL GET/POSTのデータ ファイルのアップロード その他リクエストヘッダ そのほかにもいくつもあります。 環境変数 設定ファイル クローラが取得したデータ パートナー企業のAPIから取得したデータ（XMLやJSONなど） パートナー企業の入稿用 F
ログイン/ユーザ登録といったフォーム実装用のフレームワーク「jFormer」:phpspot開発日誌
jQuery Form Framework - jFormer ログイン/ユーザ登録といったフォーム実装用のフレームワーク「jFormer」。 JavaScript と PHP、CSSファイルが１つのセットになっており、このフレームワークを使って便利なフォームをPHPで簡単構築できるライブラリです。 例えば、ログイン用のフォームを見てみると、次のように、demoユーザの案内を出すことも出来ます。 デモページ上には、単にデモだけではなく、実現するためのPHPコードがデモページ上から確認でき、比較的容易に実現できるようになっています。 全てPHPのコードで記述出来てしまうところがこのフレームワークの特徴。PHPとJavaScriptの思考をいったりきたりする必要がなくて作り安いというわけです。 テキストのバリデーション機能なんかも入ってます。 ここら辺もPHPでrequiredに設定することで
「わざと脆弱性を持たせたWebアプリ」で練習を
命名・「やられWebアプリケーション」（仮） 構築したWebアプリケーションがセキュアかどうかを確かめる方法として、疑似的に攻撃を行うことで問題を発見する「脆弱性診断」があります。脆弱性診断は専門業者が実施することがほとんどだと思いますが、あなた自らが脆弱性診断の技術を身につけることで、セキュアWebアプリケーションについての理解が深まるとか、自社内で脆弱性診断ができるようになるといったこともあるかもしれません。 脆弱性診断の技術を身につける過程では、脆弱性を見つける手法を試したり、診断ツールを試したりする必要がありますが、診断といえど攻撃と同様のことを行うので、気軽に実稼働環境で実験するわけにもいきません。ましてや、他人や他社のWebサイトで試すなどはもってのほかです。 そこで、わざと脆弱性を持たせたWebアプリケーションと、それを動作させる環境が必要になります。 このような環境をわざわ
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
formの各項目のnameとvalueを画面上に表示する - monjudoh’s diary
どんなの？ ↓こんなの 前置き 人に説明するときの簡単な資料として使ったり、 印刷して横に置いて見ながらコード書いたりとか。 業務系システムの画面なんかだと項目がべらぼうに多いこともよくあるので、 普通のスクリーンショットに手でポチポチ書いていったり、 Excelに貼付けてhogehogeとかやると死ぬ人もいるだろうし、 とりあえず私は死ぬので楽にやりたい。 必要なもの Firefox Web Developer http://www.getfirebug.com/ jQueryを読み込ませるbookmarklet Google AJAX Libraries API版 (JavaScriptの動的ロードとか) - 文殊堂 やり方 ページを表示して、 Web DeveloperのForms->Display Form Detailsを選択 こんな感じでformの各要素の手前にタグを表示してく
持続型XSS | 鳩丸ぐろっさり (用語集)
用語「持続型XSS」について持続型XSS (じぞくがたえっくすえすえす)話題 : セキュリティ クロスサイトスクリプティング脆弱性の中でも、特に、ターゲットのサイトにスクリプトが持続的に埋め込まれ、効果が永続するタイプのもの。一般的には "XSS type2" と呼ばれたりするようですが、数字で言われても分かりにくいので、このサイトでは「持続型」と呼ぶことにしています。"stored XSS" とも呼ばれるようです。 ユーザが入力した内容をサイトに表示する機能があり、その表示の処理に不具合がある場合にこの問題が発生します。反射型XSSと大きく異なるのは、サイトに訪れた全てのユーザに対してスクリプトが実行されるという点です。罠サイトや罠メールを経由する必要がなく、普通にサイトを訪れたユーザが被害に遭います。そのため、反射型に比べて脅威は大きなものとなります。 実際に過去に被害にあった例として
クリックジャック - 素人がプログラミングを勉強していたブログ
最近流行のクリックジャックについて、メモ程度にまとめておく。 一言で言うと、外部サイトのボタンをユーザが間違えてクリックしてしまうように仕向けるテクニックが、クリックジャックである。 クリックジャッキングってこうですか？ わかりませんではiframeをCSSのopacityプロパティを利用して透明にして、その下にダミーのボタンを置いている。目に見えているボタンを押そうとすると、その上に被せてある透明なiframeのボタンが押されてしまう。 [Sleipnir]No Click Jacking — Gistはこの攻撃に対する防御手段として考えられたユーザースクリプトで、透明なiframeを検出する。 しかし、opacity以外にもクリックジャックをする方法はあるので不十分である。 例えば 2009-03-04_2146 - javascripter's library にスクリーンキャストを
“セキュアなWebアプリ”に立ちはだかる課題 − ＠IT（情報元のブックマーク数） - ripjyr's blog
開発で抑える、検査でバグを落とす、防御する、確認するという対策ですね。 Webアプリケーションの脆弱性対策は、おおむね以下のように分類できます。 1. 開発時に脆弱性を作り込まないようにする 2. 開発後の脆弱性検査を行う 3. ネットワーク攻撃防御／検知システム（IDS／IPS／WAF）と関連サービスを利用する 4. ログ取得および関連サービスを利用する 今回は、この4点の現状をお話ししていきましょう。 “セキュアなWebアプリ”に立ちはだかる課題 (1/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT やっぱりフレームワークに組み込まれるのが一番いいのかな？＞三輪節でも セキュアプログラミングができる技術者、というスキルが明示的に個人のスキルとして示すことができないうえに、それで就職や転職に有利かというと、そこまで社会的な受け皿の機運は高まっていません。従って、技術者の中
SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog
以前このブログでも取り上げたことのある神戸デジタル・ラボの近藤伸明氏がThink IT上で「SQLインジェクション大全」という連載を執筆しておられる。その第三回「SQLインジェクションの対策」を読んで以下の部分が引っかかった。 バインド機構とは、あらかじめSQL文のひな型を用意し、後から変動個所（プレースホルダ）に実際の値（バインド値）を割り当ててSQL文を生成するデータベースの機能だ。バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 http://thinkit.jp/article/847/1/ たしかにエスケープ処理を使ってバインド機構を実装する場合もある。JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 | 徳丸浩の日記から派生して、MyS
第1回■ぜい弱性がなくならない本当の理由（わけ）
2008年に入り，SQLインジェクション攻撃が猛威を奮い続けている。8月6日には，アウトドア商品などを扱う通販サイト「ナチュラム・イーコマース」が外部からSQLインジェクション攻撃を受けたことを明らかにした（関連記事）。約65万件の個人情報が流出した可能性があるという。その少し前の7月23日には，ECサイト事業を手がけるアイリスプラザが攻撃を受けたと発表した。使っていない古いプログラムのぜい弱性を突かれ，カード情報2万8000件が漏えいした可能性があった。 SQLインジェクション攻撃では，情報を盗み出すものだけでなく，サイト改ざん事件も多発している。例えば（米国のビジネスウィーク誌のサイトが乗っ取られた事件（関連記事）。Webページではないが，ゴルフダイジェストオンラインもSQLインジェクション攻撃によって，メルマガ配信用のコンテンツを書き換えられた。 SQLインジェクション以外のぜい弱性
「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
XSS: 今こそXSS対策についてまとめよう - 徳丸浩の日記(2008-08-22)
_今こそXSS対策についてまとめよう 沢出水（さわ いずみ）さんからトラックバックを頂戴した。 元々はホワイトリスト方式の優位は神話というエントリでホワイトリストはどう作る?を引用(批判)した事が発端の模様です。 一見真っ向対決しているようなので興味深く読ませていただいたのですが、正直、両者の主張の違いがわかりません。 どちらもXSS等インジェクション系の対策としてはアプリケーションで入力値が正しい形式の範囲内かチェックし、出力時に必要なエスケープ処理を行う、という結論に思えるんですけど… [ホワイトリストとブラックリストより引用] ご指摘の通りで、XSS対策は入り口でのバリデーションと表示(HTML組み立て)時のエスケープだ。しかし、元ブログの主題はホワイトリストとブラックリストの比較なので、「ただ、表面的に文章を追っただけでは『何をホワイトリストと呼ぶのか』という部分がだいぶ違う印象を
プログラミングではホワイトリスティングが基本 - ikepyonのだめ人間日記
http://blog.ohgaki.net/-13 なんか違和感があるなぁと思った。 脆弱性がどこで発生するかと言うと、多くの場合、他のプログラムへの出口だと思うんですよ。入り口で閉める（ホワイトリストやブラックリストでフィルタリングする）ことで、そりゃある程度の対策は取れる。なぜなら、プログラムの挙動は入力データによりある程度左右されるから。でも、それらを通過してしまってなお、攻撃が有効なケースと言うのもあるわけで。作成したプログラム単体（DBとかファイルシステムとか）使ってないと言うのであれば、話は簡単なんだけど。実際のプログラムは他のプログラムと連携を取っていて、他のプログラムの仕様は変更できないから、出口で何とかしなけりゃいけないと思うんだよなぁ（ま、いじれる自分が開発したプログラムで何とかするということ）。 ホワイトリストが基本と言われると、あらゆるデータを受け付ける必要がある
「安全なウェブサイト運営入門」におけるOSコマンド・インジェクションの脆弱性：IPA 独立行政法人 情報処理推進機構
「安全なウェブサイト運営入門」にOSコマンド・インジェクションの脆弱性が存在することが判明しました。 この脆弱性を悪用された場合、悪意ある第三者の攻撃により「安全なウェブサイト運営入門」が動作しているコンピュータ上でOSコマンドが実行されてしまう危険性があります。 このことから「安全なウェブサイト運営入門」は使用しないでください。 脆弱性の説明 「安全なウェブサイト運営入門」が、細工されたセーブデータを読み込むことで任意の OSコマンドを実行される可能性があります。 脆弱性がもたらす脅威 悪意のある第三者によってコンピュータが任意に操作される可能性があります。 対策方法 「安全なウェブサイト運営入門」を使用しない。 「安全なウェブサイト運営入門」の開発およびサポートは終了いたしました。そのため、今後本脆弱性の対策版を提供する予定はありません。「安全なウェブサイト運営入門」の使用を停止してく
IE6 の JavaScript では href 属性の %20 と %25%32%30 の違いが分からない - IT戦記
これはひどい /%20 と /%25%32%30 はリンク先が違うのに、 IE6 では判断する術がない。 <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> </head> <body> <a id="id0" href="a%20a">foo</a> <a id="id1" href="a%25%32%30a">foo</a> <script> var elm0 = document.getElementById('id0'); var elm1 = document.getElementById('id1'); alert(elm0.href == elm1.href); // true alert(elm0.getAttribute('href') == elm1.ge
見落としがちな脆弱性（Webアプリケーション編）～その3
Webサイト利用者への受動的攻撃の踏み台利用を目的としたWeb改ざんが世間を騒がせている。日本IBMのSOC（セキュリティ・オペレーション・センター）においても，中国を発信源とする一連のSQLインジェクション攻撃を断続的に観測しており，今後も同様の攻撃が続くものと見ている。 Web改ざん自体は目新しいものではないが，動機は自己顕示・愉快犯から金銭目的に変わった。攻撃の手口も，公開されている攻撃コードを単純かつ無差別に試すスクリプトキディ的なものから，周到に準備する傾向に変化している。Webサイト管理者には，自らのサイトに対する直接的な攻撃の防御に加え，第三者に対する攻撃に加担させられないためのセキュリティを考慮することが今後ますます求められる。今回はWeb改ざんによる不正プログラムの挿入を防ぐ上で，見落としがちな例を取り上げる。 Webページの改ざんを許してしまうWebアプリケーションのぜ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog
http://tokumaru.org/d/20081029.html
PHPでのセキュリティ対策についてのメモ - Liner Note