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
レポート「ビットコインキャッシュの取り出し方&送金方法」を配信。画面付きで丁寧に解説 レポート「アルトコイン図鑑」では30種類以上のコインの概要と見通しを解説レポート内容へ ビットコインについて、それでもまだよくわからないという声がおおい。多分、送金のところのイメージがつかめないので、意味不明に陥っていると思う。 今回の事件を理解するにあたっては、ビットコインの送金の部分がどうなっているのか、理解することが肝要であろう。これがわかると、だいぶわかると思う。議論や、取材の一助になればとおもう。 Q ビットコインの送金はどうやるのか? ビットコインの送金は、相手先のビットコインアドレスというものを指定することで送ることができる。ビットコインアドレスは世界中で固有のもので重複がない。よって、一意に相手に送金できる。 Q 相手をダイレクトに指定できるということか? そうだ。メールアドレスや、ツイッ
不正ログイン防止のため、パスワードと登録情報のご確認をお願いします 弊社自身の調査により、はてなのサービスに対して外部から不正なログインが行われた可能性があることが判明しました。 ただし、弊社サーバーへの侵入によるアカウント情報の流出や、パスワードを機械的に推測してログインを試行するといった不審な行動は確認されておらず、他社サービスから流出または不正取得されたアカウント情報(IDとパスワードの組み合わせ)を流用された可能性が高いと考えています。 そこで、他社サービスと同一のID(メールアドレスまたはユーザー名)およびパスワードを使用しているユーザー様は、安全のため登録メールアドレスがご自身のものであるかを確認の上、早急にパスワードを変更してください。 それ以外のユーザー様も、下記にあるように登録情報等をご確認の上、より安全なパスワードと、正しく有効なメールアドレスを設定いただけるようお願い
ubuntu 12.10 (AMD64) ※12.10以前でも基本は同じですが,“Passwords and Keys”のGUI操作が微妙にちがいます(メニューや右クリックで表示されるコンテキストメニューをながめて探せば同じメニューにたどりつける程度のちがいです). 図1. ubuntuにログインした直後にパスワードを聞かれるダイアログ. (原文)Unlock Login Keyring. Enter password to unlock your login keyring. The login keyring did not get unlocked when you logged into your computer. (訳)ログイン キーリングのロック解除.ログインキーリングのロックを解除するためにパスワードを入力してください.コンピューターにログインする際にログイン キーリングの
セキュリティの基礎概念 この章では、WebLogic Server のセキュリティに関する以下の基礎概念について説明します。 監査 認証 SAML (Security Assertion Markup Language) シングル サインオン (SSO) 認可 ID と信頼 セキュア ソケット レイヤ (SSL) ファイアウォール J2EE と WebLogic セキュリティ 監査 監査とは、リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するプロセスのことです。言い換えれば、監査はコンピュータのアクティビティの電子的な記録を提供するものです。WebLogic Server のセキュリティ アーキテクチャでは、監査プロバイダを使用して監査サービスを提供します。 監査プロバイダがコンフィグレーションされている場合、ドメイン コンフィグレーシ
Javaの通信暗号化もTSL 1.2に。基本的に後方互換性は維持するが、一部影響がある場合もあるという。 米オラクルは、2014年3月に正式リリースを予定している「Java Development Kit(JDK)8」の通信暗号化プロトコルはTLS 1.2がデフォルトになると発表した。業界でTLS 1.2をサポートする動きが広がる中、デフォルトをアップデートすべき時だと判断した。 オラクルの2014年1月28日のブログによると、TLS 1.2は2011年にJDK 7でサポートを追加したものの、互換性上の理由からサーバーソケットではデフォルトで有効に、クライアントでは無効になっていた。しかし、その後の進歩で相互運用上の問題が解消されたという。 JDK 8でTLS 1.2をデフォルトとする理由は2つあり、1つはTLSの後方互換性を挙げている。デフォルトが1.2になっても、1.1や1.0を使って
ISO 27001 certified by BSI under certificate number IS 619805 for the information security management of Simeji
これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。 間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいか ということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団
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に値を埋め込む場合は、プリペ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く