Webアプリケーションを作る前に知るべき10の脆弱性 ― ＠IT
Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP（Open Web Application Security Project）は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日本語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ
会員制ログイン機能を簡単に付加するスクリプト「PHPLogin」 - GIGAZINE
「会員制ログイン機能」を搭載しようと思うとなかなか骨が折れます。で、そういった面倒な部分のみを提供し、簡単に実現できるのがこの「PHPLogin」というスクリプト。既存のスクリプトなどにすこし追記するだけで使用可能です。 実現できる機能としては、会員のログイン率のグラフ化、ユーザーのグループ化、メールの一斉配信、フォームの入力チェック、オンラインかオフラインかの表示、多言語対応、メールによる認証、二度目以降のログインの省略などなど。 ダウンロードと実際の機能の詳細、デモなどは以下から。 PHP Login script http://www.phplogin.net/ 以下のページから無料版がダウンロードできます。無料版は20ユーザーまでという制限があります。ちなみに有料版だとユーザー数が無制限で、価格は29ドル。 Download the trial version of PHPLogi
まちがった自動ログイン処理
(Last Updated On: 2018年8月20日)問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
対策遅らせるHTMLエンコーディングの「神話」
クロスサイト・スクリプティングという言葉は元々，WebアプリケーションのHTMLエンコード漏れなどを利用することによって第三者にJavaScriptを実行させる手法を指す。広義では，HTMLのエンコードによる画面改変などを含むこともある。 前回述べたように，クロスサイト・スクリプティングのぜい弱性はWebアプリケーションに見付かるぜい弱性の半分以上を占める。数年前から指摘されているにもかかわらず，一向になくならない。その理由として，クロスサイト・スクリプティング対策あるいはHTMLエンコード注1）に対する「神話」があり，正しい対策の普及を遅らせているように思う。その「神話」の数々について説明しよう。 注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる 「すべからくHTMLエンコードすべし」が鉄則 HTM
ウノウラボ Unoh Labs: PHPで暗号化・復号化あれこれ
shimookaです。 皆さんはPHPでデータの暗号化・復号をする必要に迫られた場合、どのようにしているでしょうか？今回は、PHPで利用可能なモジュールやパッケージとそれらのサンプルを3つほど挙げてみました。 mcrypt拡張モジュールを使った暗号化 libmcryptを利用したPHP拡張モジュールです。DES、3DES、Blowfish、RIJNDAEL（ラインダール：AES暗号とも呼ばれる）、Blowfishなどのブロック暗号をサポートしています。利用可能な暗号モードはCBC、OFB、CFB、ECBです。 PHPで利用するには、libmcryptをインストールし、configureオプションに「--with-mcrypt」を付ける必要があります。また、PHP5以降、libmcrypt 2.5.6以降が必要です。 以下は、SSHやファイル暗号化ソフトウェアなどに広く利用されているBlow
[セキュリティ]画像へのPHPコマンド挿入 ― T.Teradaの日記
だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ
yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
(Last Updated On: 2016年3月3日)最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考：セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQL、MySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト～6バイト必要なのか
画像ファイルに PHP コードを埋め込む攻撃は既知の問題
(Last Updated On: 2015年9月10日)国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。 典型的な攻撃のシナリオは次の通りです。 追記：Tokenizerを使った例に修正しました。 アバダなどの画像ファイルをアップロードできるサイトを探す ローカルファイルインクルードバグを探す 画像ファイルにサイトが利用している言語のコードを埋め込む 攻撃コードを含んだファイルを画像ファイルとしてアップロードする ローカルファイルインクルードバグを利用して攻撃コードを実行する PHPの場合、リモートインクルードバグを攻撃するための攻撃
絶対に公開してはいけないPHPプログラミング
絶対に公開してはいけないPHPプログラミング ネタ元：AjaxMail：Ajaxを活用したフリーPHPメールフォーム これはひどいのに誰もつっこみを入れていないので、ツッコミを入れておきます。 セキュリティーフィックスされたました。 AjaxMailを利用しているサイトはスパムメールの踏み台にされます。 送信プログラムであるsendmail.phpの 150行目でPOSTで受け取ったアドレスをそのまま変数に入れて、 $reto = $_POST['email']; 168行目で直接メール関数に利用している。 if($remail == 1) { mail($reto,$resbj,$rebody,$reheader); } ありえない。 mail関数の第一引数には送信先のメールアドレスを設定できるのですが、カンマ区切りで複数のメールアドレスが指定できます。 リターンメールの性質上、リファラ
やねうらお―よっちゃんイカを買いに行ったついでに家を買う男 - 危険なwebプログラミング
いまや、デザイナーですら、phpを使う時代になった。猫も杓子もphpである。以前は、「htmlが書けなきゃwebデザイナーじゃないよね」と言われていたのが、次第に「cssも書けなきゃ」「JavaScriptぐらい読めなきゃ」「phpを使えなきゃ」と、敷居があがってきた。webデザイナーの人たちも大変である。 phpは、確かに手軽に使える言語であり、いままでプログラミングに携わったことのない人であっても少し勉強すれば簡単なプログラムが書けてしまう。まして、C++やJavaで鍛えあげられたプログラマなら見た瞬間使えると言っても過言ではない。 しかし、セキュリティを確保することはそう簡単な問題ではない。このたび、ソシム株式会社から発売になった「PHP サイバーテロの技法 攻撃と防御の実際」(asin:4883374718)だが、この本は素晴らしい。現状知られているメジャーな攻撃方法14種類につい
t_komuraの日記 [セキュリティ]Web Application Security Reviews
PHP Everywhere に Web Application Security Reviews という、投稿がありました。 非常に興味深かったので、訳してみました。金融機関で受けた Web アプリケーションのセキュリティチェック項目をまとめたものだそうですが、結構厳しいです。 誤訳などがありましたら指摘していただけますと幸いです。 全ての重要な作業過程において、開発側と検査側を含めなければならない。言い換えると、もし私(開発側)が重要な案件を作成する場合、他の誰か(検査側)の検査と承認を受けなければならない。 取引の活発な団体の全ての取引において、ユニーク ID と(前後の)変更データ、タイムスタンプを保存しなければならない。 PHP または ASP で使用される全てのデータベースのパスワードは暗号化されていなければならない。 もし、Web アプリケーションがインターネットに公開される
![t_komuraの日記 [セキュリティ]Web Application Security Reviews](https://cdn-ak-scissors.b.st-hatena.com/image/square/ae7f4abb7e6442fab45fa96b182f48e5f0527f6b/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127090908787%2F17680117127090918273%2F1556506981)
PHPに“最悪”のセキュリティ・ホール，全ユーザーは今すぐ対処を：IT Pro
Hardened-PHP Projectは10月31日（現地時間），オープンソースWebアプリケーション開発言語PHPの深刻なセキュリティ・ホールを警告した。リモートからPHPスクリプトを実行される「今まで見つかった中でも最悪のセキュリティ・ホール。全てのPHPユーザは今すぐ対処を行う必要がある」（日本PHPユーザー会 大垣靖男氏）。PHP4の4.4.0以前のバージョン，PHP5の5.0.5以前のバージョンが影響を受ける。対策はパッチを適用することなど。 このセキュリティ・ホールは，ファイル・アップロードでグローバル・シンボル・テーブル$GLOBALSが書き換えられることにより，リモートからPHPのスクリプトを実行される可能性があるというもの。PHPの標準ライブラリであるPEARなどがこのセキュリティ・ホールにより攻撃される可能性がある。そのほか「影響を付けるシステムやアプリケーションは数
PHPのSession Fixation問題
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
akiyan.com : 新たなXSS(CSS)脆弱性、EBCSS
新たなXSS(CSS)脆弱性、EBCSS 2006-03-30 かなりヤバめなXSS的攻撃方法が見つかりました。詳細は以下のリンク先をご覧下さい。 文字コード（SJIS）とHTMLエンコードとCross-Site Scriptingの微妙な関係 文字コードとHTMLエンコードとCross-Site Scriptingの微妙な関係 (EUCの場合、UTF-8の場合) 何がヤバいのかというと、この攻撃方法に対する根本的対策がほとんどのサイトで行われていないと思われるからです。 今までCross-Site Scripting脆弱性への対策はHTMLで使われる文字列を実体参照に変換するのが基本でした。しかし、マルチバイト文字列の仕様を突いて半端な文字列を送信しクオート文字を無効化（escape）することで、実体参照に変換されていてもスクリプトの実行が可能なケースがあることが判明したのです。 ちなみ
マルチバイトの落とし穴 − ＠IT
ブラインドSQLインジェクションも不必要情報の脆弱性も覚えた星野君。だけど覚えないといけないことはまだまだありそうです。今日も赤坂さんといっしょにお勉強。 「はい、これでクロスサイトスクリプティングやってみせて」赤坂さんがそういって見せてくれた勉強用のWebアプリケーション、あれ、見たところ完ぺきなんですが…… 高橋さん 「どうよ？」 星野君 「え……。どうって何がですか？」 高橋さんは唐突に会話を始めることが多い。大抵の場合、星野君には何の話か分からない。 高橋さん 「こないだ赤坂さんとWebアプリの検査したでしょ。どうかなって」 星野君 「どう……っていうか、なんか難しい感じでした。簡単なのはすぐに見つけられると思うんですけど……」 高橋さん 「ふーん……」 高橋さんはしばらく考え込んだ後、赤坂さんに声を掛けた。 高橋さん 「ねぇ、赤坂さん。いまって暇？暇だよねー？」 赤坂さん 「いや
高木浩光＠自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mixiのユーザーのプロフィールを外部へ持ち出し、データベース化するシステムは作成可能*ホームページを作る人のネタ帳
Webアプリケーション脆弱性チェックツール:Chorizo:phpspot開発日誌
連載：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp
http://neta.ywcafe.net/000727.html