SQLインジェクション対策に正解はない
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
今夜つける HTTPレスポンスヘッダー （セキュリティ編） - うさぎ文学日記
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
GitHubに大規模な不正ログイン試行 | 徳丸浩の日記
GitHubのブログおよび国内の報道によると、GitHubに対して大規模な不正ログインが試みられたようです。 GitHubは米国時間の2013年11月19日、ブルートフォース攻撃を受けたことを明らかにした。攻撃の時期や被害を受けたアカウント数は公にしていないが、今回の攻撃を踏まえ、より強固なパスワードや二要素認証などを利用するようユーザーに呼び掛けている。 GitHubにブルートフォース攻撃、一部のパスワードが破られるより引用 私もGitHubアカウントがありますのでSecurity Historyページを確認したところ、不正ログインの試行が確認されました。IPアドレスは、ベネズエラ、タイ、ブラジルのものです。 GitHubアカウントをお持ちの方は、念のためSecurity Historyを確認することを推奨します。 今回の不正ログインの特徴は以下のようなものです。 少数の「弱いパスワード
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
JavaScript: / の \ によるエスケープのみによるセキュリティ対策は禁止
(Last Updated On: 2018年8月4日)RFC 4696をもう一度読みなおしてみると/もエスケープ可能文字に定義してありました。JavaScriptのエスケープシークエンスの処理の部分も間違っていたので全面的に書き直します。 RFC 4696（JSON）の定義では string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; ” quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ;
PHPのJSONのエスケープ
(Last Updated On: 2023年12月8日) 追記：最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。 JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。 PHPにJSON形式のデータに変換するjson_encode関数とjson_decode関数をサポートしています。 JSON関数がサポートされている
OAuthのセキュリティ強化を目的とする拡張仕様を導入しました - mixi engineer blog
こんにちは. 研究開発グループ ritouです. だいぶ前の記事で紹介したとおり, mixi Platformは様々なユーザーデータをAPIとして提供するにあたり, リソースアクセスの標準化仕様であるOAuth 2.0をサポートしています. mixi PlatformがOAuth 2.0の最新仕様に対応しました | mixi Engineers' Blog mixi Platformをさらに安全にご利用いただくため, OAuth 2.0におけるCSRF対策を目的とした拡張仕様を検討, 導入しましたので紹介します. OAuth 2.0の認可フローとCSRF エンジニアの方であれば, Webサービスに対するCSRF(Cross-site Request Forgery)をご存知でしょう. CSRF攻撃とは悪意のある外部サービスへのアクセスや特定のURLへの誘導などをきっかけとしてユーザーの意図
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
サーバサイドからクライアントサイドのJavaScriptを呼び出す際のベストプラクティス - kazuhoのメモ置き場
JavaScript文字列のエスケープ – yohgaki's blog に対して、 最近だと id="hoge" data-foo="<% bar %>" しておいて $("#hoge").data('foo') でとりだすのが主流かと思います。 はてなブックマーク - JavaScript文字列のエスケープ – yohgaki's blog のように、 そもそもJavaScriptコードを動的生成すべきでない JavaScriptコードに渡す変数はHTMLノードを経由すべきだ というような反論がついています。 が、はたしてそうでしょうか。 僕には、元の記事の手法も、HTMLノードを経由する手法もあまり好ましくない*1ように思えます。 そもそも、HTML生成時にXSS脆弱性が発生しがちなのは、 タグや静的な文字列と動的に生成される文字列が混在し 埋め込まれる多数の文字列を正しくエスケープ
JavaScript文字列のエスケープ
これらの中で注目すべきは ‘ と ” と \ です。シングルクォート、ダブルクオートは文字リテラルを作成する為に利用され、\ でエスケープできることです。つまり、文字リテラルの最後に \ が現れると文字列の終端が無くなります。単独で不正なJavaScriptの挿入が可能になる訳ではありませんが、プログラムの構造が破壊される事を意味します。 PHPにはJavaScript文字列用のエスケープ関数が用意されていません。htmlspecialchars()やhtmlentities()で代用している場合も多いと思います。しかし、これらの関数ではJavaScript文字列のエスケープを十分に行う事ができません。 JavaScriptプログラムの構造が破壊される例 <?php $msg1 = 'test string\\'; $msg2 = ');alert(document.cookie); //
エンジニア必須の概念 – 契約による設計と信頼境界線
(Last Updated On: 2019年5月29日)少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。 契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。 契約プログラミングとは 契約プログラミングは比較的新しい設計思想で、サポートしている言語にはEffile、D、Clojure、Valaなどがあります。最近作られた言語の多くが契約プログラミングをサポートする機能を持っています。C++、C#やJavaなどでも契約プログラミングをサポートするライブラリが利用できます。契約プログラミングをサポートする言語やライブラリを利用しない場合でも、契約プログラミングの概念を適用すると安全かつ効率が良い開発の手助けになります。 Wikipdiaの
出力先のシステムが同じでも、出力先が異なる、を意識する
(Last Updated On: 2018年8月4日)出力先のシステムが同じでも、出力先が異なる場合はよくあります。これを意識していないとセキュリティ問題の原因になります。 私は普段から出力を行う場合には、どのような出力先であるか、を常に意識しています。「大垣はなぜエスケープにこだわるのか？」と疑問に思っている方も居ると思います。その理由は出力にこだわっているからです。安全なプログラミングには出力先を良く理解する事が必須だからです。フレームワークやライブラリは出力先の特性を良く理解していなくても、安全に出力できるような仕組みを提供している場合もあります。しかし、前提条件があったり、不完全な場合も多いです。フレームワークやライブラリが完全であるかないか？を確認・理解する為にも出力先と出力先に対する適切なエスケープ/バリデーションにはこだわる必要があります。APIを利用した出力を行っている場
PHPのsetcookie関数で空文字列を設定しようとするとクッキーが削除される
PHPでスクリプトを書いていて、setcookieの第2パラメータ(クッキーの値)の変数をタイプミスしたところ、以下のレスポンスヘッダが送信されていました。 setcookie('A', $misspelled_variable); ↓ 結果 Set-Cookie: A=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT 日付が大昔になっているし、クッキーの値に「deleted」は指定していません。これは、クッキーを削除する時の書き方ですが、PHPでクッキーの削除というと、expiresに過去日付を明示する方法をよく見かけますが、単に第2パラメータを空文字列にすればよかったのか…と思いマニュアルを見たら、一応書いてありました。 http://php.net/manual/ja/function.setcookie.php 陥りやすい失敗 クッキーは
「社長が覚えられないので管理者のパスワードは４桁の数字でお願いします」 - 情報の海の漂流者
新規で立ち上げる某中小企業サイトのネットショップ機能について、タイトル通りのセリフを言われて、ここ最近気が重かった。 そういう感覚で自前のネットショップをやるのはセキュリティ上明らかにまずい。 この件のことを考えていると、顧客情報流出したらどうしようとか、管理者アカウントを乗っ取られたらどうしようとか、そもそもそんな危険なサイトを作るのはインターネット全体に対する裏切りなんじゃないのかとか、いろいろ悩んでしまい、胃が痛くて仕方がなかった。 そんなタイミングで、yahooショッピング出店料無料化のニュースが流れたのはすごいラッキーだった。 先方はどうやら、出店料や維持費が払えないため、自前でネットショップをやろうと思ったらしくて、ヤフーの変更について話したら「その条件ならばヤフーでやりたい」と即座に方向転換することが決定した。 yahooでやってくれるならば、パスワードは最低6桁必要になる。
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
ApacheのVirtualHostによる高集積Webホスティングでsymlink問題を根本解決する方法について考えた
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 最近、各所でApacheのVirtualHostを利用した高集積ホスティングのセキュリティに関するインシデントが起きています。僕自身、自分の専門の一つがWebサーバのセキュリティなので、他人事には思えず、毎日各所の経過情報を眺めています。また、数社からApacheのセキュリティに関してもいくつか質問を受けたりしており、公に話せるような内容はこのブログでも公開していきたいと思います。 ということで、ApacheのVirtualHostによる高集積Webホスティングにおけるsymlink問題を根本解決するにはどうしたら良いのかを考えました。まずは、静的コンテンツも動的コンテンツのようにファイルのユーザ権限で処理する方法から紹介します。その後、ホス
Apache HTTPD: `Options -FollowSymLinks` は不完全 - ダメ出し Blog
シンボリックリンク攻撃を防ぐための Apache HTTPD モジュールの解説はこちら: Apache HTTPD: mod_allowfileowner https://fumiyas.github.io/apache/mod-allowfileowner.html 背景 ロリポップの共有 Web サービス下のサイト改ざん事件で、 攻撃手法の一つとして 「他ユーザー所有のファイルへのシンボリックリンクを自分のコンテンツディレクトリ下に作り、Apache HTTPD 経由でアクセスする」手順が利用されたらしい。 参考: http://blog.tokumaru.org/2013/09/symlink-attack.html 当社サービス「ロリポップ！レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について http://lolipop.jp/info/news/4149/#090
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
共用サーバにおけるSymlink Attacksによる攻撃とその対策について - さくらインターネット創業日記
