Androidアプリの脆弱性の学習・点検ツール「AnCoLe(アンコール)」(以降、本ツール)は、Androidアプリの開発者を対象とした、脆弱性が作り込まれてしまう原因や対策について実習形式で学べるツールです。詳細は、「ツール概要」をご確認ください。 利用を希望される場合は、ダウンロードページの利用規約の内容に同意の上、使用してください。
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private network
Imagine the following scenario: You need to get a key (in the asymmetric case the user's public key) from a user visiting your website and want the browser to remember the private part without bothering the user with lengthy import procedures. To be honest, in practice you don't even want the user to deal with cryptographic details - details that many users are not able to know and do not know any
Free course demos allow you to see course content, watch world-class instructors in action, and evaluate course difficulty.
ISO 27001 certified by BSI under certificate number IS 619805 for the information security management of Simeji
JVN#53768697 Android OS において任意の Java のメソッドが実行される脆弱性 について見つけたいきさつを記事にしました。 こちらは長いので、ざっくりバッサリ、なるべく簡潔に、何ができちゃうのか・何がヤバいのかをまとめます。 【原因】 WebViewの addJavascriptInterface()の危険性(参考)が、Android 3.x/4.0/4.1 ではWebViewそのものに存在する。 このためWebViewをそのまま使っているアプリや、WebViewのラッパにすぎない標準ブラウザに同様の脆弱性がある。(Android版ChromeはWebViewを使っていないので問題ないです) 【何ができてしまうか】 JVNに書かれている通り Android 標準ブラウザや WebView クラスを利用しているアプリで、細工されたウェブページを閲覧した際に、ユーザの意
JVN#53768697 Android OS において任意の Java のメソッドが実行される脆弱性 が公表されました。 不肖私が昨年9月にIPAに届け出たものです。 これまでは情報非開示依頼があったので多くを語ることができませんでした。 ヤバい内容なのでみんなに注意喚起したかったけれどそれができない苦しさ。 周りでICS端末を使ってる人を見かけたら「事情は言えないけどブラウザにはChromeを使って。標準ブラウザ使わないで」と言うくらいしかできなくて申し訳ありませんでしたm(_ _)m 当時のいきさつを日記から掘り起こして記録に残しておきたいと思います。 2012年9月15日(土) WebViewを使ったビジネスアプリのフレームワークを作りたいという構想があって(PhoneGapにはないビジネス用の固有の機能を入れようと思って。バーコードリーダーとか印刷機能とか)、そういえば addJ
単純ではない、最新「クロスサイトスクリプティング」事情:HTML5時代の「新しいセキュリティ・エチケット」(2)(1/3 ページ) 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー(Same-Origin Policy)」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング(XSS)について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
2013-12-07 【Windows】秒速でパケットを盗聴する条件[ARP] ネタ 秒速でパケットは盗聴できる 以下の2つの手順で同一LAN内にある誰かのPCがどこと何を通信しているか(たとえばサイトURLとか)を知ることができます。 ARPスプーフィングする 自分のPCが通信するパケットを見る どっちもメチャメチャ簡単なので秒速でできます。今どきポチポチクリックしていればできてしまいます。つまり小学生でも盗聴ができてしまうのです。ノートPCでもスマホでもタブレットでも盗聴されちゃいます。 ARPスプーフィングする 早速やっていきましょう。ためにならない解説は飛ばしてやり方を見てください。 ARPスプーフィングについて しょぼい解説です。要らない方は飛ばしてやり方を見てください。 普段の通信 ターゲットを「弟」としましょう。弟はいつもこんな感じでニコニコ動画とかLOLとかやってるとします
先日のng-mtg#4 AngularJS 勉強会でLTしようと思ったけど申し込みが間に合わなかったのでブログに書きます。 先月リリースされたAngularJS 1.2はセキュリティがんばってる的なことを聞いたので、セキュリティ周りの仕組みを調べてみました。 お題は以下です。 CSRF JSON CSP (Content Security Policy) Escaping CSRF ユニークなトークンをHTTPリクエストに載せてサーバーでチェックする対応が世の中では主流(最近はカスタムヘッダのチェックによる対策も) AngularJSでは、XSRF-TOKEN Cookieにトークンが載っていると、$httpを使ったHTTPリクエストのヘッダに自動的にX-XSRF-TOKENヘッダーが付く。 XSRF-TOKEN CookieはもちろんNot HttpOnlyで。 Angular界ではCS
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く