理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
Appleのサーバー認証を通過するアプリ内課金のクラックツールが出回っているらしい - @Yoski はてな別室
アプリ内課金のクラックツールで有名なのは iAP Cracker で、これは偽署名を作成することで「サーバー側認証を行なっていない」実装のアプリについてアプリ内課金を回避ししてしまうツールです。 urus のリポジトリにあるやつが有名で、これを使うとデフォルトで Transaction ID が「com.urus.iap.xxxx」になるので、まぁもろバレなわけですが・・・。 iAP Cracker については、iOS 6.1 で Apple が対策をいれたため使えなくなりました。 代わりに「LocalIAPStore」というものが出まわってます。ただ、これも「サーバー側認証」されるとダメなので、アプリ開発者がちゃんとサーバー側で認証していれば問題ありません。 ところが、最近サーバー側認証を回避するアプリ内課金のクラッキングツールが出回っているようです。 アプリ内課金のサーバー認証では、i
Blog: bashの脆弱性がヤバすぎる件 – x86-64.jp - くりす研
Browse by time: December 2018 (1) December 2016 (1) December 2015 (1) January 2015 (1) September 2014 (2) July 2014 (2) April 2014 (1) February 2014 (1) January 2014 (3) December 2013 (2) September 2013 (3) June 2013 (1) May 2013 (1) April 2013 (1) March 2013 (2) February 2013 (5) やっと更新する気になった。 もくじ 0. 産業で説明 1. 理論編 2. 攻撃編 3. パッチ 4. 結論 0. 産業で説明 bashが アホで 地球がヤバイ 1. 理論編 bashの関数機能は、環境変数の中でも使える仕様になっています
自社サーバと交信するスマホアプリにおけるサーバ証明書の発行手法について（SSL Pinningと独自CA再考）
■背景 自社のサーバと通信する自社アプリについて、本来不要であるにも関わらず他社であるCAに認証情報の管理を委託することが多いわけですが、CAが証明書を誤発行した結果情報漏洩が発生したとして、その責任は自社にはないと主張できるのか、もう一度考えなおしたほうがいいんじゃないかと思うんです — Kazuho Oku (@kazuho) July 15, 2014 .@ockeghem @smbd @ando_Tw スマホアプリの提供においてはコードの署名鍵を安全に管理することが求められますが、その前提において通信相手の認証管理をCAに委託することにどれほどの意味があるんでしょう — Kazuho Oku (@kazuho) July 14, 2014 ■他社CAは信頼できるのか 特定のCAにpinningするのはしないより安全だけど、そもそも誤発行しないCAなんてあるのかという議論は重要。見知
攻撃シナリオを使って解説するApplicationCacheのキャッシュポイズニング
攻撃シナリオを使って解説するApplicationCacheのキャッシュポイズニング 吾郷 協 最近ウィンナーと燻製の自作にはまっています。@kyo_agoです。 この記事は1/28に行われた、第44回HTML5とか勉強会（HTML5とセキュリティ編）で発表した内容を元に書いています。 今回はApplicationCacheのキャッシュポイズニングに関してお話したいと思います。 最初に用語について説明します。 キャッシュポイズニングとは、キャッシュに対して攻撃コードを送り込み、そのキャッシュ経由で攻撃コードを実行させる攻撃手法です。 Googleで「キャッシュポイズニングを検索」した場合、検索結果の上位はDNSのキャッシュポイズニングに関する内容がほとんどですが、最近はクライアントサイドのキャッシュポイズニングも話題に上がるようになっています。 「クライアントサイドのキャッシュポイズニング
コマンド実行でシェルが怖いなら使わなければいいじゃない - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
http://blog.ohgaki.net/os-command-escape-shell-spec-command-implementation 「えすけーぷじゅうよう!!」を強調して言いたいからなのかシェルの理解が足りないからなのか、 意図がよくわからない文言やら説明が散見されますが、きりがないのでそれらはスルーします。 (シェルについては、なんで関係ない tcsh の話が出てくるんだとか、 位置パラメーター展開に $* 使うなとか、色々) 特に気になったのが以下の文章です。(強調は私によるもの) OSコマンドはOSが提供するシェルで実行されます。 シェルはテキストインターフェースを持ち、 テキストでコマンドとオプションを受け取り実行します。 例示した脆弱なPHPプログラムの場合、 ユーザーからの入力に対しセキュリティ処理を一切してないため、 簡単にサーバーを乗っ取られる可能性があり
「データ連携」が新たな価値を生むために必要な「アイデンティティ」の課題
「データ連携」が新たな価値を生むために必要な「アイデンティティ」の課題：Japan Identity ＆ Cloud Summit 2013レポート（1/2 ページ） 3月4日、5日の2日間、東京・一ツ橋の学術総合センターにおいて、産官学のそれぞれの立場におけるキーマンが「ID」を巡る幅広いテーマについて議論を行うイベント「Japan Identity ＆ Cloud Summit 2013」が開催された。 インターネット上で提供されるサービスの多様化に合わせて、各サービスが個人を識別するための「アイデンティティ（ID）」の重要性も高まりつつある。また、そのIDに関連して議論されるテーマも、技術的な論点に始まり、標準化、セキュリティ、信用の担保、各国の法制度に対応した運用をいかに行うべきかといったものへ、大きく広がりを見せている。 3月4日、5日の2日間、東京・一ツ橋の学術総合センターにお
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
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
サービスごとに異なるパスワードを使い分ける方法 - kazuhoのメモ置き場
最近、パスワードの使い回しをしているユーザーに対する攻撃が出回るようになってきています (参照: パスワード攻撃に対抗するWebサイト側セキュリティ強化策 | 徳丸浩の日記) が、マスタパスワードからサービスごとに異なるパスワードを自動生成するのが簡単な対策ですよね。 プログラマなら（もしくはコマンドライン操作に慣れているのなら）、こんな感じでできるかなーと思います。 $ perl -MDigest::HMAC_SHA1 -wle 'print Digest::HMAC_SHA1->new($ARGV[0])->add($ARGV[1])->b64digest' "my-master-password" example.com Mau83v+ml6dRViOZhcRdHM0NXzY $HMAC 関数にマスターパスワードとサービスのドメイン名を食わせて、その出力をサービス専用のパスワードにす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
