SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
SQLインジェクションゴルフ - なんと3文字で認証回避が可能に
昨日のエントリ「SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?」にて、認証回避の攻撃文字列が5文字にできる（「'OR'1」）ことを示しましたが、@masa141421356さんと、やまざきさん（お二人とも拙著のレビュアーです）から、idとpwdにまたがった攻撃例を示していただきました。やまざきさんの例は、MySQL限定ながら、なんと3文字です。これはすごい。 @masa141421356さんの攻撃例 @masa141421356さんのツイートを引用します。 @ockeghem 大抵のDBでid=''OR' AND pwd='>' ' が通ると思います（id側に「'OR」, pwd側に「>' 」で6文字）。長さ0の文字列がNULL扱いされないDBなら最後のスペースを消して5文字です。 — masa141421356 (@masa141421356) June
「安全なWebアプリケーションの作り方」を読んでセッションを復習してみた - As a Futurist...
タイトルが長くて略称があれば知りたい感じの「安全な Web アプリケーションの作り方」を暇を見つけて読んでいます。今まであいまいなままだった部分を順を追って説明してくれるので、本当に助かります。Web アプリ作りの初心者は卒業したかなーという人は必ず目を通しておくと良いと思います。 Cookie を用いたセッションについて復習 「HTTP はステートレスで」とかいう話はよく聞きますが、じゃあどうやってセッション管理するのがいいの？って話をよく考えると体系的に聞いたことがなかった！というわけで、この本で文字通り体系的に学び直すことができました。 その中でも、「セッション ID の固定化」という話題はちゃんと分かってなかった部分があったので、こちらのサイトを参考に PSGI なアプリケーションを作ってみました(僕の書いたアプリ自体はその他の脆弱性に溢れていますがｗ)。コードはエントリの最後に。
CSRF 防止用トークンの自動チェックの問題と解決 | tech | perl - 氾濫原
自分が作るウェブアプリケーションでは基本的に以下のような規則を守るようにしている GET だけで副作用 (DB書きこみなど) を伴う処理をしないこと POST 時には自動的に CSRF 防止用トークンをチェックすること これだけで単純な CSRF はまず防げくことができるからだ (実際は CSRF 防止用トークンの生成方法が多少問題になるが、作るウェブアプリケーションによって、どれほど厳密にすべきかが違うため、そのたび考えてやりかたを変えてる) このような設計をした場合、全ての POST するフォームに input type="hidden" とかで CSRF 防止用トークンを埋めこむ必要がある。ウェブアプリケーションフレームワークによっては、防止用トークンを埋めこむところも自動的にやってしまうものもあるが、外部サーバへ POST するフォームなんかを作ったとき (ASP型の外部サービスと
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
サービス側がパスワードを平文で保存する10の理由: ある nakagami の日記
（タイトルは釣りです） 「おいおい、おれのパスワードがメールで送られ来たよ」 という事例があとを経たず歴史は繰り返すなー、と思う今日この頃。 何故に平文で保存するのか？を自分なりに想像してみた 間違いとか、追加とかあったら教えて 1. 知らない ハッシュ値で保存しておいて、入力されたパスワードを、そのハッシュ値で 比較すればよいということを知らない。 プロなのに無知。しかし、このパターンが一番多い気がする。 2. 電話サポートが簡単 電話で問い合わせがあった時に、パスワードを再発行してもらうより その場の電話で口頭でパスワードを言ったほうが早く済む。客も喜ぶ（人もいる） 僕は、自分のパスワードを口頭で伝えられたらいやーな気分になりますが 3. めんどくさい 保存とはちょっと違うけど HTTP の Basic 認証とか csv pserver 認証とかって 符号化してるだけで簡単に復号できる
書式文字列によるSQLインジェクション攻撃例
以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは？ と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ？と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ
OAuthの認証にWebViewを使うのはやめよう
AndroidからTwitterへアクセスするためのライブラリとして，Twitter4Jが有名です． これを使ってみようと，「Android Twitter4J」と検索すると 認証にWebViewを使った例がたくさん出てきます． ・・・いや，ちょっとまて． それはちょっとまずいだろう． そういうわけでもうちょっと賢い方法を探してみました． 何がまずいのさ 「Android Twitter4J」と検索すると，上位にこんなページが出てきます． Twitter4jを使ってOAuth認証をアプリ内で行う方法 Twitter4j-2.2.xを使ったOAuth認証のコーディング例 twitter4jでツイートする Android+Twitter4JでOAuthするためのソースコード 上のサイトでは次の様は方法をとっています． アプリ内にWebViewを貼り付け WebViewでTwitterの認証画面
つながる時代のセキュリティ、チップと組み込みOSの連携で守る
つながる時代のセキュリティ、チップと組み込みOSの連携で守る：組み込みソフトウェア技術（1/4 ページ） もはや携帯電話機やPCだけではない。あらゆる組み込み機器がネットワークにつながる時代である。そうした機器をクラッカーの脅威から守り、データ保護を実装するには、半導体チップ上にハードウェアとソフトウェアの両方の形態で搭載された信用基盤を活用する必要がある。ただし、実際のセキュリティ設計には、制約条件や技術的な選択肢が数多く待ち受けている。 エレクトロニクスの世界は今、高度化が急速に進展している。それを後押しする要因は、さまざまな機器が通信によってインターネット上のサービスと連携し、高いインテリジェンスを提供するM2M（Machine to Machine）の興隆や、マルチメディアのさらなる普及、高額金融取引などの登場といった状況だ。 このような高度化は、基本的には好ましいものである。ただ
PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
俺史上最強のiptablesをさらす - Qiita
#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :
高木浩光＠自宅の日記 - Tポイント曰く「あらかじめご了承ください」
■ Tポイント曰く「あらかじめご了承ください」 「Tポイントツールバー」なるものが登場し、8月8日ごろからぽつぽつと話題となり、13日には以下のように評されるに至った。 Tポイントツールバー（by CCCとオプト）が悪質すぎてむしろ爽快, やまもといちろうBLOG, 2012年8月13日 その13日の午後、一旦メンテナンス中の画面となり、夕方には新バージョン（1.0.1.0）がリリースされたのだが、15日には、「Tポイントツールバーに関する重要なお知らせ」が発表されて、「8月下旬」まで中止となった。非難の嵐が吹き荒れる中で堂々と新バージョンを出してきたにもかかわらず、なぜすぐに中止することになったのかは不明である。 この「Tポイントツールバー」とはいかなるものか。以下の通り検討する。 騙す気満々の誘導 刑法の不正指令電磁的記録供用罪（第168条の2第2項）は、「人が電子計算機を使用するに際
Tポイントツールバーを導入するとSSL通信の履歴までもが盗聴可能になる
twitterなどでTポイントツールバーの利用規約が話題になっています。このエントリでは、Tポイントツールバーを実際に導入して気づいた点を報告します。結論として、当該ツールバーを導入すると、利用者のアクセス履歴（SSL含む）が平文で送信され、盗聴可能な状態になります。 追記(2012/08/10 20:10) たくさんの方に読んでいただき、ありがとうございます。一部に誤解があるようですが、ツールバーが送信している内容はURLだけで、Cookieやレスポンスまでも送信しているわけではありません。URLを送信するだけでも、以下に示す危険性があるということです。 追記終わり 追記(2012/08/13 23:50) ポイントツールバーにバージョンアップがあり、WEB閲覧履歴の送信がSSL通信に変更されました。従って、WEB閲覧履歴が盗聴可能な状況は回避されました。本日22:50頃確認しました。
Tポイントツールバー利用規約: TポイントとTカードの総合サイト[T-SITE]
カルチュア・コンビニエンス・クラブ株式会社 本規約は、カルチュア・コンビニエンス・クラブ株式会社(以下「当社」といいます)が定める「T会員規約」に同意し、T-IDその他当社が別途指定するログインID（以下総称して「指定ID」といいます）を登録の上、T会員ネットサービス登録を完了した方に対して当社が配布する、WEBブラウザ用プログラム「Tポイントツールバー」（以下「本ツールバー」といいます）をご利用いただくために、第1条第1項に定義する利用者端末に本ツールバーをインストールのうえ、本ツールバーを利用される方（以下「利用者」といいます）が遵守すべき事項及び当社と利用者の関係を定めたものです。尚、個人情報の取扱いや当社からのメール配信、その他本規約に定めのない事項及び用語の定義は、当社が別途定める「T会員規約」及び「Tサイトサービス利用規約」、並びに株式会社Tポイント・ジャパンが別途定める「ポイ
![Tポイントツールバー利用規約: TポイントとTカードの総合サイト[T-SITE]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5a1b20d201894e94ff54ad3869163e9dd07ab9a6/height=288;version=1;width=512/http%3A%2F%2Ftsite.jp%2Fpc%2Fimg%2Findex%2FT-cube.gif)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高木浩光＠自宅の日記 - 携帯電話販売店が本人同意を亡きものにする, 追記（21日）
なんとなくOAuth怖いって思ってるやつちょっと来い
NICOSパスワード8文字切り詰め制限祭りまとめ
